Digital wallets, network tokenisation, 3-D Secure, and cardholder-data boundaries

Cardholder device and wallet

Protects the user session and requests provisioning or payment with device context.

Kind

channel

Owner

Wallet provider and device owner

Responsibilities

• Authenticate the user under wallet policy
• Protect device-bound credentials

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Device integrity
• User authentication
• No credential in analytics logs

Failure modes

• Lost device
• Compromised wallet session
• Repeated provisioning

Recovery

• Suspend the token
• Re-enrol only after issuer and wallet controls pass

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Wallet provisioning service

Coordinates card enrolment, eligibility, identity-and-verification, and token request.

Kind

service

Owner

Wallet provider

Responsibilities

• Create a correlated provisioning case
• Carry issuer verification outcome without inventing approval

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Card eligibility
• Device and account risk
• Step-up verification

Failure modes

• Provisioned to wrong user
• Orphan request
• Repeated verification

Recovery

• Suspend pending tokens
• Resume from the issuer's confirmed outcome

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Token service provider and token vault

Maps a payment token to the underlying account and manages token lifecycle and domain controls.

Kind

security

Owner

Network or authorised token service provider

Responsibilities

• Issue a constrained payment token
• Manage activation, suspension, replacement, and deletion

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Token domain restriction
• Vault access
• Lifecycle audit
• Cryptographic key control

Failure modes

• Token used outside its domain
• Vault unavailable
• Stale token status

Recovery

• Decline or suspend
• Recover token state from authoritative lifecycle evidence

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Issuer digitisation and risk service

Decides card eligibility, identity verification, token assurance, and lifecycle action.

Kind

control

Owner

Issuer digital cards and fraud

Responsibilities

• Approve or decline provisioning
• Bind assurance and verification method to the token record

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Customer verification
• Account and card status
• Fraud and device risk

Failure modes

• False provisioning approval
• Verification timeout
• Lifecycle mismatch

Recovery

• Suspend until state is confirmed
• Reconcile issuer and token-service records

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Merchant wallet acceptance

Accepts tokenised credentials and binds them to the transaction, channel, amount, and merchant.

Kind

gateway

Owner

Merchant payment platform

Responsibilities

• Request a transaction credential
• Avoid storing raw credentials in commerce systems

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Merchant and amount binding
• Replay control
• Secure checkout

Failure modes

• Credential replay
• Amount changed after authentication
• Fallback exposes raw data

Recovery

• Reject changed context
• Create a new authenticated attempt

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

3-D Secure access and authentication domains

Coordinates merchant/acquirer, interoperability, and issuer authentication responsibilities for an online card payment.

Kind

external-network

Owner

Merchant, scheme directory, and issuer access-control owners

Responsibilities

• Exchange authentication data
• Return a correlated frictionless, challenge, unavailable, or failed outcome

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Protocol version
• Transaction and channel binding
• Challenge integrity

Failure modes

• Authentication unavailable
• Late challenge
• Protocol downgrade

Recovery

• Apply documented fallback policy
• Do not reinterpret authentication as authorisation

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Card authorisation and clearing rail

Carries the payment token and transaction credential through normal card authorisation and later clearing.

Kind

external-network

Owner

Acquirer, network, and issuer

Responsibilities

• Route tokenised authorisation
• Preserve token and authentication context for risk and reconciliation

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Token status
• Cryptogram validation
• Authorisation and clearing correlation

Failure modes

• Token valid but cryptogram invalid
• Authentication data lost
• Token-to-account mismatch

Recovery

• Decline precisely
• Investigate across token and card references

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Token, authentication, and fraud operations

Investigates provisioning, token lifecycle, authentication, authorisation, and customer-reported events across organisations.

Kind

operations

Owner

Issuer, wallet, merchant, and network operations

Responsibilities

• Correlate token, device, authentication, and payment references
• Coordinate suspension and recovery

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Least-privilege case access
• Evidence retention
• No raw credential in case notes

Failure modes

• Unowned fraud case
• Token suspended in one system only
• Sensitive data copied into tickets

Recovery

• Contain token use
• Synchronise authoritative status
• Redact and remediate exposed data

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Provisioning request

wallet-user → wallet-provisioning

Carry authenticated device, user, and card-enrolment context.

Contract

api · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Keep the request pending when issuer outcome is uncertain.

Issuer eligibility and verification

wallet-provisioning → wallet-issuer

Obtain issuer approval and assurance evidence.

Contract

message · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Do not issue an active token without a confirmed decision.

Token issuance decision

wallet-issuer → wallet-token-service

Authorise token issuance and lifecycle state.

Contract

control · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Reconcile mismatched issuer and token-service outcomes.

Device token and credential

wallet-token-service → wallet-user

Deliver a constrained token representation and payment capability.

Contract

api · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Suspend on device or lifecycle compromise.

Wallet payment

wallet-user → wallet-merchant

Submit tokenised payment data bound to transaction context.

Contract

api · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Reject replayed or context-mismatched credentials.

Authentication request

wallet-merchant → wallet-3ds

Request 3-D Secure authentication when applicable.

Contract

message · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Return a distinct unavailable or failed state.

Issuer authentication

wallet-3ds → wallet-issuer

Let the issuer assess or challenge the cardholder.

Contract

message · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Preserve challenge outcome and protocol evidence.

Tokenised authorisation

wallet-merchant → wallet-card-rail

Request card authorisation with token and authentication context.

Contract

message · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Do not equate authentication success with issuer approval.

Token resolution and assurance

wallet-card-rail → wallet-token-service

Validate token state, domain, and transaction credential.

Contract

control · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Decline invalid token or credential with controlled diagnostics.

Lifecycle and fraud event

wallet-card-rail → wallet-operations

Open a correlated investigation or token action.

Contract

event · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Deduplicate repeated events and protect sensitive data.

Provision and spend a token

Follow a card from wallet enrolment to one authenticated, tokenised authorisation.

1. Start enrolment — Provisioning requested. The wallet binds the request to the authenticated user and device.
2. Ask the issuer — Eligibility under review. The wallet requests issuer eligibility and any required verification.
3. Approve token issuance — Provisioning approved. The issuer records the verification and assurance decision.
4. Issue a constrained token — Token active. The token service creates a token with domain and lifecycle controls.
5. Bind the purchase — Payment context fixed. The merchant binds amount, merchant, and channel before authentication.
6. Authenticate when required — Authentication outcome recorded. 3-D Secure returns an outcome; it does not approve the payment.
7. Authorise the tokenised payment — Card authorisation decided. The issuer decides the card payment using token and transaction context.

Provisioning outcome is lost

The token service response is lost after issuer approval.

Last confirmed state

Issuer approval exists; token state is uncertain.

Settlement

No purchase settlement has occurred.

Funds and entries

No purchase funds moved.

Next owner

Issuer digital-card operations

Safe action

Query the token lifecycle by the original provisioning reference before retry.

Evidence required

• Issuer decision
• Token request ID
• Token-service lifecycle state

Recovery

• Confirm or cancel the existing token
• Synchronise wallet and issuer status

3-D Secure is unavailable

Authentication cannot return a conclusive outcome.

Last confirmed state

The purchase context exists; authentication is unavailable.

Settlement

No card settlement has occurred.

Funds and entries

No issuer authorisation hold is confirmed.

Next owner

Merchant payment operations

Safe action

Apply the merchant, issuer, regulatory, and scheme fallback policy; do not label unavailable as authenticated.

Evidence required

• Protocol error
• Transaction reference
• Fallback rule

Recovery

• Return a clear outcome
• Retry only if the protocol permits
• Keep the new attempt distinct

Token credential is replayed

A transaction credential is reused outside its intended context.

Last confirmed state

The original payment attempt is already known.

Settlement

Settlement state of the original attempt must be checked separately.

Funds and entries

A second hold or posting must not be assumed valid.

Next owner

Issuer fraud operations

Safe action

Decline the replay, contain the token if policy requires, and correlate the original transaction.

Evidence required

• Token reference
• Credential and domain checks
• Original authorisation

Recovery

• Block repeated use
• Investigate compromise
• Replace or resume the token under controlled lifecycle rules

Which system is authoritative for token lifecycle?

• Token service authoritative — Keeps issuance and lifecycle central but demands rapid issuer and wallet synchronisation.
• Issuer mirror authoritative — Improves issuer control but risks divergence unless every token event is reconciled.

Name one lifecycle authority and define reconciliation, suspension, and recovery for every participant.

How should authentication and authorisation states relate?

• Separate states — Preserves the fact that identity evidence and funds approval answer different questions.
• Single success flag — Hides unavailable, challenged, declined, and approved distinctions and weakens troubleshooting.

Store protocol outcome, issuer authentication outcome, and card authorisation outcome separately.