---
title: "Understand the Android Mobile solutions"
description: "Learn about concepts and transaction flows relevant for choosing a Mobile solution."
url: "https://docs.adyen.com/point-of-sale/mobile-android/understand"
source_url: "https://docs.adyen.com/point-of-sale/mobile-android/understand.md"
canonical: "https://docs.adyen.com/point-of-sale/mobile-android/understand"
last_modified: "2025-10-06T15:31:00+02:00"
language: "en"
---

# Understand the Android Mobile solutions

Learn about concepts and transaction flows relevant for choosing a Mobile solution.

[View source](/point-of-sale/mobile-android/understand.md)

This page explains various concepts that our Mobile solutions are based on, and provides information to help you choose which Mobile solution to build. You can choose to:

* Integrate our Mobile SDK into your POS app, to accept Tap to Pay and/or card reader payments.
* Let your POS app communicate with an Adyen Payments app that already includes the Mobile SDK, to accept Tap to Pay payments.

## SDK or Payments app

Both when integrating the Mobile SDK and when using the Payments app, your POS app must be integrated with [Terminal API](/point-of-sale/design-your-integration/terminal-api#api-structure). And in both cases you have to work on the backend as well as on the frontend.

It depends on your use case and development capacity which solution is the most suitable. You may prefer a low-code integration without PCI Mobile Payments on COTS (MPoC) compliance requirements, or a more involved integration that allows more control of the app experience.

Also note that the same Mobile SDK is used for Tap to Pay and card reader payments. If your POS app allows selecting the payment interface, both solutions can be used alongside each other. The Payments app on the other hand only supports Tap to Pay.

The following table shows the pros and cons of each solution.

| Mobile SDK                                                                                                 | Payments app                                |
| ---------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| **Pros**                                                                                                   | **Pros**                                    |
| Full control of the in-app experience                                                                      | Lower integration effort (Links & API)      |
| Better UX: no app switching                                                                                | Adyen handles updates                       |
| Better payment performance                                                                                 | No PCI MPoC compliance requirements         |
| Supports Tap to Pay and card reader                                                                        |                                             |
| **Cons**                                                                                                   | **Cons**                                    |
| Update SDK version every six months                                                                        | Payments app must be boarded on each device |
| [PCI MPoC compliance requirements](/point-of-sale/mobile-android/security#pci-dss-compliance-requirements) | App switching during the payment flow       |
|                                                                                                            | Only supports Tap to Pay                    |

## Communication session

When you integrate the Mobile SDK into your POS app, the SDK has to communicate in a secure way with the Adyen payments platform. To enable this, you must integrate a server-to-server POST [/auth/certificate](https://docs.adyen.com/api-explorer/softpos-configuration-api/latest/post/auth/certificate) request to establish a secure communication session. Your POS app needs to call your backend to trigger this request and get the session data.

The SDK uses the session data from the response to authenticate with our payments platform. Because the session expires after some time, the SDK checks regularly if it needs to establish a new session.

![Authentication flow](/user/pages/reuse/pos-mobile-sdk/communication-session/ipp-mobile-authentication-flow.svg?decoding=auto\&fetchpriority=auto)

## SDK transaction flow

If you use or build a Mobile solution where our Mobile SDK for Android is integrated into your POS app, transactions take place as follows:

1. Optional but recommended: your POS app calls a warm-up function to speed up initiating transactions.

2. Your POS app creates a Terminal API request that is serialized to JSON, or receives the Terminal API payment request from your backend.

3. The POS app passes the Terminal API request to the Mobile SDK.

4. The SDK checks if the communication session is still valid, and if necessary establishes a new session.

5. The transaction starts on the mobile device.

6. The SDK passes the Terminal API response to your POS app.

![](/user/pages/reuse/pos-mobile-sdk/sdk-flow/ipp-mobile-sdk-flow-ios.svg?decoding=auto\&fetchpriority=auto)

## Payments app transaction flow

If you use or build a Mobile solution where your POS app communicates with the Adyen Payments app, transactions take place as follows:

1. Your POS app creates a Terminal API payment request, or receives a Terminal API payment request from your backend.
2. Your POS app sends an encrypted, Base64URL-encoded Terminal API payment request to the Payments app as an App Link with your return URL.
3. On the mobile device, a Tap to Pay screen appears, and the shopper presents their contactless payment method to the NFC reader of the device.
4. The Payments app routes the payment request through our POS Mobile SDK to the Adyen backend.
5. The Adyen backend returns an encrypted, Base64URL-encoded Terminal API payment response to the Payments app.
6. On the mobile device, the screen shows the outcome, and switches to your POS app using the return URL you specified.
7. Your POS app receives the encrypted, Base64URL-encoded Terminal API payment response.

## PIN transactions

It is possible to make PIN transactions in your Tap to Pay and card reader solution. Unlike traditional payment terminals with physical keypads, PIN entry on a mobile device requires specialized security measures to protect the shopper's data. To comply with [PCI MPoC compliance requirements](/point-of-sale/mobile-android/security/#pci-mpoc-compliance-requirements), the PIN entry pad is not always centered on the mobile device screen. Instead, it appears in a random position as shown in the following examples.

|                                                                                                           |                                                                                                       |
| --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Bottom-left ![](/images/a/3/1/1/a/a311af9179d969cc987fe320f9aca3230737fbd9-screen-enpin-pad-centered.png) | Top-right ![](/images/d/0/7/4/e/d074e65a5e3dd81c2ba63de57b2790ac4f0ecc3e-screen-enpin-pad-random.png) |

### PIN transaction with a card reader in the US

You need an NYC1 card reader with PIN support [for secure PIN transactions](/point-of-sale/mobile-android/requirements#card-readers).

NYC1 card readers with PIN support require Mobile SDK version 2.4.0 or later.

In the US, not all NYC1 card readers support PIN. You can check if your card reader supports PIN transactions in the following ways:

* By checking the \[`connectedDevice.model`] . Returns the model of the card reader. The result can be:

  * **SCRP** (card reader supports PIN).
  * **SCR** (card reader does not support PIN).

* In the [built-in UI](/point-of-sale/mobile-android/understand#ui-for-card-reader-operations): If under **Device Info** the field **Model** is present, you have an NYC1-SCR card reader that does not support PIN. If the field **Model** is not present, you have an NYC1 that supports PIN.

  | Device info for NYC1-SCR                                                                                                  | Device info for NYC1                                                                                                   |
  | ------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
  | Card reader not suitable for PIN ![](/images/8/2/6/2/e/8262ee89b277fa88191c823ff3fc0d13e196e70f-screen-enandroid-scr.png) | Card reader suitable for PIN ![](/images/f/1/a/0/e/f1a0e2c1e4eef33160ae1764fd4d0c16e9098731-screen-enandroid-scrp.png) |

If you want to disable PIN support on your NYC1 card reader, [refer to card reader requirements](/point-of-sale/mobile-android/requirements#card-readers)

## UI for card reader operations

If your Mobile SDK solution uses NYC1 card readers as the payment interface, the people operating the readers need to:

* Connect their mobile device with the card reader through Bluetooth pairing or direct USB (if the Android device supports USB host mode).
* View an overview of card readers. For example, to switch to a different card reader.
* View details of the card reader they are using. For example, to check the battery charge level.
* Update the firmware of the card reader they are using.

The SDK allows you to build your own UI for those tasks, but also provides a built-in UI as shown in the following examples.

![](/user/pages/docs/03.point-of-sale/55.mobile-android/05.understand/screen-EN_Reader2x.jpg)

The following sections provide some example built-in screens for specific tasks:

* [Bluetooth pairing](#bt-pairing)
* [Updating the card reader firmware](#updating-card-reader)

If your solution uses the NYC1 card reader in combination with the NYC1 dock, users also need to be able to connect to the card reader through USB and update the dock firmware. See [UI for dock operations](#usb-dock).

### Bluetooth pairing

The built-in UI screens guide the reader through the process of connecting their mobile device to a card reader through Bluetooth.

![](/user/pages/docs/03.point-of-sale/55.mobile-android/05.understand/pairing-new.gif?decoding=auto\&fetchpriority=auto)

### Updating the card reader firmware

The firmware of the card reader must be updated from time to time, to ensure secure transaction processing.

You must check for new firmware updates regularly, and update your card readers to the latest version.

Our built-in UI shows a red indicator when a new firmware version is available for the connected card reader, and has an **Update** button to start the firmware update. A firmware update can fail when the card reader does not have an active Bluetooth connection when the update requires it. In this case the built-in UI shows instructions on how to reset the reader before retrying the update.

![](/user/pages/docs/03.point-of-sale/55.mobile-android/05.understand/reader-update-trimmed.gif?decoding=auto\&fetchpriority=auto)

If you use your own custom UI, it is required that you [build logic into your POS app](/point-of-sale/mobile-android/build/card-reader/?tab=build_a_custom_ui_1_2#updating-card-reader) to check for new card reader firmware updates and handle the firmware update flow correctly within your POS app.

## UI for dock operations

If your Mobile SDK solution uses card readers as the payment interface in combination with docks, the people operating the readers need to:

* Connect their mobile device with the card reader through the dock.
* Update the firmware of the dock they are using.

The SDK allows you to build your own UI for those tasks, but also provides a built-in UI.

The following sections provide some example built-in screens for specific tasks:

* [Connecting to a dock](#connecting-usb-dock)
* [Updating the dock firmware](#updating-usb-dock)

### Connecting to a dock

In addition to Bluetooth, card readers can be connected through USB. The user's mobile device is connected to a dock using a USB-C cable, and the card reader is placed in the dock. The SDK recognizes the situation, and presents built-in UI screens to inform the reader about the USB connection.

![](/images/6/7/9/4/c/6794c2e423e68437b6be91b6a3a678251546df83-screen-endock-connected.jpg)

Note that it is also possible to place the card reader in the dock but [connect the mobile device to the reader through Bluetooth](#bt-pairing). In that case the dock and the user's mobile device are *not* connected with a USB-C cable. This is a way to charge the card reader through the dock in a countertop setup.

### Updating the dock firmware

The firmware of the dock must be updated from time to time, to ensure secure transaction processing.

Our built-in UI shows a red indicator when a new firmware version is available for the connected dock, and has an **Update** button to start the firmware update.

![](/user/pages/docs/03.point-of-sale/55.mobile-android/05.understand/dock-update-trimmed.gif?decoding=auto\&fetchpriority=auto)

If you use your own custom UI, it is required that you [build logic into your POS app](/point-of-sale/mobile-android/build/card-reader/?tab=build_a_custom_ui_1_2#updating-usb-dock) to check for new card reader firmware updates and handle the firmware update flow correctly within your POS app.

## Kiosk mode

Kiosk mode is intended to optimize the UI for Tap to Pay transactions on larger screens, for example on Android tablets.

Kiosk mode includes the following UI adjustments for usability and security:

* **Increased text and icon size**: Text elements and icons shown during the transaction are enlarged for improved readability on larger screens.
* **Compact PIN keypad**: The on-screen keypad used for PIN entry is reduced in size. This minimizes the risk of bystanders observing the customer's PIN entry.

According to the PCI MPoC compliance requirements, your Tap to Pay on Android solution must not use Kiosk mode in an unattended environment.

Kiosk mode activates automatically at the start of the transaction process if the SDK detects a mobile device with a screen width greater than or equal to 9 inches. It is possible to [enable Kiosk mode on devices ](/point-of-sale/mobile-android/build/tap-to-pay/#apply-kiosk-mode-on-all-smaller-tablets)with a screen width smaller than 9 inches. You can also [customize the placement of the NFC tap indicator](/point-of-sale/mobile-android/build/tap-to-pay/#customize-position-of-nfc-tap-indicator-in-kiosk-mode) in kiosk mode. The indicator can either be a static image of an NFC logo or an animated chevron-type arrow.

## Next steps

[![](/user/themes/adyen/images/illustrations/wrench.svg)](/point-of-sale/mobile-android/build)

###### [Build your solution](/point-of-sale/mobile-android/build)

[Follow steps to build and Android Tap to Pay, Card reader, or Payments app solutions.](/point-of-sale/mobile-android/build)

[![](/user/themes/adyen/images/illustrations/settings.svg)](/point-of-sale/mobile-android/manage)

###### [Manage your solution](/point-of-sale/mobile-android/manage)

[Enable and maintain your solution and keep the software up-to-date.](/point-of-sale/mobile-android/manage)

[![](/user/themes/adyen/images/illustrations/close.svg)](/point-of-sale/mobile-android/troubleshooting)

###### [Error handling](/point-of-sale/mobile-android/troubleshooting)

[Resolve errors that appear on the mobile Android device.](/point-of-sale/mobile-android/troubleshooting)
