Worldline Tap on Mobile Integration Validation Process

Version: 1.9

Introduction

This document describes end-to-end test scenarios for an integration partner’s business application integrating the Tap on Mobile payment application on iPhone or Android.

The goal is to validate various aspects of an integration, such as installation, terminal activation, card payments, cancellations, refunds, DCC, optional APM flows, and transaction visibility in the test environment, before allowing the integration to go to production.

At the end of implementation, the integration partner should execute these scenarios step by step in the sandbox environment already provided by Worldline. The partner should confirm execution to their integration contact so that Worldline can validate the integration by checking the log files and the information requested in this document.

Target audience: Integration partners integrating Worldline Tap on Mobile with their business application and intending to move to production.

In scope

• App installation and sandbox setup
• Terminal activation and merchant configuration
• Card payment flows (below/above CVM)
• Transaction cancellation and refunds (if supported)
• DCC activation and usage
• App restart and persistence checks
• Transaction history and portal validation
• Idle-time stability (8-hour inactivity)
• Optional APM / QR payments

Out of scope

• Performance/load testing
• PCI certification testing
• Acquiring-related functionalities, such as production settlement and reconciliation
• Integrations other than Tap on Mobile integrations

Prerequisites

An existing Tap on Mobile integration

These tests require an ongoing Tap on Mobile integration. The integration partner must have requested to start the integration process, followed the implementation guidelines available on the Worldline Developer Portal, and been granted access to the Worldline Tap on Mobile Sandbox environment.

Devices and technical requirements

iPhone

• iOS version supported by Tap on Mobile (at the time of writing, iOS 18.4 or later)
• iPhone 11 or later
• Internet connection (Wi-Fi or mobile data)

Android

• Android device with Android 11 or later (at the time of writing)
• Google Certified and GMS (Google Mobile Services)
• Android device with NFC
• Internet connection (Wi-Fi or mobile data)

Environment

• Tap on Mobile Sandbox app
• Development SDK, if applicable
• Tap on Mobile Sandbox back-office portal access

For WMI / Backend-to-Backend activation:

• OAuth2 credentials

Scenarios to be executed by the integration partner

These test scenarios must be conducted by the integration partner once app development is finished.

Scenario execution framework

Enter the test details in the test-results table to help Worldline analyse the logs accordingly.

Clean installation

Relevance: ☒ Android · ☒ iOS

Objective

• Ensure no previous Tap on Mobile instances (app or SDK) interfere with testing.
• Verify that a first installation on a new device will work.

Important: N/A

Steps

1. On the device, locate any existing Tap on Mobile application and merchant application.
2. Uninstall all the aforementioned applications completely.
3. Restart the device.

Expected results

• No Tap on Mobile app (app or SDK) is present on the device.
• No merchant app is present on the device.
• The device is ready for clean installation.

Status of the integration: ☐ Passed · ☐ Failed

Install app (sandbox)

Relevance: ☒ Android · ☐ iOS

Objective

• Validate correct installation using the sandbox environment.

Important: N/A

Steps

1. Install the Tap on Mobile app configured for sandbox.
2. Install the merchant app.
3. Launch the merchant app.

Expected results

• Tap on Mobile is installed successfully.
• The merchant app starts without errors.
• On Tap on Mobile, the welcome screen displays the app version, clearly showing -SNB at the bottom-right corner.

Status of the integration: ☐ Passed · ☐ Failed

Manual terminal activation (if supported)

Relevance: ☒ Android · ☐ iOS

Objective

• Manually activate a terminal.
• Confirm the target operating system used by the integration partner meets the requirements.

Important: N/A

Steps

1. Open the Tap on Mobile app.
2. Begin and finalise the terminal activation process.

Expected results

• The terminal activates successfully:
  • The Terminal ID (TID) is displayed in the app menu.
  • The terminal status shows Active in the Tap on Mobile back office.

Status of the integration: ☐ Passed · ☐ Failed

WMI / Backend-to-Backend terminal activation

Relevance: ☒ Android · ☒ iOS

Objective

• Validate the correct implementation of terminal activation with backend-to-backend communication.

Important

