А почему у вас есть нужда в двухстадийном формате оплаты, если вы описываете реккурентные платежи
Двухстадийная оплата нужна для блокировки средств в качестве депозита и последующего списания за аренду Рекуррентный платеж необходим для повторного проведения операции аренды в целях удобства пользователя. Он не подразумевает что платеж одностадийный.
У вас есть сертификация PCI DSS
Сейчас очень непросто получить сертификацию PCI DSS, но мы работаем в этом направлении, и соблюдаем стандарты качества - храним пользовательские данные карт в обфусцированном виде без CVV, и передаем в зашифрованном от клиента к серверу.
Почему вы выбрали конкретно этот вариант?
Аренда может быть длительная, до нескольких месяцев, чтобы не дергать пользователя с оплатой, она происхоит безактепционно. Таким образом пользователь может оплачивать свою аренду постепенно
Похвальное понимание теории, однако реальность жестоко отличается от воображений о том как что должно работать и как оно работает на самом деле. Могу по пунктам вам разобрать ваш комментарий:
не содержит необходимости передавать данные карты в открытом
Откуда вы это взяли вообще представления не имею
Отправка запроса на оплату в API для получения ссылки на платежную форму и идентификатор процесса оплаты (и его сохранение)
ну отправьте запрос на карту Мир с самопильного клиента, потом напишите результат.
Получение статуса оплаты при возвращении пользователя на success URL и/или проверка оплаты в бекграунде по идентификатори процесса оплаты
Упустили шаг Submit3DSAuthorization. В документации он не описан корректно
Если у вас все так хорошо и отлично получается то пост просто не для вас, листайте дальше 🤷♂️
По первому пункту, я очень плохо себе представляю как использовать этот клиент на сервере, это не кажется очень разумной идеей. Такого сценария в вашем репозитории не описано
По поводу второго пункта:
Почему работает без него?
Почему в самой реализации вашего клиента указан неверный роут конфирмации?
Добрый день, добавьте пожалуйста эту ссылку на саму страницу продукта https://www.tinkoff.ru/kassa/develop/api/payments/. Спасибо
Да, конечно, скорее всего так и есть, и оно именно для этого и используется, но как этим пользоваться в случае с Тинькофф, не совсем понятно.
Двухстадийная оплата нужна для блокировки средств в качестве депозита и последующего списания за аренду Рекуррентный платеж необходим для повторного проведения операции аренды в целях удобства пользователя. Он не подразумевает что платеж одностадийный.
Сейчас очень непросто получить сертификацию PCI DSS, но мы работаем в этом направлении, и соблюдаем стандарты качества - храним пользовательские данные карт в обфусцированном виде без CVV, и передаем в зашифрованном от клиента к серверу.
Аренда может быть длительная, до нескольких месяцев, чтобы не дергать пользователя с оплатой, она происхоит безактепционно. Таким образом пользователь может оплачивать свою аренду постепенно
Tinkoff support reply detected.
Похвальное понимание теории, однако реальность жестоко отличается от воображений о том как что должно работать и как оно работает на самом деле. Могу по пунктам вам разобрать ваш комментарий:
Откуда вы это взяли вообще представления не имею
ну отправьте запрос на карту Мир с самопильного клиента, потом напишите результат.
Упустили шаг Submit3DSAuthorization. В документации он не описан корректно
Если у вас все так хорошо и отлично получается то пост просто не для вас, листайте дальше 🤷♂️
Хотя должен быть 'Complete3DSMethodV2'. Протестируйте в ручном режиме.
При всем уважении, использовать Flutter на сервере это очень сомнительная идея. В любом случае спасибо за вашу работу!
На сколько я помню, 3DS V2 не будет так работать.
По первому пункту, я очень плохо себе представляю как использовать этот клиент на сервере, это не кажется очень разумной идеей. Такого сценария в вашем репозитории не описано
По поводу второго пункта:
Почему работает без него?
Почему в самой реализации вашего клиента указан неверный роут конфирмации?
Для чего он вообще нужен?