I am tired of accepting payments via webview. What should I do?

    I go to the office by train - you need to go one station, and I will be almost there.

    Every morning I buy train tickets in the app and suffer. It's cheaper there, but the price difference doesn't pay back my pain when I go through these three minutes of stress. Without even mentioning the loading time of each of the five screens of the application, one cannot help saying about the bank WebView with the saved card, entering the code from the SMS on the run and unexpected failures in work.

    This is when you run to the train, and they say “Something went wrong” to you and write off money, but they don't give you a ticket. The return comes immediately, but the train has already left. This happens a couple of times a month, regardless of the quality of the Internet. Neither of which-peiah and say no.

    At this point, you wonder - maybe there is a simpler way? Well, to no webview at all, beautiful and native. And yes, there is such a way. Details under the cut.

    tl; dr We made an interface for accepting payments through Apple Pay, Google Pay, Sberbank mobile bank and Yandex.Money in iOS and Android. No, I do not have to draw payment forms. Yes, it is also in open source.

    In general, there are approximately two payment acceptance scenarios in mobile applications.

    The first is via WebView with a payment page. So you can accept payments through a wallet, bank card, mobile or anything else. The problem is that WebView does not have access to browser cookies, which means that authorization for some payment methods will not work.

    In the second scenario, the merchant passes the card data through its backend - for this you need to comply with PCI DSS, which is expensive, time consuming and difficult.

    Mobile SDK

    Yandex Mobile Cash register SDK is a library for iOS and Android, which we did to simplify the life of merchants, application developers and those who care about their users. In fact, the mobile SDK is a tool for tokenization of bank cards and other payment instruments. Tokenization is an exchange of data that is needed for making a payment, for a unique identifier - a token.

    In the spring, we rolled out the first version of the SDK - there was a payment by card and from the Yandex.Money wallet. Now everything has become even better - in the July release, Google Pay, Apple Pay and payments through Sberbank were added with confirmation by SMS.

    About the benefits

    The main benefit is that the buyer pays with anything, but for the merchant it looks like a single token that can be used instead of payment information.

    There is still no need to pass PCI DSS certification - card data will be processed in our perimeter. We undergo certification every year, we observe all the rules of regulators and we do away with the shops that have connected to the Cashier. So it is possible.

    With the SDK, payments on Android and iOS look familiar to users, and they no longer need to leave the application context at the time of payment. Those who pay from the electronic wallet do not need to log in yet - if the user is logged in to the Money application, you only need to select the account you need through Yandex.Passport.

    How to start using at home?

    If you completely generalize, you need to do two things:

    • Integrate the Yandex.Cashy payment API - for accepting payments;
    • Connect mobile SDK - for tokenization and native interface.

    To add Apple Pay, it is enough to connect the acceptance of payments by bank cards and release the keys in the account of the Apple developer.

    Google Pay is a little different. Need to:

    1. Prepare a test build APK.
    2. Fill in the integration checklist - confirm that your application is not going to capture the world, and a few more things.
    3. Pour the assembly for review in Google Pay.

    Google will check everything and allow (or not allow) to upload the application on Google Play.

    Mobile SDK is embedded in the client application, so that native payments can work through it. It works like this: card details go straight to our PCI DSS perimeter, without getting to the backend of the store. We all check, process and return the payment token to the merchant with a lifetime of 30 minutes - it can be used once.

    The scheme of interaction between the user, the merchant, the mobile SDK and the Ya. Cashier API

    With the participation of the SDK, the payment consists of three stages:

    1. Initiation of payment and receipt of a token. The application initiates the payment through the SDK, and at the output receives the payment token.
    2. Create payment. The token goes to the server that initiates payment through the API.
    3. Request payment status. This is necessary in order to draw the correct window with success or errors.

    Why is it so good?

    1. The architecture is homogeneous in different payment scenarios.
    2. No need to work with a bank card on the backend of the store.

    Pro development and testing

    In the iOS version, we use VIPER and microservices.

    The mobile SDK is based on the tokenization module - it controls the process so that the merchant can only see the token for the Yandex.Cash API at the output, regardless of what the user paid. Another tokenization module decides which window to show the user now, and makes POST requests to the server. We wrote our wrapper for API for working with HTTP / HTTPS requests to YandexMoneyCoreApi - it made life easier.

    Services are storages and objects that work with the Yandex.Cashy client API.
    Their code was clean and concise, without a large number of branches and early exits, because the development department managed to think through the entire architecture in advance. In the SDK services a concentrated amount of functional programming - here we have revealed its capabilities completely. Where we had to work with Functor, Monad, Applicative Functor, ordinary Promise helped us.

    let method = PaymentOptions.Method(oauthToken: clientApplicationKey,
                                               passportAuthorization: passportToken,
                                               gatewayId: gatewayId,
                                               amount: amount,
                                               currency: currency)
            let paymentOptions = session.perform(apiMethod: method).responseApi()
            let allItems = getItems <^> paymentOptions
            let items = paymentMethodHandler.filterPaymentMethods <^> allItems
            let itemsWithEmptyError = items
                .recover(on: .global(), mapError)
            return itemsWithEmptyError

    The only difficulty arose with VIPER - we began to add new types of payment and realized that the central module is growing strongly. When it turned out to be about 1000 lines, we decided that we should do something about it and revise the architecture.

    We liked the idea with the central module of the process, and we decided to leave it. In other projects, we use a deterministic finite state machine to describe the process, but here it would not solve the problems, since the implementation of many things would remain in the same module. So we decided to apply the “strategy” pattern to isolate the processes of each payment instrument. After the user has chosen a payment method, we create a strategy for the payment method that manages the conversion card and decides which process is followed.

    Demo application

    We made it.

    It all started with the fact that the testing department needed something to test the mobile SDK. Without a test application, the guys could not check how the SDK works, and there were no developers for both platforms among the testers.

    In the process, it turned out that, apart from testing tasks, a demo application is a good way to show our partners what a mobile SDK is. Anyone who cannot program in Swift or Kotlin (read: any person) can see how the SDK works. Therefore, we uploaded a demo application on Google Play and an iOS version on the Yandex.Money website.

    It turned out a thing in which you can see how different payment methods work, play with the settings or show it to someone who is responsible for choosing a payment aggregator. Do not be shy.

    Open source

    A few months after the launch, we distributed the library very inconveniently - sharing a link to the site or sending files by mail. Good guys don't do that - they put everything on GitHub under the MIT license. So we did exactly that.

    In addition to tokenization magic, merchants can customize colors, change logos, or make any other changes to the library. And to make it absolutely convenient, we published a mobile SDK in CocoaPods for iOS developers and in Maven for Android guys.

    If you already accept payments through the Cashier, but now you want to make it even better and more productive - connect the mobile SDK. If you just open the store - connect the Cashier. We are fine.

    useful links

    Library for mobile applications
    SDK documentation
    SDK for iOS and Android on GitHub.

    That's all. Ask questions in the comments!

    Also popular now: