WebsiteStatusSupportPostman workspacePricingDocumentation hub survey
Documentation
RSS feedSign up
Start typing to search…
  1. Server-to-Server, Mobile SDK, and COPYandPAY
  2. Integrations

Mobile SDK

Mobile SDK simplifies payment acceptance in mobile apps for iOS and Android.

This guide explains how to integrate in-app payments into a mobile shop or build a wallet-style app. Mobile SDK manages the complexity by routing payments and handling interactions with the payment gateway.

🚧
  • Applications using mSDK versions before 6.14.0 with iOS SDK 18 and Xcode 16 may crash due to a UI-related issue.
  • Technical insight: Apple's internal changes affect view initialisation, causing repeated initialisation and crashes.
  • Resolution: mSDK version 6.14.0 includes a fix. Refer to the release notes for details.
  • Recommendation: Upgrade to mSDK 6.14.0 for compatibility with iOS SDK 18 and Xcode 16. Using older versions with these tools may lead to stability issues.
  • Already published applications remain unaffected.
  • If FNB is your acquirer, you cannot use special characters in the merchantTransactionId or merchantInvoiceId parameters and must only use letters and numbers.

Integration scenarios

  • Use ready-made checkout screens with customisation options.
  • Build custom payment forms and checkout processes while using the SDK in the background for transaction processing.
📘

When starting a project, try the checkout screens for a complete checkout experience. You can always build custom payment forms later.

The Mobile SDK works in three main steps:

1. Get the checkout ID

  1. The app sends checkout configuration details, including amount and currency, to the server.
  2. The server forwards this data along with authentication details to the platform to receive the Checkout ID.
  3. The server receives the Checkout ID and sends it back to the app.

2. Send the payment information using the Mobile SDK

If using the SDK with checkout screens:

  1. The app initialises mSDK with the Checkout ID.
  2. The SDK presents the Checkout Screens, processes user input, and submits the transaction.
  3. The SDK returns the payment authorisation status from the platform and passes control back to the app.

If using the SDK with a custom UI:

  1. The app initialises mSDK with the Checkout ID and user payment details.
  2. The SDK submits the transaction and returns the payment authorisation status from the platform.

3. Get the payment status

  1. The app sends the Checkout ID to the server.
  2. The server forwards the Checkout ID along with authentication details to the platform to request the payment status.
  3. The server receives the payment status and sends it back to the app.

Key concepts

Checkout ID

The server creates a checkout ID, a unique transaction identifier that merchants must generate for each customer transaction. The client retrieves the checkout ID from the server and initialises the Mobile SDK.

Token

The Mobile SDK returns a token, which represents stored payment details. The Mobile SDK retrieves payment information using this token for one-click payments. The server obtains and stores the token, while the client retrieves it and provides it to the Mobile SDK.

Synchronous and asynchronous payments

For a credit card that does not require 3-D Secure authentication, the customer enters card details in the app's payment form and confirms the purchase, such as by clicking "Buy". The transaction follows a synchronous workflow, processing straight away.

If the card requires 3-D Secure, the customer confirms the purchase and completes authentication on the issuer's page. The transaction processes after successful authentication, following an asynchronous workflow.

Online banking transfers also use an asynchronous workflow. The customer may need to authenticate on the issuer's bank page (example: SOFORT Banking) before the payment completes.

Integration support

Peach Payments provides support for native integrations, covering iOS and Android.

Peach Payments does not support hybrid integrations because they mix native and web technologies, often leading to performance and compatibility issues. These problems disrupt the user experience and payment processing reliability. Focusing on native integrations ensures optimal performance, security, and seamless mobile payments. This approach maintains high-quality support and protects the integrity of payment solutions.

Privacy policy for Android Mobile SDK integration

Merchants should involve fraud prevention, security, and compliance teams to update the privacy policy. You must explain how your app handles user data, including device information.

That means disclosing how your app accesses, collects, uses, handles, and shares user data while limiting its use to disclosed policy-compliant purposes. The following data fields require careful handling during 3-D Secure 2.x authentication:

  • Advertising ID
  • Latitude
  • Longitude
  • Device ID (not used in API level 29 or higher)
  • Subscriber ID (not used in API level 29 or higher)
  • Group identifier level
  • Phone number
  • SIM serial number (not used in API level 29 or higher)
  • WiFi MAC address
  • Bluetooth adapter hardware address
  • Array of paired Bluetooth device MAC addresses
  • Array of paired Bluetooth device aliases
  • Build identifier string
  • Hardware serial number (not used in API level 29 or higher)
  • Installed applications

Privacy policy for iOS Mobile SDK integration

The iOS SDK includes a privacy information manifest file that describes how required API functions and data usage work.

The following are the Privacy Accessed API Types:

  • File timestamp

Merchants should create a privacy information manifest file inside the app bundle when using more APIs that require justification.

Mobile SDK and PCI compliance

Peach Payments' mobile SDK allows you to build native apps for iOS and Android, enabling direct integration with the hosted payment platform. However, the SDK itself does not process card data.

PCI DSS AOC scope

The mobile SDK enables native applications for both iOS and Android platforms. Designed for seamless payment integration, it connects mobile applications to the hosted platform endpoint for payment processing. The mobile SDK itself does not function as a hosted service for processing card data.

Scope of PCI DSS AOC: The PCI DSS Attestation of Compliance (AOC) covers hosted products and solutions, such as COPYandPAY and Server-to-Server.

Client environment: This certification does not extend to any libraries, products, or solutions installed in your environment, including the mobile SDK.

Updated about 7 hours ago