Ingenico Direct Support Site

Results for

icon-search-large No search results yet
Enter your search query above

1. Introduction

Mobile payments are becoming more and more important to your online transaction 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, including “native” in-app payments. We offer you all the tools you need to 

  • Create an optimal payment experience
  • Have maximum data security through your applications

2. Understand SDK logic

Our dedicated Client SDKs implement the Client API:

icon-ios

Objective-c

Our native SDK for iOS supports iOS 9.0 and up out-of-the box.

Read the documentation

Download from GitHub

icon-android

Android

Our native SDK for Android supports API level 16 and up. This means you can use it from Android 4.1 (JellyBean) is the lowest supported Android version.

Read the documentation

Download from GitHub

icon-javascript

JavaScript

Our JavaScript SDK supports ECMAScript 3 and up out-of-the box. No external dependencies.

Read the documentation

Download from GitHub

Swift

Our Swift SDK supports iOS 9.0 and up out-of-the-box.

Read the documentation

Download from GitHub

One of these SDKs’ main functions is to establish a secure channel between your native app and our sever. This channel processes security credentials to guarantee the safe 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 server (your dedicated server running the payment application)
  • Your mobile application (your app your customers use on their mobile devices for the payment)
  • Our platform (our system processing the transaction)

A typical interaction flow of these three components goes like this:

  1. The Client API exposes REST endpoints that mobile devices can access directly
  2. The Server API exposes REST endpoints accepting data from native clients going through your e-commerce server
  3. Your e-commerce server that communicates with the Server API and your app
  4. Your app that communicates with your e-commerce server and the Client API
  5. The Client SDK (Native SDK) that implements the logic to connect the app with the Client API for an optimal user experience
  6. The Server SDK that implements the logic to connect your e-commerce server with the Server API

The graph above illustrates how the Client SDK interacts with the different players in a mobile transaction

Mind that you need to define the architecture between your app and your e-commerce server on your own. The graphic above defines this connection with “Your own app API”. Our mobile payment flow graphic covers this in steps 2/15

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.

3. Understand SDK main components

Our SDKs provide you with the following core components to help you implement native payments in your apps:

Every SDK also has a corresponding native example implementation of payment screens, using all the aforementioned features

Have a look at how these core functionalities work step-by-step during in a mobile payment flow.

4. Understand mobile payment flow

A typical flow for a mobile payment looks goes like this:

  1. Your customers finalise an order in your app
  2. Your app sends the order request to your e-commerce server via your own API
  3. Your e-commerce server initiates a session on behalf of the mobile app with our platform
  4. Our platform returns a sessionid and a customerid
  5. Your server provides both the sessionid and a customerid to your app
  6. Your app uses these session details to get available payment products
  7. For the actual payment, your app gets a public a-symmetric key
  8. Your app encrypts your customers' sensitive data (i.e. credit card numbers) using a unique one-time password to prevent replay attacks
  9. Your app sends the encrypted data to your e-commerce server using PreparedPaymentRequest
  10. Your e-commerce server sends the encrypted data (and if needed additional data) in property encryptedCustomerInput to our platform via the Server API
  11. Our platform uses the private key to decrypt the data
  12. Our platform sends the decrypted data to the acquirer to processes the payment
  13. Our platform receives the transaction result in real-time
  14. Your e-commerce server request the payment result via the Server API
  15. Your provide the payment result to your app via your own API

mobileSDK2.png

The graph above explains all the steps of a typical mobile payment flow.

This flow includes encryption/decryption steps 8-11 for credit card payment methods. These steps are not included for third party redirection payment methods (i.e. Paypal)

5. Get started with SDK

To get an idea how to start creating your own app, download the example app in your preferred IDE. Have a look around to understand how the app uses the SDK main components and the communication with our Client API. We recommend to minimise changes to the cryptography code to ensure it works with all our payment products.

  • All major mobile platforms have specific rules about offering products involving external parties. As Worldline is considered as such, make sure that your app complies with the platform’s regulations regarding payment services. This will ensure your target platform’s approval
  • Make sure to also have a look at our best practices for mobile payments