- Getting Started
- Tutorials
- Reference
- API Reference
- Basic Payment
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Corporate
- Merchant
- Cart
- Airline
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Risk
- Point of Sale
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Brands Reference
- API Reference
- FAQ
- Imprint

Mobile SDK
Mobile SDK makes it easy to accept payments in your mobile app on iOS and Android platforms.
This guide shows you how to integrate in-app payments into your mobile shop or build a wallet-style app. The Mobile SDK takes care of the complexity: it routes the payment correctly to your account and handles the interaction with the payment gateway.
Integration scenarios
NOTE: When you are just getting started with your project, we suggest trying our checkout screens to instantly have a full-fledged checkout experience. You can always come back and build your own payment forms later.
How it works in three main steps
2
Send the payment info
using the Mobile SDK
Use the Checkout ID to send the payment info. You can use our Checkout screens or create your own payment form.

Why is a Merchant Server required?
As you can see on the diagram, Merchant Server communicates with your app and our Server (Platform) on steps 1 and 3.
To integrate the SDK you need to expose your backend API first. We did not include this functionality to the SDK due to security reasons. Your authentication details are required for these steps, they should be stored on your server, not in the app.
As you can see on the diagram, Merchant Server communicates with your app and our Server (Platform) on steps 1 and 3.
To integrate the SDK you need to expose your backend API first. We did not include this functionality to the SDK due to security reasons. Your authentication details are required for these steps, they should be stored on your server, not in the app.
Step 1. Get the Checkout ID in order to make the payment using the mSDK
Step 2. Send the payment info using the Mobile SDK
If you are using the SDK with our Checkout Screens:
If you are using the SDK with your own UI:
Step 3. Get the payment status
Key concepts
Checkout ID
The checkout ID is a string returned by your application from your server to represent a unique transaction identificator. This should not be reused; a new checkout ID should be generated for each new customer transaction. Your server is responsible for generating the checkout ID.Your client is responsible to obtaining the checkout ID from your server and initializing the Mobile SDK.
Token
The token is a string returned by the Mobile SDK to represent the stored payment details. Mobile SDK uses this string to obtain the detailed payment information to allow making one-click payment. Your server is responsible for getting and storing the token.Your client is responsible for obtaining the tokens from your server and providing them to the Mobile SDK.
Synchronous & asynchronous payments
To pay with a credit card (that is not enrolled with 3D Secure program) the shopper needs to fill app's payment form with card details. Then he confirms purchase e.g. by clicking "Buy" and the transaction is submitted immediately. It is a synchronous workflow.
If the card is enrolled with 3D, after purchase confirmation the shopper should be redirected to the issuer page to perform the 3D authorization. The transaction will be processed only after successful authentication. It is a typical example of asynchronous workflow. Another example is online banking transfers, in this case customer may need to pass account authentication on issuer bank page (e.g. SOFORT Banking).
Brand | Async / sync workflow |
---|