The Adyen mobile payments solution provides merchants with an SDK (version TBD) that they need to integrate into their POS application. The SDK allows them to start online transactions with and without PIN using one of the following payment interfaces:
- Tap to Pay.
- Card reader.
Supported devices and operating system versions
-
Supported operating system versions: Android 11 and later.
-
Supported COTS device types — non-rooted Android smartphone or tablet with:
- NFC reader.
- Support for hardware key attestation.
-
Supported card readers: Adyen card readers NYC1-SCR and NYC1-SCRP.
Adyen NYC1 card readers
There are two PCI-approved secure card readers that can be used in our mobile payments solution: NYC1-SCR and NYC1-SCRP.
For both readers, add info about the MSR (hardware, firmware and validation details; supported functionality)
NYC1-SCR
The NYC1-SCR is a secure card reader that doesn't support PIN. This device is approved by the PCI Security Standards Council (SSC) with the following details.
- Approval number: 4-30492.
- Version: 6.x
- Approval class: SCR
- Expiry date: April 30, 20
- SRED key management: Triple DES and AES DUKPT.
- Functions: ICC reader, contactless reader, and magnetic stripe reader in accordance with OP and SRED requirements.
For more information, see:
NYC1-SCRP
The NYC1-SCRP is a secure card reader that supports PIN. This device is approved by the PCI Security Standards Council (SSC) with the following details.
- Approval number:
- Version:
- Approval class: SCRP
- Expiry date:
- SRED key management:
- Functions:
For more information, see:
- NYC1-SCRP security policy
- Our operational guidance for end users
Communication flow
Transactions start in the merchant's app. To start a transaction, the merchant needs to create a Terminal API payment request and specify the payment interface to use. The payment request initializes our SDK.
The next step is to ensure a valid authentication session exists. If there is no valid session, the merchant needs to send an authentication session request. This request contains a setupToken that is sent from the app to the merchant’s server, and from the merchant's server to Adyen, in order to validate the authenticity of the app. It is the merchant's responsibility to authenticate their app and to secure the communication with their own server.
When an authentication session is established, the SDK communicates directly with Adyen's servers for tasks like loading encryption keys, getting updated configurations, and initializing the transaction.
The authentication step establishes a secure communications channel between the SDK and the Adyen servers. For details, see Mutual authentication.
SDK boundaries
To improve security, some functionality is implemented in a native layer. This ensures stronger obfuscation and makes it harder for bad actors to use mechanisms like hooking and debugging.
Modular structure
We modularized our code for separation of concerns and improved build times. Each module is a separate library. Merchants only interact with the top library, shown in yellow in the following diagram. The other libraries come as transitive dependencies.
