Integration für Mobilgeräte

Introduction

Mobile payments are becoming more and more important to your online transactional business. Thus, you want to offer your customers an attractive payment experience on mobile devices.

Our modern RESTful API supports payments from all mobile platforms. For each platform, we have created SDKs that support full integration and provide payment tools, including "native" in-app payments.

We offer all the tools you need to

• Create a great experience.
• Help you enhance data security through your applications.
• Support many technologies and most devices available on the market.

SDK Communication Structure

One of these SDKs' main functions is to establish a secure channel between your application and our server. This channel processes security credentials to secure the transit of your customers' data during the payment process.

But there is a lot more to it! Together with our server SDKs, the Client SDKs create a secure and stable connection between.

• Your Client application – your app that your customers use for payment.
• Your server – your dedicated server running the payment application.
• Our platform – our system processing the transaction.

By isolating these three components, we can determine a typical interaction flow:

• Client application
  • Uses the Client API via the Client SDKs, which exposes REST endpoints that mobile devices can access directly.
  • Implements the logic to connect the app with the Client API for an optimal user experience.
  • Communicates with your application server.
• Server
  • Uses the Server API via the Server SDKs, which exposes REST endpoints accepting data from the Client application going through your e-commerce server.
  • Implements the logic to connect your application server with the Server API.
  • Communicates with your Client application.

The graph below illustrates how the Client SDK interacts with different components in the system:

To learn more about how exactly our Client SDKs establish the links between these elements, have a look at the SDKs’ main components and a typical mobile payment flow in the following sections.

Main SDK Modules

Our SDKs provide you with the following core features to help you implement native payments in your Client applications:

• Encryption of sensitive data: Cryptography support.
• Objects used in SDK: Wrapping the Client API and the Server API responses to native platform objects.
• AssetManager: Getting and managing related assets.
• Localisation: Easy localisation on your custom views.
• Data validation: Field validation and value presentation.
• Issuer identification number (IIN) check: Support to identify the brand from the card number.
• Logging: Communication logging support.

Mobile Payment Flow

The payment process can be divided into four stages:

1. Transaction initialisation
2. Payment product selection
3. Payment processing
4. Payment finalisation

Have a look at the description of stages below to see what exactly the payment process looks like.

1. Transaction initialisation

1. The Customer makes a purchase using the Client app.
2. The Client app initiates the payment and sends an initial request to the Merchant Server.
3. The Merchant Server receives initial request and initiates the session through the Server API.
4. The Server API returns session data to the Merchant Server.
5. The Merchant Server passes session details to the Client app.
6. The Client app creates a client SDK session on the basis of the received session details.

2. Payment product selection

1. The Client app sends a request for available Payment Products through the Server API.
2. The Server API returns available Payment Products for current Session.
3. The Client app processes the received data in order to display it.
4. The Client app displays the Payment Product selection page to the Customer.

3. Payment processing

Depending on the payment product, differences apply:

For card payments

1. The Customer selects a Payment Product.
2. The Client app processes the selected Payment Product.
   2'.(optional) The Client app processes account on files if they exist.
3. The Client app displays fields to fill in.

For native payments and payments with a third-party payment provider

1. The Customer selects a Payment Product.
2. The Client app processes prepares the action to be performed.
3. The Client app triggers the desired action.

4. Payment finalisation

1. The Customer fills in the fields of the selected Payment Product and processes payment.
2. The Client app validates provided field values.
3. The Client app sends a request for an asymmetric public key via the Server API.
4. Our platform returns a public asymmetric key.
5. The Client app encrypts the provided and validated values with the public key.
6. The Client app sends encrypted data to the Merchant server.
7. The Merchant server transmits encrypted data through the Server API.
8. Encrypted data is decrypted with a private key.
9. The decrypted data is forwarded to the Acquirer.
10. The Acquirer sends a transaction result.
11. The Merchant server receives a transaction result.
12. The Client app receives a transaction result.
13. The Client app displays a transaction result page.

5. Get started

To get an idea how to start creating your own app, download the example app in your preferred IDE. Every SDK also has a corresponding native example implementation of payment screens, using all the aforementioned features.

Have a look around to understand how the app uses the SDK main modules and the communication with our Client API. Make sure to also have a look at our best practices for mobile payments.