MSPF-539: recurrent data storage protocol #556
Conversation
proto/payment_processing.thrift
Outdated
| @@ -1763,6 +1783,33 @@ service RecurrentPaymentTools { | |||
| 2: RecurrentPaymentToolNotFound rec_payment_tool_not_found | |||
| 3: EventNotFound event_not_found | |||
| ) | |||
|
|
|||
| RecurrentPaymentTool UpdateResource ( | |||
| 1: RecurrentPaymentToolID id, | |||
There was a problem hiding this comment.
Мне пока не очень понятно, как адаптер (ну или HG) сможет при запросе на обновление карточных данных узнать идентификатор созданного когда-то в прошлом для хранения токена RecurrentPaymentTool. Ведь, насколько я понимаю, запрос снаружи придет с каким-то своим идентификатором (вероятно тот выдадут во время создания токена, не помню протокол). Как, на твой взгляд, должно происходить обновление?
There was a problem hiding this comment.
Сейчас поперечитывал и пораздумывал — складывается ощущение, что возможно стоило бы отойти от идентификатора, и в качестве аргумента использовать непосредственно карточные данные. 🤔
There was a problem hiding this comment.
Карточные данные не уникальны, их не получится использовать как идентификатор.
There was a problem hiding this comment.
Ну да, мысль была про то, чтобы обновлять все средства, где карточные данные совпадают с переданными.
There was a problem hiding this comment.
Как минимум мы не можем обновлять данные везде потому что держатель карты явно дает согласие на обновление данных в конкретной подписке. Это даже не говоря о том, что запрос снаружи придет с идентификатором subscriptionID
There was a problem hiding this comment.
А зачем системе нужен этот идентификатор подписки? Он даже не уникален сам по себе.
There was a problem hiding this comment.
Или задам вопрос иначе. Чем этот идентификатор для нас отличается от рекурентного токена и зачем нам их разделять?
There was a problem hiding this comment.
Хотя да, наверное он нужен, чтобы потом можно было по нему снаружи сослаться на созданный токен и сохраненные данные карты.
There was a problem hiding this comment.
Чтобы этот самый id подписки получить.
Но зачем он нужен там? Вроде пока никто не собирался обновлять данные старых подписок.
There was a problem hiding this comment.
Если только для новых вводить — в принципе не нужен, да.
Co-Authored-By: Andrey Fadeev <me@ciiol.net>
kpy3
force-pushed
the
MSPF-539/ft/recurrent_data_storage_protocol
branch
from
7be8dec
to
d50e883
Compare
proto/payment_system_provider.thrift
Outdated
| 1: CardNotTokenizable card_not_tokenizable | ||
| 2: domain.Failure failure |
There was a problem hiding this comment.
А почему было решено отдельно выделить именно эту ошибку?
There was a problem hiding this comment.
не все ошибки формализованы к сожалению, оставил в общем виде пока
There was a problem hiding this comment.
Я скорее про card_not_tokenizable. Мне пока кажется странным, что это отдельная ошибка / отдельный класс ошибок.
proto/payment_system_provider.thrift
Outdated
| /** | ||
| * Токенизация банковской карты. | ||
| **/ | ||
| PaymentSystemProxyResult Tokenize(1: InvoicePayment invoice_payment) |
There was a problem hiding this comment.
Странно, а почему передается платеж (и только платеж)? Там как минимум еще нужны опции адаптера, его стейт и т.д.
There was a problem hiding this comment.
В платеже, кажется есть всё что нужно для токенизации, айдишники будут в параметрах терминала, кажется тут нужно добавить опции адаптера и стейт
There was a problem hiding this comment.
Ну обычно мы делаем другую структуру, куда, быть может, как одно из полей входит платеж. Просто периодически возникает желание добавить еще информации для адаптера.
There was a problem hiding this comment.
К примеру, в платежный адаптер передается еще и инвойс
| @@ -658,6 +663,35 @@ union ShopLocation { | |||
| 1: string url | |||
| } | |||
|
|
|||
| /** Данные, необходимые для идентификации и аутентификации в МПС API **/ | |||
|
|
|||
| union PaymentTokenProviderInfo { | |||
There was a problem hiding this comment.
Этот тип нигде не используется. И должен ли? Вроде хотели хранить эти данные (и их часть) в параметрах терминала.
There was a problem hiding this comment.
Ну я пытался их формализовать как раз для параметров терминала или считаешь не нужно?
Co-authored-by: Andrey Fadeev <me@ciiol.net>
|
|
||
| struct TokenizationSuccess { | ||
| 1: PaymentTokenID token_id | ||
| 2: PaymentTokenEnrollment token_enrollment |
There was a problem hiding this comment.
А что такое PaymentTokenEnrollment и зачем он нужен? Нигде больше он сейчас не используется.
There was a problem hiding this comment.
оно используется в некоторых служебных вызовах например при манипуляциях с токеном, непонятно, правда нужен ли он будет нам или нет, решил что пусть пока сохраняется
| /** | ||
| * Необходимые для авторизации данные | ||
| **/ | ||
| typedef base.Opaque TokenCredentials |
There was a problem hiding this comment.
Странно, что это непрозрачные данные. Как адаптеры будут ими пользоваться?
There was a problem hiding this comment.
у них разная структура и наполнение, пусть адаптеры сами решают как им хранить это
|
|
||
| union FinishIntentSuccess { | ||
| 1: TokenizationSuccess tokenization_success | ||
| 2: GetTokenCredentialsSuccess credential_success |
There was a problem hiding this comment.
Учитывая, что GetTokenCredentials будет вызывать, вроде бы, платежный адаптер, мне представляется весьма нетривиальной задачей пробросить коллбек сквозь платежный адаптер. И, кажется, сейчас протокол в принципе не позволяет этого. Поставить коллбек при GetTokenCredentials можно, а обработать его не получится.
There was a problem hiding this comment.
Это я к тому, что быть может, если получение данных синхронное, пока не добавлять это в протокол.
There was a problem hiding this comment.
Поставить коллбек при GetTokenCredentials можно, а обработать его не получится.
Хотя, я тут подумал, обработать наверное получится.
| /** | ||
| * Получить данные (ключи, криптограммы) для авторизации платежа | ||
| **/ | ||
| PaymentSystemProviderResult GetTokenCredentials(1: PaymentTokenID token_id, 2: Context context) |
There was a problem hiding this comment.
Если этот вызов будет делать платежный адаптер, то ему придется собирать Context из payment_proxy.PaymentInfo. Это может быть весьма непросто. Или даже невозможно – вроде мы не пытались делать так, чтобы в payment_proxy.PaymentInfo была вся информация из платежа.
There was a problem hiding this comment.
Предлагаешь выпилить тут Context?
No description provided.