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. 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 (deep 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 | 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 /checkout/possdk/v68/sessions request to create a 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.
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:
-
Your POS app creates a Terminal API request that is serialized to JSON, or receives the Terminal API payment request from your backend.
-
The POS app passes the Terminal API request to the Mobile SDK.
-
The SDK checks if the communication session is still valid, and if necessary establishes a new session.
-
The transaction starts on the mobile device.
-
The SDK passes the Terminal API response to your POS app.
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:
- Your POS app creates a Terminal API payment request, or receives a Terminal API payment request from your backend.
- Your POS app sends an encrypted, Base64URL-encoded Terminal API payment request to the Payments app as a deep link with your return URL.
- 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.
- The Payments app routes the payment request through our POS Mobile SDK to the Adyen backend.
- The Adyen backend returns an encrypted, Base64URL-encoded Terminal API payment response to the Payments app.
- On the mobile device, the screen shows the outcome, and switches to your POS app using the return URL you specified.
- Your POS app receives the encrypted, Base64URL-encoded Terminal API payment response.
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:
- Pair their mobile device with the card reader.
- See 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. Here are some example built-in screens.
Firmware updates
The firmware of the card reader must be updated from time to time, to keep the reader secure. Firmware updates have a due date, at which time they become mandatory. This means the card reader cannot process transactions anymore until it is updated to the mandatory firmware 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. In case a firmware update failed because the card reader did not have an active Bluetooth connection when the update required it, the built-in UI shows instructions on how to reset the reader before retrying the update.
