Digital wallet card provisioning testing verifies that an eligible payment card can be added to a digital wallet and that the resulting payment credential is correctly issued, associated with the intended customer and device, and usable or manageable according to the issuer's rules. It covers the app and service interactions involved in adding, verifying, activating, suspending or removing a wallet card, including the handling of failures and sensitive data.

What provisioning testing covers

A typical flow starts when a customer selects a card in a banking app or enters card details in a wallet. The issuer checks eligibility and may require customer verification, such as a one-time passcode or an in-app approval. The issuer and its payment partners then arrange a tokenised credential for the wallet. The wallet confirms whether setup completed and displays the card's status.

The exact sequence and system boundaries vary. A flow can involve the banking app, issuer processing systems, a wallet provider, a token service provider (TSP) and card-network services. Testing should verify the agreed behaviour at each relevant boundary, including request and response data, status changes, error mapping and retry handling.

A test scope commonly includes:

  • Eligible and ineligible cards, including cards with relevant account or security restrictions.
  • Customer verification success, failure, expiry and cancellation.
  • Successful provisioning, delayed responses, service errors and duplicate requests.
  • Correct association between the customer, card and wallet or device where that association applies.
  • Card status changes after provisioning, such as suspension, resumption or removal.
  • Use of the provisioned credential in a payment test, where that is within scope.

Tokenisation and provisioning are related

Card tokenisation replaces or represents the primary account number (PAN) with a payment token for use in a defined context. Provisioning is the workflow that requests, verifies and installs a card credential in a wallet. It can include token creation, but it also covers the customer journey, eligibility decisions, authentication and status management. See Card tokenisation testing for tests focused on token behaviour and lifecycle controls.

Provisioning success alone does not prove that a wallet payment will work. Where payment use is in scope, test a suitable transaction and check that the wallet credential is accepted through the relevant payment path. A separate payment test may be needed to cover authorisation outcomes, reversals or settlement.

How to verify the flow

Define expected results across the user interface and the services that participate in the flow. A success message in the app is insufficient evidence if the issuer or token service reports a failed or pending request. Check the final card and token status through approved test interfaces, and correlate records using safe test identifiers. Confirm that failures leave the card in the expected state and that retries do not create unintended duplicate credentials.

Use test cards and environments approved for the integration. Protect PANs, verification codes, token values and authentication data in logs, screenshots and test reports. Mask sensitive values in evidence and ensure test data belongs to the intended test environment. Differences between sandbox and production integrations can affect available responses and lifecycle events, so record environment limitations when interpreting results.

Practical example

For a card that requires one-time passcode verification, test these outcomes:

  1. Submit an eligible test card for wallet provisioning. Confirm that verification is requested and that the request is associated with the expected customer and card.
  2. Enter a valid test code. Confirm that provisioning completes, the wallet displays the expected status and the issuer-side record reflects the same outcome.
  3. Repeat with an invalid or expired code. Confirm that the wallet does not report successful provisioning and that no active credential is created.
  4. Retry after a simulated timeout. Confirm that the final state is consistent across systems and that the retry does not create a second active credential.

Record the starting card state, test inputs, environment, service responses and resulting state for each case. These checks support Mobile banking application testing and Integration testing in banking when the provisioning journey crosses app and payment-service boundaries.

Frequently asked questions

Does provisioning testing require a physical phone?

It depends on the wallet integration and the behaviours under test. A simulator or provider test environment may support some flow checks, while device-specific behaviour such as device binding or secure credential use may require an approved physical device.

Can a sandbox prove that live wallet provisioning will work?

No. A sandbox can verify supported integration behaviour, but it may not reproduce every production dependency, eligibility rule or wallet response. Treat its results as evidence for the behaviours it actually simulates.

Should test evidence include the full card number or token?

No. Evidence should use approved identifiers and mask sensitive card and token data. Capture enough information to correlate the test across systems without exposing payment credentials.