• Only valid if using WMI or backend-to-backend integration.

Steps

1. Perform an action chosen by the integration partner to trigger terminal activation.

Expected results

• The terminal activates successfully.
• The terminal status shows Active in the Tap on Mobile back office.

Status of the integration: ☐ Passed · ☐ Failed

Accepting merchant T&C

Relevance: ☐ Android · ☒ iOS

Objective

• Validate the Apple merchant Terms & Conditions (T&C) acceptance flow.

Important: N/A

Steps

1. Apple merchant Terms & Conditions can be accepted within the mobile app or using the portal.
2. The preferred solution for integrations is using the portal (supported as of version 5.15 of the backend).
3. If T&C have been accepted on the portal, no T&C screen should appear, and the card reader should be ready at the first start of Tap on Mobile.
4. If T&C have not yet been accepted for this merchant, a system screen will appear that allows the merchant to accept them.
5. Once T&C have been accepted for this merchant, the screen should never appear again.

Expected results

• The T&C screen is optionally presented, and the merchant can accept the T&C.
• The T&C screen is only presented once.

Status of the integration: ☐ Passed · ☐ Failed

First card transaction

Relevance: ☒ Android · ☒ iOS

Objective

• Validate an initial card payment initiated from the partner business application.

Important: N/A

Steps

1. From the merchant app, initiate a transaction.
2. Proceed with payment.

Expected results

• The transaction is processed successfully.
• The transaction is approved and appears as Cleared in the back office.
• A payment confirmation screen is displayed either in Tap on Mobile or within the merchant app.

Status of the integration: ☐ Passed · ☐ Failed

Transaction with reference (if supported)

Relevance: ☒ Android · ☒ iOS

Objective

• Validate that the merchant app properly uses the reference field for a transaction.

Important

• If always using a transaction reference, this test can be validated with the previous scenario.

Steps

1. From the merchant app, initiate a transaction including a transaction reference.
2. Proceed with payment.

Expected results

• The transaction is processed successfully.
• The transaction is approved and appears as Cleared in the back office.
• The reference is properly displayed in the back office.

Status of the integration: ☐ Passed · ☐ Failed

Cancel transaction at card read screen

Relevance: ☒ Android · ☒ iOS

Objective

• Validate cancellation before card tap for a transaction initiated by the merchant app.

Important: N/A

Steps

1. From the merchant app, initiate a transaction.
2. From the Tap on Mobile payment screen, press Cancel.

Expected results

• The merchant app handles the transaction as a cancelled transaction.

Status of the integration: ☐ Passed · ☐ Failed

Incorrect PIN

Relevance: ☒ Android · ☒ iOS

Objective

• Validate the behaviour of the merchant app for an incorrect PIN.

Important

• The amount entered must match the predefined value so that it is recognised by the mock within Tap on Mobile.

Steps

1. From the merchant app, initiate a transaction for an amount of 42.55.
2. Proceed with payment.
3. The payment is declined for incorrect PIN.

Expected results

• If using its own cardholder receipt, the merchant app handles the incorrect PIN response properly and displays a clear message to the customer.

Status of the integration: ☐ Passed · ☐ Failed

App restart and configuration persistence

Relevance: ☒ Android · ☒ iOS

Objective

• Validate the behaviour of the merchant app when restarted.

Important

• From the logs, Worldline will be able to monitor the behaviour of the merchant app towards Tap on Mobile upon restart.

Steps

1. Close the merchant app (either by browsing the open apps or from the settings on Android).
2. Restart the merchant app.

Expected results

• Tap on Mobile remains registered.
• No unnecessary requests are performed to Tap on Mobile or the backend upon restart.

Status of the integration: ☐ Passed · ☐ Failed

Timeout management

Relevance: ☒ Android · ☒ iOS

Objective

• Validate the merchant app behaviour in case of a timeout in Tap on Mobile.

Important

• Tap on Mobile has its own timer for a timeout transaction, and the merchant app should handle it properly.

Steps

1. From the merchant app, initiate a transaction either below or above the CVM limit.
2. Do not proceed with payment; let Tap on Mobile time out.

