приложение?
интересуют 2 сценария:
- оплата картой (без сохранения)
- оплата через Apple/Google pay
1- ый кейс: Насколько корректно/безопасно использовать вебвью и редиректить пользователя на шлюз оплаты через него?
2-ой: вроде бы понятен, но может тоже есть какие- подводные камни, о которых стоит занть зарнее
проблема еще в том, что заказчик уже давно на сайте использует Сбербанковский шлюз (а у них SDK вообще нет - только rest) - а тут можно нарваться на ограничения ( ибо если занимаешься хранением/передачей/обарботкой карт в аппке то должен иметь особый сертификат под этом)
Поэтому стороние сервисы типа paypall stribe etc не подходят, а то что я видел с яндекс-кассов - решение как по мне кажется тоже сырое, ну и опять-таки это уже отдельный провайдер получается
тогда только страдать. 1) webview использовать можно, но 100% работать будет только оплата картой, без apple / google pay 2) apple/google pay в webview не работают по требованиям безопасности. в wkwebview начиная с iOS 13+ можно платить с помощью Apple Pay но только если не внедрять скрипты на страницу, иначе просто кнопка не рендерится. В этом случае только chrome tabs или внешний браузер 3) хранить данные карт в принципе небезопасно, поэтому такое хранение обычно делается на стороне провайдера платежной системы. он возвращает токен пользователя / карты, с которым уже работает приложение
Ну я думаю все-таки нативную оплату Apple/Google pay отдельно обрабатывать вроде бибилотек парочку видел Так что отсутсвие нативных кнопок в вебвью не пугает
тогда ок, нативные интеграции и webview параллельно использовать никто не запрещает.
Обсуждают сегодня