To enable the Adyen POS Mobile SDK for Android to handle payments, you need to add code to your Android POS app. This code starts a transaction with:
- A Terminal API request.
- The NFC reader on your mobile device.
After you have added this code, payments take place as follows:
- Your Android POS app creates a Terminal API request that is serialized to JSON, or you receive the Terminal API payment request from your backend.
- You pass the Terminal API request to the Adyen POS Mobile SDK.
- The SDK checks if the session is still valid, and if necessary establishes a new session.
- The transaction starts on your mobile device.
- The SDK passes the Terminal API response to your POS app.
Handle a payment
In your Android POS app, add code for the following steps:
-
If you create the Terminal API payment request in your POS app, use
InPersonPayments.getInstallationId()
asPOIID
in the MessageHeader of the payment request.
Note that if you create the Terminal API payment request in the backend, the backend uses the installationId from the/checkout/posskd/v68/sessions
response.For the structure of a Terminal API payment request, see Make a payment.
-
Create an instance of
TransactionRequest
usingTransactionRequest.create(nexoRequest)
, and pass the Terminal API payment request from your POS app or backend.val transactionRequest = TransactionRequest.create(nexoRequest)
-
Get a
PaymentInterface
fromInPersonPayments
usingInPersonPayments.getPaymentInterface(TapToPay)
.val paymentInterface = InPersonPayments.getPaymentInterface(TapToPay)
-
Register a listener for the
PaymentResult
and pass thetransactionResponse
to your POS app. This is the Terminal API payment response, including data you can use to generate a receipt.InPersonPayments.registerForPaymentResult(context) { result -> result.fold( onSuccess = { paymentResult -> { // Here your logic for paymentResult if (paymentResult.success) "Payment Successful" else "Payment Failed" }, onFailure = { error -> { // Here your logic for failure case }, )
-
Invoke
InPersonPayments.performTransaction()
with your transaction data, payment launcher, and authentication service.Then customize the user interface using
merchantUiParameters
with the following optional fields:merchantLogo
: A logo in WEBP, JPEG, or PNG format to show on your mobile device during the transaction flow. The logo will be shown at 100dp x 32dp (width x height).autoDismissDelay
: Indicates how long the SDK shows the screen that indicates the transaction succeeded. If not specified, this success screen is dismissed after four seconds. You can set a time in milliseconds as a Long with a minimum of 0.5 seconds (500L) and a maximum of 4 seconds (4000L).tapToPayUiParameters
: To choose different UI options for present card screen for Tap to Pay payments. Options forFront
:Center
,TopCenter
, orBottomCenter
. Options forDirectional
:TopCenter
orBottomCenter
.cardReaderUiParameters
: To choose different UI options for present card screen for NYC1 card reader payments. Options forSimplified
:Center
,CenterRight
, orCenterLeft
.
InPersonPayments.performTransaction( context = this@DevAmountEntryActivity, paymentLauncher = paymentLauncher, paymentInterface = result.paymentInterface, transactionRequest = result.transactionRequest, merchantUiParameters = MerchantUiParameters.create( merchantLogo = commonR.drawable.temp_merchant_logo_int, tapToPayUiParameters = TapToPayUiParameters(Front(NfcFrontPosition.TopCenter)), cardReaderUiParameters = CardReaderUiParameters(Simplified(Position.CenterLeft)), ), )
The Adyen POS Mobile SDK checks for a session and shows the transaction screen on your mobile device.
If the shopper does not present their payment method within 30 seconds, the payment request times out. If that happens, you need to make another payment request.
Handle a refund
There are two types of refund: referenced and unreferenced. The main difference is that a referenced refund is connected to the original payment, and an unreferenced refund isn't. That makes unreferenced refunds a bit riskier. For an overview of the differences, see Refund a payment.
Refunds are usually not processed synchronously. When you send a request for a referenced or unreferenced refund, the Terminal API response only confirms we received the request. Unreferenced refunds, however, can be processed synchronously. This depends on the card scheme and the country/region where the card is used. If processed synchronously, you receive an additional field in the Terminal API response: acquirerResponseCode
.
To learn the outcome of a refund, you need to set up webhooks.
Handle a referenced refund
The Terminal API request for a referenced refund is a reversal request. The SDK contains a dedicated function for this.
In your Android POS app, add code for the following steps:
-
If you create the Terminal API reversal request in your POS app, use
InPersonPayments.getInstallationId()
as POIID in the MessageHeader of the payment request.
Note that if you create the Terminal API reversal request in the backend, the backend uses the installationId from the/checkout/posskd/v68/sessions
response.For the structure of the Terminal API reversal request, see Referenced refund.
-
Create an instance of
TransactionRequestReversal
usingTransactionRequestReversal.create(nexoRequest)
, and pass the Terminal API payment request from your POS app or backend. -
Register a listener for the
PaymentResult
and pass thetransactionResponse
to your POS app. This is the Terminal API payment response, including data you can use to generate a receipt.val paymentLauncher = InPersonPayments.registerForPaymentResult(this) { refundResult -> // handle refund response here ... }
-
Invoke
performReversal()
with your transaction data andauthenticationProvider
.
Note thatauthenticationProvider
is an implementation of the AuthenticationProvider interface, which extracts thesdkData
from the server response.public fun performReversal( context: Context, paymentLauncher: ActivityResultLauncher<Intent>, transactionRequestReversal: TransactionRequestReversal, )
-
Check the
refundResult
that you receive in thepaymentLauncher
callback. -
Pass the
refundResult
to your POS app.
Handle an unreferenced refund
The Terminal API request for an unreferenced refund is a payment request with an additional parameter:
PaymentData.PaymentType
: Refund
This means you can use the same code as for handling a payment. The only difference is the structure of the Terminal API payment request that you pass as the payload to the TransactionRequest
.
For the structure of the Terminal API request, see Unreferenced refund.
Testing
To test transactions, you can use the following Adyen point-of-sale test cards:
- White-green test card
- Blue-green test card version 2.4 or later
The instructions are the same for both cards; see either of the pages mentioned above.
Troubleshooting
The Adyen payments platform performs regular checks to make sure that the mobile device on which the SDK is installed is secure. Errors that occur during the security attestation process need to be resolved to make transactions, including Store and Forward payments. Below you can find the table with the most common errors and how to handle them.
Error code | Description | Resolve offline | Required action |
---|---|---|---|
ANDROID_NOT_UPDATED | Transaction canceled. | Update the SDK to the latest software version and try again. | |
DEBUG_ENABLED_APK | Transaction canceled. | In Settings > System > Developer Options turn off Developer Options. | |
DEVELOPER_OPTIONS_ON | Transaction canceled. | In Settings > System > Developer Options turn off Developer Options. | |
INVALID_NYC1_FIRMWARE_VERSION | Card reader firmware version is invalid. | Update NYC1 to the latest software version and try again. | |
LOCAL_TIME_TAMPERING | Transaction canceled. Unable to check the security requirements. | In Settings > System > Date and Time toggle on Automatic date and time. | |
NON_SELF_RESOLVABLE | Transaction canceled. Unable to check the security requirements. | Contact our Support Team to resolve the issue. | |
NO_TOKEN | Cannot transact. | Must go online for SDK to check security requirements. | |
PASSCODE_NOT_ENABLED | Transaction canceled. Device passcode was removed, offline transaction data may have been lost. | In Settings > System > Developer Options set a passcode for this device and try again. All S&F transactions previously performed with passcode will be lost and cannot be recovered. You will not be able to continue transacting in S&F. |
|
SECURITY_PATCH_LEVEL_OUTDATED | Transaction canceled. | Update the SDK to the latest software version and try again. | |
SYSTEM_CHANGE | Transaction canceled. Cannot transact due to system change. | Must go online for SDK to check security requirements. If the date/time of the device was changed, you must change it back to continue transacting. If the device was restarted, it must go online for the SDK to check security requirements. |
|
TOKEN_EXPIRED_S&F | Offline transaction window has expired. | Must go online for SDK to check security requirements. | |
UNSECURED_WIFI_NETWORK | Transaction canceled. | Connect to a secure Wi-Fi network and try again. | |
USB_DEBUGGING_ON | Transaction canceled. | In Settings > System > Developer Options turn off Developer Options. | |
WIFI_DEBUGGING_ON | Transaction canceled. | In Settings > System > Developer Options turn off Developer Options. |