- Я устал принимать платежи через WebView. Что мне делать?
- Мобильный SDK
- О пользе
- Как начать использовать у себя?
- Почему так — хорошо?
- Про разработку и тестирование
- Демонстрационное приложение
- Открытый исходный код
- Полезные ссылки
- Зачем и как мы создали мобильный SDK для приёма платежей в приложениях и что в этом хорошего
- Yandex kassa android sdk
- About
Я устал принимать платежи через WebView. Что мне делать?
Я езжу в офис на электричке — нужно проехать одну станцию, и я буду почти на месте.
Каждое утро покупаю билеты на поезд в приложении и страдаю. Там дешевле, но разница в цене не окупает мою боль, когда я прохожу эти три минуты стресса. Даже не упоминая время загрузки каждого из пяти экранов приложения, нельзя не сказать про банковские WebView с сохранённой картой, ввод кода из смс на бегу и неожиданные сбои в работе.
Это когда ты бежишь на поезд, а тебе говорят «Что-то пошло не так» и списывают деньги, а билет не дают. Возврат приходит тут же, но поезд-то уже ушел. Такое происходит пару раз в месяц, вне зависимости от качества интернета. Ни о каких -пэях и говорить не приходится.
В этот момент задумываешься — а может, есть способ проще? Ну, чтобы вообще без вебвью, красиво и нативно. И да, такой способ есть. Подробности под катом.
tl;dr Мы сделали интерфейс для приёма платежей через Apple Pay, Google Pay, мобильный банк Сбербанка и Яндекс.Деньги в iOS и Android. Нет, не придётся рисовать платёжные формы. Да, это еще и в open source.
Вообще, сценариев приёма платежей в мобильных приложениях примерно два.
Первый — через WebView с платёжной страницей. Так можно принимать платежи через кошелек, банковскую карту, мобильный или что угодно ещё. Проблема в том, что у WebView нет доступа к браузерным кукам, а значит, и авторизации для некоторых способов оплаты, поэтому заплатить не получится.
Во втором сценарии мерчант пропускает карточные данные через свой бэкенд — для этого нужно соответствовать PCI DSS, что дорого, долго и сложно.
Мобильный SDK
Мобильный SDK Яндекс.Кассы — это библиотека под iOS и Android, которую мы сделали, чтобы упростить жизнь мерчантам, разработчикам приложений и тем, кто заботится о своих пользователях. Фактически мобильный SDK — это инструмент для токенизации банковских карт и других платёжных инструментов. Токенизация — это обмен данных, которые нужны для проведения платежа, на уникальный идентификатор — токен.
Весной мы выкатили первую версию SDK — там была оплата картой и из кошелька в Яндекс.Деньгах. Сейчас всё стало ещё лучше — в июльском релизе добавили Google Pay, Apple Pay и платежи через Сбербанк с подтверждением по смс.
О пользе
Главная польза — покупатель платит чем угодно, но для мерчанта это выглядит как один токен, которым можно оперировать вместо платёжных данных.
Ещё не придётся проходить сертификацию на соответствие PCI DSS — карточные данные будут обрабатываться в нашем периметре. Мы каждый год проходим сертификацию, соблюдаем все правила регуляторов и избавляем от этого магазины, которые подключились к Кассе. Так можно.
С SDK платежи в Android и iOS выглядят привычно для пользователей, и им теперь не нужно покидать контекст приложения во время оплаты. Тем, кто платит из электронного кошелька, еще и не нужно авторизовываться — если пользователь залогинен в приложении Денег, понадобится только выбрать нужную учётку через Яндекс.Паспорт.
Как начать использовать у себя?
Если совсем обобщить, то нужно сделать две вещи:
- Интегрировать платёжный API Яндекс.Кассы — для приёма платежей;
- Подключить мобильный SDK — для токенизации и нативного интерфейса.
Чтобы добавить Apple Pay, достаточно подключить приём платежей по банковским картам и выпустить ключи в аккаунте разработчика Apple.
С Google Pay немного по-другому. Нужно:
- Подготовить тестовую сборку APK.
- Заполнить интеграционный чек-лист — подтвердить, что ваше приложение не собирается захватывать мир, и ещё несколько вещей.
- Залить сборку на проверку в Google Pay.
Google всё проверит и разрешит (или не разрешит) выкладывать приложение в Google Play.
Мобильный SDK встраивается в клиентское приложение, чтобы через него работали нативные платежи. Работает так: реквизиты карты уходят сразу в наш периметр PCI DSS, не попадая на бэкенд магазина. Мы всё проверяем, обрабатываем и возвращаем мерчанту платёжный токен со временем жизни в 30 минут — его можно использовать один раз.
Схема взаимодействия пользователя, мерчанта, мобильного SDK и API Я.Кассы
С участием SDK платёж состоит из трех этапов:
- Инициация оплаты и получение токена. Приложение инициирует платёж через SDK, а на выходе получает платёжный токен.
- Создание платежа. Токен уходит на сервер, который инициирует оплату через API.
- Запрос статуса платежа. Это нужно для того, чтобы отрисовать правильное окно с успехом или ошибками.
Почему так — хорошо?
Про разработку и тестирование
В iOS-версии мы используем VIPER и микросервисы.
В основе мобильного SDK лежит модуль токенизации — он управляет процессом так, чтобы мерчант на выходе видел только токен для API Яндекс.Кассы вне зависимости от того, чем платил пользователь. Еще модуль токенизации решает, какое окно сейчас показывать пользователю, и делает POST-запросы на сервер. Мы написали свою обёртку для API для работы с HTTP/HTTPS-запросами к YandexMoneyCoreApi — это сделало жизнь проще.
Сервисы — это хранилища и объекты, которые работают с клиентским API Яндекс.Кассы.
Их код получился чистым и лаконичным, без большого количества ветвлений и ранних выходов, потому что отделу разработки удалось продумать всю архитектуру заранее. В сервисах SDK концентрированное количество функционального программирования — здесь мы раскрыли его возможности полностью. Там, где приходилось работать с Functor, Monad, Applicative Functor, нам помогли обычные Promise.
Единственная сложность возникла с VIPER — мы начали добавлять новые виды оплаты и поняли, что центральный модуль сильно разрастается. Когда в нём оказалось около 1000 строк, мы решили, что надо что-то с этим делать и пересматривать архитектуру.
Идея с центральным модулем на процесс нам нравилась, и её мы решили оставить. В других проектах мы используем детерминированный конечный автомат для описания процесса, но здесь это не решило бы проблем, так как реализация многих вещей осталась бы в том же модуле. Так что мы решили применить паттерн «стратегия» для изоляции процессов каждого платёжного средства. После того, как пользователь выбрал способ платежа, мы создаём стратегию для способа оплаты, которая управляет картой переходов и решает, какой процесс за каким идет.
Демонстрационное приложение
Мы его сделали.
Всё началось с того, что отделу тестирования понадобилось что-то, на чём можно было тестировать мобильный SDK. Без тестового приложения ребята не могли проверить, как работает SDK, а разработчиков под обе платформы среди тестировщиков не нашлось.
В процессе выяснилось, что, кроме задач тестирования, демо-приложение — хороший способ показать нашим партнёрам, что такое мобильный SDK. Любой человек, который не умеет программировать на Swift или Kotlin (читай: любой человек), может посмотреть, как работает SDK. Поэтому мы залили демо-приложение в Google Play и iOS-версию на сайт Яндекс.Кассы.
Получилась штука, в которой можно посмотреть, как работают разные способы оплаты, поиграть с настройками или показать её тому, кто у вас отвечает за выбор платёжного агрегатора. Не стесняйтесь.
Открытый исходный код
Несколько месяцев после запуска мы распространяли библиотеку очень неудобно — делились ссылкой на сайт или отправляли файлы по почте. Хорошие ребята так не делают — они выкладывают всё на GitHub под лицензией MIT. Вот мы ровно так и сделали.
Кроме магии токенизации мерчанты могут настраивать цвета, менять логотипы или вносить любые другие изменения в библиотеку. А чтобы было совсем удобно, мы опубликовали мобильный SDK в CocoaPods для iOS-разработчиков и в Maven для Android-ребят.
Если вы уже принимаете платежи через Кассу, но теперь хотите делать это ещё лучше и продуктивнее — подключайте мобильный SDK. Если только открываете магазин — подключайте Кассу. У нас всё хорошо.
Полезные ссылки
На этом всё. Задавайте вопросы в комментариях!
Источник
Зачем и как мы создали мобильный SDK для приёма платежей в приложениях и что в этом хорошего
Менеджер по продуктам «Яндекс.Кассы» Максим Иванов — о том, как обстоят дела с оплатой в мобильных приложениях в России и что его команда сделала для того, чтобы предприниматели могли увеличить конверсию и зарабатывать больше.
Для начала давайте поговорим в цифрах про популярность платежей в мобильных приложениях. По данным Criteo (Европа, 2017 год), в приложениях конверсия продаж в три раза выше, чем в вебе. Проще говоря, в приложениях теряется намного меньше покупателей. Объём покупок в них превышает объём покупок в мобильном вебе — 56% против 44%.
Более того, доля покупок через смартфоны и планшеты — в том числе с мобильных приложений — постоянно растёт. Мы хорошо видим это по метрикам «Яндекс.Кассы». Недавно мы выпустили библиотеку для приёма платежей непосредственно в мобильных приложениях — рассказываем, как к этому пришли и что получилось в итоге.
До недавнего времени с помощью «Яндекс.Кассы» принимать платежи в мобильных приложениях можно было несколькими способами. Самый популярный — через webview, когда пользователь переходит из интерфейса приложения в веб-интерфейс платёжной страницы. Это самый простой в плане интеграции, но не самый эффективный метод.
Тот факт, что покупателям приходится покидать контекст нативного интерфейса приложения, приводит к снижению конверсии. Если человек хочет заплатить из электронного кошелька, тут тоже есть свой нюанс.
Обычно приложения не имеют доступа в мобильных браузерах к авторизации в «Яндексе», поэтому для оплаты из кошелька пользователю придётся авторизоваться в «Яндексе» через веб-интерфейс в приложении. Это ещё сильнее снижает конверсию в платежи.
Ещё один способ приёма оплаты в мобильных приложениях через «Яндекс.Кассу» — с помощью «Сбербанка Онлайн». В этом случае человеку нужно переходить через deep link из приложения магазина в приложение банка. Преимущество этого метода в том, что платёж происходит для покупателя в привычном и безопасном интерфейсе приложения «Сбербанка».
К недостатку можно отнести то, что пользователь покидает приложение магазина и после оплаты может в него уже не вернуться. Магазинам подключить этот способ оплаты не составляет большого труда, но опять же он не идеален с точки зрения пользовательского процесса.
Наконец, компании могут интегрироваться с API «Яндекс.Кассы» и принимать оплату с банковских карт через нативную платёжную форму в своём приложении. Однако для подключения этой возможности партнёру «Кассы» нужно обязательно иметь сертификат PCI DSS. Он есть далеко не у всех крупных компаний, а средним и небольшим получить его зачастую вовсе не по силам.
Таким образом, до сих пор в «Яндекс.Кассе» не было идеального универсального инструмента для приёма платежей в мобильных приложениях. И мы его создали.
Все перечисленные выше сценарии приёма платежей имеют как достоинства, так и недостатки. Мы проанализировали все их сильные и слабые стороны — и создали мобильный SDK «Яндекс.Кассы» для Android и iOS. С помощью нашей новой библиотеки можно принимать платежи из электронных кошельков и с банковских карт.
Мобильный SDK является частью новой технологической платформы «Кассы», то есть работает в связке с её API. На практике это означает, что магазины, которые уже интегрированы с этим API, смогут легко и без особых затрат интегрироваться и с нашим мобильным SDK. Теперь давайте разберём преимущества нашей новой библиотеки.
При использовании SDK оплата происходит полностью в нативном интерфейсе приложения магазина — без каких-либо переходов в веб. То есть процесс платежа становится для покупателя максимально простым и понятным, что положительно сказывается на конверсии.
Кроме того, SDK работает таким образом, что магазину не придётся пропускать данные банковских карт пользователей через свою бэкенд-систему. Это значит, что для приёма платежей с карт компаниям не нужно проходить сертификацию PCI DSS. По сути, мы создали нативный интерфейс, который помогает принимать оплату в мобильных приложениях и который могут подключить любые магазины — от самых крупных до небольших.
Ещё один плюс в пользу мобильного SDK — это заметное упрощение сценария оплаты из электронных кошельков в «Яндекс.Деньгах». Теперь авторизация в «Яндексе» нужна только при первом платеже в приложении. При этом покупателю вовсе не обязательно вручную вводить логин и пароль от аккаунта на «Яндексе».
SDK может получить авторизационные данные из других приложений «Яндекса», установленных на мобильном устройстве пользователя, или из мобильного браузера. И таких устройств в России большинство — на 80% смартфонов и планшетов в России уже пройдена авторизация в «Яндексе». Все последующие платежи «Яндекс.Деньгами» в мобильном приложении можно будет подтверждать одним касанием — так же просто, как через Apple Pay.
Авторизовавшись в «Яндексе», покупатели смогут платить в приложении и с банковских карт, привязанных к электронным кошелькам. По сути, это ещё одно упрощение платёжного сценария, благодаря которому пользователям больше не придётся вводить данные их банковских карт.
Это поможет ещё больше увеличить конверсию платежей. В результате с подключением мобильного SDK «Яндекс.Кассы» компании получат не только простой и эффективный платёжный сценарий в своих приложениях, но и постоянно растущую базу карт, привязанных к кошелькам в «Яндекс.Деньгах».
Поскольку SDK — это программная библиотека, посмотреть на неё в действии без участия разработчика не получится. Это затрудняет продвижение нашего нового решения среди клиентов «Яндекс.Кассы».
В самом деле, как предпринимателю или продакту принять решение об интеграции своего мобильного приложения с «Кассой», если он не может посмотреть, как всё это работает? Для всех сомневающихся мы создали демонстрационное приложение для iOS и Android. Оно наглядно воспроизводит разные сценарии оплаты, встроенные в наш SDK.
Мы наблюдаем тренд увеличения платежей из нативных интерфейсов сайтов и приложений. Это означает, что потребность в сервисах, подобных мобильному SDK «Яндекс.Кассы», будет только расти. Так что мы не собираемся останавливаться на достигнутом. В дальнейшем мы намерены совершенствовать уже существующие в SDK платёжные сценарии, добавить в него возможности кастомизации интерфейса и, конечно, новые способы оплаты.
Источник
Yandex kassa android sdk
YooMoney for Business Payments SDK (YooKassaPayments)
This library allows implementing payment acceptance into mobile apps on Android. It works as an extension to the YooMoney API.
The mobile SDK contains ready-made payment interfaces (the payment form and everything related to it).
Using the SDK, you can receive tokens for processing payments via bank cards, Google Pay, Sberbank Online, or YooMoney wallets.
Oldest supported version of android sdk: 21(Android 5).
This repository contains the SDK code and an example of an app which integrates it.
Android Checkout mobile SDK: version $versionName (changelog)
Registering an app for payments via the wallet
If the YooMoney wallet is one of the payment methods, you need to register your app and get authCenterClientId . If not, you can skip this step.
If you’ve already registered apps for oAuth authorization, then you can find the list of your apps on this page: https://yookassa.ru/oauth/v2/client If you haven’t registered apps for oAuth authorization yet, you need to follow these instructions.
- To register a new app, you need to sign in at https://yookassa.ru
- After signing in, go to the page for registering apps: https://yookassa.ru/oauth/v2/client
- Click on the Create app button and enter values for the following parameters:
- Name;
- Description. Optional;
- Link to the website;
- Callback URL: any, you can enter the link to the website;
- Accesses. There are three sections here: YooMoney API , YooMoney wallet , and YooMoney account .
- Give permission to access user’s wallet balance in the YooMoney wallet section. To do that, put a check mark next to the View field in theWALLET BALANCE section;
- Open the YooMoney account section and give permission to access user’s phone number, email address, name, and profile picture. To do that, put a check mark next to the View field in the PHONE NUMBER, EMAIL ADDRESS, NAME, AND PROFILE PICTURE section;
- Click on the Register button and finish the registration;
- A window with information about the registered app will open. You’ll need authCenterClientId to launch tokenization, see (Launching tokenization);
Implementation via Gradle
To implement the library, enter dependencies in build.gradle of the module:
Ask your onboarding manager for the ThreatMetrix Android SDK 5.4-73.aar library. Create a libs folder in the module where you implement the sdk and add the ThreatMetrix Android SDK 5.4-73.aar there. Add the following in build.gradle of the same module in dependencies:
Setting up the app scheme
In order for the sdk to work, you need to set up your app’s scheme for processing deep links. It’s required for payments via sberpay. You need to add resValue «string», «ym_app_scheme», «your_unique_app_shceme» to your build.gradle file in the android.defaultConfig section
Or add a row similar to the following example to your strings.xml:
Where your_unique_app_shceme is a unique name of your app; if you already process deep links in your app, you can use your app’s working scheme. If you haven’t processed deep links in the project before, you can create a unique scheme made of Latin letters for your app.
Configuring the app for selling digital products
If your app is used for selling digital products, you need to remove Google Pay from the list of payment methods. To do that, add the following code to AndroidManifest:
Using the library
The ru.yoomoney.sdk.kassa.payments.Checkout class is used for everything involved in working with the library
The Checkout.createTokenizeIntent() method is used to launch the tokenization process. This method returns Intent which should be launched in startActivityForResult(). After that, control over the process will be transferred to the SDK. You can get a ready-made payment token in onActivityResult() (see Getting tokenization results)
Input parameters of the method:
- context (Context): app’s context;
- paymentParameters (PaymentParameters): payment parameters;
- testParameters (TestParameters): parameters for debugging, see Test parameters and debugging;
- uiParameters (UiParameters): interface settings, see Interface configuration.
- amount (Amount): product price. Available payment methods can change depending on this parameter;
- title (String): product name;
- subtitle (String): product description;
- clientApplicationKey (String): key for client apps from the YooMoney Merchant Profile (Settings section—API keys).;
- shopId (String): store’s ID in YooMoney.
- savePaymentMethod (SavePaymentMethod): configuration for saving payment methods. Saved payment methods can be used for processing recurring payments.
- authCenterClientId (String): app’s ID for sdk authorization ru.yoomoney.sdk.auth , see Registering an app for payments via the wallet.
- paymentMethodTypes (Set of PaymentMethodType): restrictions on payment methods. If you leave the field empty or enter null in it, the library will use all available payment methods;
- gatewayId (String): gatewayId for the store;
- customReturnUrl (String): url of the page (only https supported) where you need to return after completing 3ds. It should only be used if a custom Activity is used for 3ds url. If Checkout.createConfirmationIntent() or Checkout.create3dsIntent() is used, don’t specify this parameter;
- userPhoneNumber (String): user’s phone number. It’s used for autofilling fields for payments via SberPay. Supported format: «+7XXXXXXXXXX».
- googlePayParameters (GooglePayParameters): settings for payments via Google Pay;
- customerId (String): unique customer id for your system, ex: email or phone number. 200 symbols max. Used by library to save user payment method and display saved methods. It is your responsibility to make sure that a particular customerId identifies the user, which is willing to make a purchase. For example use two-factor authentication. Using wrong id will let the user to use payment methods that don’t belong to this user.
Fields of the Amount class:
- value (BigDecimal): amount;
- currency (Currency): currency.
Values of SavePaymentMethod :
- ON: Save the payment methods for processing recurring payments. Only payment methods which support saving will be available to users. A notification that the payment method will be saved will be displayed on the contract screen.
- OFF: Don’t save the payment method.
- USER_SELECTS: User selects if the payment method should be used or not. If a method can be used, a switch will appear on the contract screen.
Values of PaymentMethodType :
- YOO_MONEY: the payment was made via the YooMoney wallet;
- BANK_CARD: the payment was made via a bank card;
- SBERBANK: the payment was made via Sberbank (text message invoicing or SberPay);
- GOOGLE_PAY: the payment was made via Google Pay.
Fields of the GooglePayParameters class:
- allowedCardNetworks (Set of GooglePayCardNetwork): payment systems which can be used for payments via Google Pay.
Values of GooglePayCardNetwork :
Launching tokenization for saved bank cards
This tokenization method is used in case there’s a bank card linked to the store and its csc needs to be requested from the user again. Otherwise, the standard tokenization procedure should be followed (see Launching tokenization).
The Checkout.createSavedCardTokenizeIntent() method is used to launch the tokenization process with a payment ID. This method returns Intent which should be launched in startActivityForResult(). You can get a ready-made payment token in onActivityResult() (see Getting tokenization results)
Input parameters of the method:
- context (Context): app’s context;
- savedBankCardPaymentParameters (SavedBankCardPaymentParameters): parameters of a payment with a saved bank card;
- testParameters (TestParameters): parameters for debugging, see Test parameters and debugging;
- uiParameters (UiParameters): interface settings, see Interface configuration.
Fields of SavedBankCardPaymentParameters :
- amount (Amount): product price. Available payment methods can change depending on this parameter;
- title (String): product name;
- subtitle (String): product description;
- clientApplicationKey (String): store’s token received in YooMoney;
- shopId (String): store’s ID in YooMoney;
- paymentId (String): payment ID.
- savePaymentMethod (SavePaymentMethod): configuration for saving payment methods. Saved payment methods can be used for processing recurring payments.
Fields of the Amount class:
- value (BigDecimal): amount;
- currency (Currency): currency.
Values of SavePaymentMethod :
- ON: Save the payment methods for processing recurring payments. Only payment methods which support saving will be available to users. A notification that the payment method will be saved will be displayed on the contract screen.
- OFF: Don’t save the payment method.
- USER_SELECTS: User selects if the payment method should be used or not. If a method can be used, a switch will appear on the contract screen.
Getting tokenization results
Tokenization result will be returned in onActivityResult() .
Possible result types:
- Activity.RESULT_OK: tokenization completed successfully;
- Activity.RESULT_CANCELED: user has canceled tokenization;
In case of a successful tokenization, the SDK will return a token and the type of the payment tool using which it was received. Use the Checkout.createTokenizationResult() method to receive the token.
Checkout.createTokenizationResult() accepts Intent received in onActivityResult() in case of a successful tokenization as input. It returns TokenizationResult which consists of:
- paymentToken (String): payment token, see Using the payment token;
- paymentMethodType (PaymentMethodType): type of the payment method.
Values of PaymentMethodType :
- YOO_MONEY: the payment was made via the YooMoney wallet;
- BANK_CARD: the payment was made via a bank card;
- SBERBANK: the payment was made via Sberbank (text message invoicing or SberPay);
- GOOGLE_PAY: the payment was made via Google Pay.
Using the payment token
You need to ask your YooMoney manager for permission to process payments using the token. A token can only be used once, it’s valid for 1 hour. If you haven’t created a payment within one hour, you’ll need to request a new token.
The payment token contains information about the payment confirmation scenario. Once you receive the payment token, you’ll be able to create a payment, enter the payment token in the payment_token parameter. If the payment is processed with authentication via 3-D Secure, use confirmation_url receive in the Payment object. Use confirmation_url to run 3-D Secure, see 3DSecure.
Test parameters and debugging
You can add the TestParameters object when calling Checkout.createTokenizeIntent() to debug tokenization.
Fields of the TestParameters: class
- showLogs (Boolean): display SDK logs. All logs start with the ‘YooKassa.SDK’ tag
- googlePayTestEnvironment (Boolean): use Google Pay’s test environment: all transactions processed via Google Pay will use WalletConstants.ENVIRONMENT_TEST . Please note that if you try paying with googlePayTestEnvironment=true, you’ll get a tokenization error. To learn more, see https://developers.google.com/pay/api/android/guides/test-and-deploy/integration-checklist#about-the-test-environment.
- mockConfiguration (MockConfiguration): use a mock configuration. If this parameter is present, the SDK will work in offline mode and generate a test token. You won’t be able to use this token for payments.
MockConfiguration The library has a test mode where you can see how SDK works with different input data. This mode doesn’t require Internet access. Received token can’t be used for payments.
Fields of the MockConfiguration class:
- completeWithError (Boolean): tokenization always returns an error;
- paymentAuthPassed (Boolean): user is always authorized;
- linkedCardsCount (Int): number of cards linked to user’s wallet;
- serviceFee (Amount): commission displayed in the contract;
You can use the UiParameters object for configuring the SDK interface. You can configure interface colors and if the YooMoney logo is displayed or hidden.
Fields of the UiParameters class:
- showLogo (Boolean): show/hide the YooMoney logo on the screen with payment methods.
- colorScheme (ColorScheme): color scheme.
Fields of the ColorScheme class:
- primaryColor (ColorInt): main color of the app. This color will be used for buttons, switches, input fields, etc. We don’t recommend choosing very bright colors (they won’t be seen with a white backgroung) or red (it’ll interfere with the color of error messages).
The SDK contains an Activity for processing 3DS to simplify the integration of payments via bank cards. Don’t specify PaymentParameters.customReturnUrl when calling Checkout.createTokenizeIntent(), if you use this Activity.
Input parameters for Checkout.createConfirmationIntent() :
- context (Context): context for creating Intent ;
- url (String): URL for redirect to 3DS.
- paymentMethodType (PaymentMethodType): selected payment method type.
- colorScheme (ColorScheme): color scheme.
You can receive 3ds results in onActivityResult()
Possible result types:
- Activity.RESULT_OK: notifies that the 3ds process is finished but doesn’t guarantee that it was successful. We recommend requesting the payment status after receiving the result;
- Activity.RESULT_CANCELED: 3ds process has been canceled (for example, if the user tapped the «back» button during the process);
- Checkout.RESULT_ERROR: couldn’t complete 3ds.
Launching 3ds and getting results
Scanning bank cards
Create an Activity which processes action ru.yoomoney.sdk.kassa.payments.action.SCAN_BANK_CARD
Implementing the activity for scanning
Launch your library for scanning cards in this Activity . Enter the card number you received using Intent as shown in the example below. Don’t forget to specify Activity.RESULT_OK if the card was scanned successfully.
Returning the result with activity
About
This library allows implementing payment acceptance into mobile apps on Android. It works as an extension to the YooMoney API.
Источник