Expected results

• The merchant app does not time out before Tap on Mobile.
• The merchant app handles the response accordingly.

Status of the integration: ☐ Passed · ☐ Failed

Multiple card transactions

Relevance: ☒ Android · ☒ iOS

Objective

• Validate the stability of the merchant app over repeated transactions.

Important: N/A

Steps

1. From the merchant app, initiate at least five card transactions with various amounts (below and above the CVM limit).
2. Proceed with the payments.

Expected results

• All transactions are processed successfully.
• All transactions are approved and appear as Cleared in the back office.
• No merchant app crash or degradation occurs.

Status of the integration: ☐ Passed · ☐ Failed

Cancel last transaction (if supported)

Relevance: ☒ Android · ☒ iOS

Objective

• Validate post-authorisation cancellation in the merchant app.

Important: N/A

Steps

1. From the merchant app, cancel the last transaction.

Expected results

• The cancellation is processed successfully. The status of the transaction can be checked in the back office.

Status of the integration: ☐ Passed · ☐ Failed

Refund a transaction (if supported)

Relevance: ☒ Android · ☒ iOS

Objective

• Validate that the refund flow is properly managed by the merchant app.

Important

• On iOS, if using the merchant app’s own refund screen(s), a copy of the screen(s) must be provided to complete the test.

Steps

1. From the merchant app, initiate a refund for a previously cleared transaction (not the last one).
2. Finalise the refund.

Expected results

• The refund is processed successfully.

Status of the integration: ☐ Passed · ☐ Failed

DCC – Decline offer

Relevance: ☒ Android · ☒ iOS

Objective

• Validate a DCC offer that is not accepted.

Important

• This is a regulatory requirement. The cardholder receipt generated by this test must be provided.

Steps

1. From the merchant app, initiate a payment transaction for a DCC-eligible amount with DCC enabled for the terminal.
2. Confirm that the DCC screen is shown.
3. Do not select the DCC offer (pay in local currency).
4. Finalise payment.

Expected results

• If using iOS without a container, all required DCC information is shown on the screen.
• If using the merchant app’s own cardholder receipt, the receipt does not include DCC information.

Status of the integration: ☐ Passed · ☐ Failed

DCC – Accept offer

Relevance: ☒ Android · ☒ iOS

Objective

• Validate a DCC offer that is accepted.

Important

• This is a regulatory requirement. The cardholder receipt generated by this test must be provided.

Steps

1. From the merchant app, initiate a transaction for a DCC-eligible amount with DCC enabled for the terminal.
2. Confirm that the DCC screen is shown.
3. Select the currency of the card.
4. Finalise payment.

Expected results

• If using iOS without a container, all required DCC information is shown on the screen.
• If using the merchant app’s own cardholder receipt, the receipt includes mandatory DCC information.

Status of the integration: ☐ Passed · ☐ Failed

APM / QR payment (if supported)

Relevance: ☒ Android · ☒ iOS

Objective

• Make a payment using an alternative payment method.

Important

• If APM are enabled for the terminal, when using WPI on Android, the selection screen is handled by Tap on Mobile. On iOS, the selection screen must be managed by the merchant app.

Steps

1. From the merchant app, initiate a payment transaction.
2. Choose QR Code payment.
3. Let the different screens progress until payment confirmation.

Expected results

• The transaction is finalised as a card-based transaction. In the back office, the payment method is QR code.
• The receipt indicates, in the Application Label, the type of QR-code payment scheme used.

Status of the integration: ☐ Passed · ☐ Failed

Transaction history (if supported)

Relevance: ☒ Android · ☒ iOS

Objective

• Validate the display of the transaction history.

Important: N/A

Steps

1. Start the merchant app.
2. Open the transaction history.

Expected results

• All transactions are listed correctly.
• Details match all tests conducted.

Status of the integration: ☐ Passed · ☐ Failed

Session expiration

Relevance: ☐ Android · ☒ iOS

Objective

• Validate long-idle behaviour in the merchant application (session expiration).

Important

• Any payment must be triggered from the merchant application.

Steps

1. Do not use the merchant app for at least 8 hours.
2. Start the merchant app.
3. Perform any action in the app that will trigger a payment.

Expected results

• The transaction is processed successfully, without error.
• The transaction is approved and appears as Cleared in the back office.

Status of the integration: ☐ Passed · ☐ Failed

Last Transaction

Relevance: ☒ Android · ☒ iOS

Objective

• Validate recovery of last transaction in case of a crash or the app or unexpected close of the app.

Important

• Any payment must be triggered from the merchant application.

Steps

1. Start a transaction for an amount of 43,20 (this will only approve the transaction after 20 seconds).
2. Close the merchant app before thransaction is approved.
3. Open the merchant app again and check the last transaction.

Expected results

• The last transaction is the one for an amount of 43,20.

Status of the integration: ☐ Passed · ☐ Failed

Integration partner’s context and test results

Test information

Field	Details
Merchant ID used for the tests	MID from Sandbox Backoffice
Terminal ID used for the tests	All TIDs used
Date of the tests	DD/MM/YYYY
Time range of the tests (from)	00:00
Time range of the tests (to)	00:00

Mandatory information

Field	Options / details
Type of integration	☐ WPI on Android ☐ SDK on iOS
Terminal registration	☐ WMI on Android with backend-to-backend integration ☐ SDK on iOS with backend-to-backend integration
Backend API usage	If using backend APIs outside of the registration process, please list them here.

Optional features

Field	Options / details
Cardholder receipt	☐ Tap on Mobile digital receipt ☐ Own cardholder receipt*
APM	☐ Using APM (TWINT, Alipay, WeChatPay) ☐ No APM used

* If using your own cardholder receipt generated with the information provided by Worldline Tap on Mobile, please attach a copy of a receipt generated in the sandbox environment.

List of tests and results

In the comments, please confirm the transaction amount used for each test to help Worldline teams locate the transaction in the logs, or enter any information required by the test.

In the Supported column, tick the box if the merchant app supports the feature.

#	Scenario	Android	iOS	Supported	Passed	Comments
1	Clean installation	☒	☒	☐	☐
2	Install app (sandbox)	☒	☐	☐	☐
3	Manual terminal activation	☒	☐	☐	☐
4	WMI / Backend-to-Backend terminal activation	☒	☒	☐	☐
5	Accepting merchant T&C	☐	☒	☐	☐
6	First card transaction	☒	☒	☐	☐
7	Transaction with reference (if supported)	☒	☒	☐	☐
8	Cancel transaction at card read	☒	☒	☐	☐
9	Incorrect PIN	☒	☒	☐	☐
10	App restart and configuration persistence	☒	☒	☐	☐
11	Timeout management	☒	☒	☐	☐
12	Multiple card transactions	☒	☒	☐	☐
13	Cancel last transaction (if supported)	☒	☒	☐	☐
14	Refund a transaction (if supported)	☒	☒	☐	☐
15	DCC – Decline offer	☒	☒	☐	☐
16	DCC – Accept offer	☒	☒	☐	☐
17	APM / QR payment (if supported)	☒	☒	☐	☐
18	Transaction history (if supported)	☒	☒	☐	☐
19	Session expiration	☐	☒	☐	☐
20	Last Transaction	☒	☒	☐	☐

The checklist can be downloaded using this link

Execution by Worldline integration

Once the validation process has been conducted by the integration partner, the Worldline integration team will perform checks. Most of these checks are common between Android and iOS, and some are specific because, at the time of writing, Android uses app-to-app with WPI/WMI and iOS uses an SDK.

Document history

Date	Version	Description
12/12/2025	1.0	Initial version of this document
17/12/2025	1.1	Revised version with Partner integration team comments
18/12/2025	1.2	Included feedback from integration team
18/12/2025	1.3	Included feedback from Martin Ulrich
18/12/2025	1.4	Fixed typos
19/12/2025	1.5	Fixed UI and added comments from integration team
19/12/2025	1.6	Pre-sales team comments
14/01/2026	1.7	Harmonised formatting, test adaptation, new context and test summary tables
02/04/2026	1.8	Formatting
12/10/2026	1.9	Last transaction added