{
  "generatedFrom": "Payments Signal canonical architecture registry",
  "reviewDate": "2026-07-23",
  "blueprint": {
    "id": "architecture-wallet-tokenisation",
    "slug": "wallet-tokenisation-3ds-card-data-boundaries",
    "title": "Digital wallets, network tokenisation, 3-D Secure, and cardholder-data boundaries",
    "shortTitle": "Wallets & tokenisation",
    "family": "channel",
    "summary": "See how a wallet enrols a card, uses a payment token and transaction credential, invokes authentication when required, and keeps raw card data inside controlled boundaries.",
    "audience": "Wallet, card, digital-channel, authentication, security, fraud, and merchant-platform architects.",
    "reviewDate": "2026-07-23",
    "versionLabel": "Payments Signal reference architecture v1",
    "status": "current",
    "nodes": [
      {
        "id": "wallet-user",
        "title": "Cardholder device and wallet",
        "kind": "channel",
        "summary": "Protects the user session and requests provisioning or payment with device context.",
        "responsibilities": [
          "Authenticate the user under wallet policy",
          "Protect device-bound credentials"
        ],
        "owner": "Wallet provider and device owner",
        "inputs": [
          "Authorised business instruction and correlated state"
        ],
        "outputs": [
          "Versioned result, status, and audit evidence"
        ],
        "interfaceContracts": [
          "Versioned cardholder device and wallet contract",
          "Stable identifier, state, error, and audit contract"
        ],
        "controls": [
          "Device integrity",
          "User authentication",
          "No credential in analytics logs"
        ],
        "failureModes": [
          "Lost device",
          "Compromised wallet session",
          "Repeated provisioning"
        ],
        "recovery": [
          "Suspend the token",
          "Re-enrol only after issuer and wallet controls pass"
        ],
        "lenses": [
          "applications",
          "interfaces",
          "data",
          "controls",
          "operations",
          "resilience"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "dataClassification": [
          "Payment, message, status, and operational metadata"
        ],
        "nonFunctionalRequirements": [
          "Durable correlation through stable business and technical identifiers",
          "Capacity and availability matched to the service-level objective",
          "Auditable state changes, configuration, and operator actions"
        ]
      },
      {
        "id": "wallet-provisioning",
        "title": "Wallet provisioning service",
        "kind": "service",
        "summary": "Coordinates card enrolment, eligibility, identity-and-verification, and token request.",
        "responsibilities": [
          "Create a correlated provisioning case",
          "Carry issuer verification outcome without inventing approval"
        ],
        "owner": "Wallet provider",
        "inputs": [
          "Authorised business instruction and correlated state"
        ],
        "outputs": [
          "Versioned result, status, and audit evidence"
        ],
        "interfaceContracts": [
          "Versioned wallet provisioning service contract",
          "Stable identifier, state, error, and audit contract"
        ],
        "controls": [
          "Card eligibility",
          "Device and account risk",
          "Step-up verification"
        ],
        "failureModes": [
          "Provisioned to wrong user",
          "Orphan request",
          "Repeated verification"
        ],
        "recovery": [
          "Suspend pending tokens",
          "Resume from the issuer's confirmed outcome"
        ],
        "lenses": [
          "applications",
          "interfaces",
          "data",
          "controls",
          "operations",
          "resilience"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "dataClassification": [
          "Payment, message, status, and operational metadata"
        ],
        "nonFunctionalRequirements": [
          "Durable correlation through stable business and technical identifiers",
          "Capacity and availability matched to the service-level objective",
          "Auditable state changes, configuration, and operator actions"
        ]
      },
      {
        "id": "wallet-token-service",
        "title": "Token service provider and token vault",
        "kind": "security",
        "summary": "Maps a payment token to the underlying account and manages token lifecycle and domain controls.",
        "responsibilities": [
          "Issue a constrained payment token",
          "Manage activation, suspension, replacement, and deletion"
        ],
        "owner": "Network or authorised token service provider",
        "inputs": [
          "Authorised business instruction and correlated state"
        ],
        "outputs": [
          "Versioned result, status, and audit evidence"
        ],
        "interfaceContracts": [
          "Versioned token service provider and token vault contract",
          "Stable identifier, state, error, and audit contract"
        ],
        "controls": [
          "Token domain restriction",
          "Vault access",
          "Lifecycle audit",
          "Cryptographic key control"
        ],
        "failureModes": [
          "Token used outside its domain",
          "Vault unavailable",
          "Stale token status"
        ],
        "recovery": [
          "Decline or suspend",
          "Recover token state from authoritative lifecycle evidence"
        ],
        "lenses": [
          "applications",
          "interfaces",
          "data",
          "controls",
          "operations",
          "resilience"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          },
          {
            "ref": {
              "sourceId": "pci-dss",
              "locator": "Tokenisation does not by itself remove scope",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "PCI DSS v4.0.1"
          }
        ],
        "dataClassification": [
          "Payment, message, status, and operational metadata"
        ],
        "nonFunctionalRequirements": [
          "Durable correlation through stable business and technical identifiers",
          "Capacity and availability matched to the service-level objective",
          "Auditable state changes, configuration, and operator actions"
        ]
      },
      {
        "id": "wallet-issuer",
        "title": "Issuer digitisation and risk service",
        "kind": "control",
        "summary": "Decides card eligibility, identity verification, token assurance, and lifecycle action.",
        "responsibilities": [
          "Approve or decline provisioning",
          "Bind assurance and verification method to the token record"
        ],
        "owner": "Issuer digital cards and fraud",
        "inputs": [
          "Authorised business instruction and correlated state"
        ],
        "outputs": [
          "Versioned result, status, and audit evidence"
        ],
        "interfaceContracts": [
          "Versioned issuer digitisation and risk service contract",
          "Stable identifier, state, error, and audit contract"
        ],
        "controls": [
          "Customer verification",
          "Account and card status",
          "Fraud and device risk"
        ],
        "failureModes": [
          "False provisioning approval",
          "Verification timeout",
          "Lifecycle mismatch"
        ],
        "recovery": [
          "Suspend until state is confirmed",
          "Reconcile issuer and token-service records"
        ],
        "lenses": [
          "applications",
          "interfaces",
          "data",
          "controls",
          "operations",
          "resilience"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "dataClassification": [
          "Payment, message, status, and operational metadata"
        ],
        "nonFunctionalRequirements": [
          "Durable correlation through stable business and technical identifiers",
          "Capacity and availability matched to the service-level objective",
          "Auditable state changes, configuration, and operator actions"
        ]
      },
      {
        "id": "wallet-merchant",
        "title": "Merchant wallet acceptance",
        "kind": "gateway",
        "summary": "Accepts tokenised credentials and binds them to the transaction, channel, amount, and merchant.",
        "responsibilities": [
          "Request a transaction credential",
          "Avoid storing raw credentials in commerce systems"
        ],
        "owner": "Merchant payment platform",
        "inputs": [
          "Authorised business instruction and correlated state"
        ],
        "outputs": [
          "Versioned result, status, and audit evidence"
        ],
        "interfaceContracts": [
          "Versioned merchant wallet acceptance contract",
          "Stable identifier, state, error, and audit contract"
        ],
        "controls": [
          "Merchant and amount binding",
          "Replay control",
          "Secure checkout"
        ],
        "failureModes": [
          "Credential replay",
          "Amount changed after authentication",
          "Fallback exposes raw data"
        ],
        "recovery": [
          "Reject changed context",
          "Create a new authenticated attempt"
        ],
        "lenses": [
          "applications",
          "interfaces",
          "data",
          "controls",
          "operations",
          "resilience"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          },
          {
            "ref": {
              "sourceId": "pci-dss",
              "locator": "Cardholder-data environment",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "PCI DSS v4.0.1"
          }
        ],
        "dataClassification": [
          "Payment, message, status, and operational metadata"
        ],
        "nonFunctionalRequirements": [
          "Durable correlation through stable business and technical identifiers",
          "Capacity and availability matched to the service-level objective",
          "Auditable state changes, configuration, and operator actions"
        ]
      },
      {
        "id": "wallet-3ds",
        "title": "3-D Secure access and authentication domains",
        "kind": "external-network",
        "summary": "Coordinates merchant/acquirer, interoperability, and issuer authentication responsibilities for an online card payment.",
        "responsibilities": [
          "Exchange authentication data",
          "Return a correlated frictionless, challenge, unavailable, or failed outcome"
        ],
        "owner": "Merchant, scheme directory, and issuer access-control owners",
        "inputs": [
          "Authorised business instruction and correlated state"
        ],
        "outputs": [
          "Versioned result, status, and audit evidence"
        ],
        "interfaceContracts": [
          "Versioned 3-d secure access and authentication domains contract",
          "Stable identifier, state, error, and audit contract"
        ],
        "controls": [
          "Protocol version",
          "Transaction and channel binding",
          "Challenge integrity"
        ],
        "failureModes": [
          "Authentication unavailable",
          "Late challenge",
          "Protocol downgrade"
        ],
        "recovery": [
          "Apply documented fallback policy",
          "Do not reinterpret authentication as authorisation"
        ],
        "lenses": [
          "applications",
          "interfaces",
          "data",
          "controls",
          "operations",
          "resilience"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "emvco-3ds",
              "locator": "Three-domain architecture and message flow",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "EMV 3-D Secure public documentation"
          }
        ],
        "dataClassification": [
          "Payment, message, status, and operational metadata"
        ],
        "nonFunctionalRequirements": [
          "Durable correlation through stable business and technical identifiers",
          "Capacity and availability matched to the service-level objective",
          "Auditable state changes, configuration, and operator actions"
        ]
      },
      {
        "id": "wallet-card-rail",
        "title": "Card authorisation and clearing rail",
        "kind": "external-network",
        "summary": "Carries the payment token and transaction credential through normal card authorisation and later clearing.",
        "responsibilities": [
          "Route tokenised authorisation",
          "Preserve token and authentication context for risk and reconciliation"
        ],
        "owner": "Acquirer, network, and issuer",
        "inputs": [
          "Authorised business instruction and correlated state"
        ],
        "outputs": [
          "Versioned result, status, and audit evidence"
        ],
        "interfaceContracts": [
          "Versioned card authorisation and clearing rail contract",
          "Stable identifier, state, error, and audit contract"
        ],
        "controls": [
          "Token status",
          "Cryptogram validation",
          "Authorisation and clearing correlation"
        ],
        "failureModes": [
          "Token valid but cryptogram invalid",
          "Authentication data lost",
          "Token-to-account mismatch"
        ],
        "recovery": [
          "Decline precisely",
          "Investigate across token and card references"
        ],
        "lenses": [
          "applications",
          "interfaces",
          "data",
          "controls",
          "operations",
          "resilience"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "dataClassification": [
          "Payment, message, status, and operational metadata"
        ],
        "nonFunctionalRequirements": [
          "Durable correlation through stable business and technical identifiers",
          "Capacity and availability matched to the service-level objective",
          "Auditable state changes, configuration, and operator actions"
        ]
      },
      {
        "id": "wallet-operations",
        "title": "Token, authentication, and fraud operations",
        "kind": "operations",
        "summary": "Investigates provisioning, token lifecycle, authentication, authorisation, and customer-reported events across organisations.",
        "responsibilities": [
          "Correlate token, device, authentication, and payment references",
          "Coordinate suspension and recovery"
        ],
        "owner": "Issuer, wallet, merchant, and network operations",
        "inputs": [
          "Authorised business instruction and correlated state"
        ],
        "outputs": [
          "Versioned result, status, and audit evidence"
        ],
        "interfaceContracts": [
          "Versioned token, authentication, and fraud operations contract",
          "Stable identifier, state, error, and audit contract"
        ],
        "controls": [
          "Least-privilege case access",
          "Evidence retention",
          "No raw credential in case notes"
        ],
        "failureModes": [
          "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"
        ],
        "lenses": [
          "applications",
          "interfaces",
          "data",
          "controls",
          "operations",
          "resilience"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          },
          {
            "ref": {
              "sourceId": "pci-dss",
              "locator": "Protect stored and transmitted account data",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "PCI DSS v4.0.1"
          }
        ],
        "dataClassification": [
          "Payment, message, status, and operational metadata"
        ],
        "nonFunctionalRequirements": [
          "Durable correlation through stable business and technical identifiers",
          "Capacity and availability matched to the service-level objective",
          "Auditable state changes, configuration, and operator actions"
        ]
      }
    ],
    "interfaces": [
      {
        "id": "wallet-e1",
        "from": "wallet-user",
        "to": "wallet-provisioning",
        "title": "Provisioning request",
        "kind": "api",
        "mode": "synchronous",
        "purpose": "Carry authenticated device, user, and card-enrolment context.",
        "failureBehaviour": "Keep the request pending when issuer outcome is uncertain.",
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      },
      {
        "id": "wallet-e2",
        "from": "wallet-provisioning",
        "to": "wallet-issuer",
        "title": "Issuer eligibility and verification",
        "kind": "message",
        "mode": "asynchronous",
        "purpose": "Obtain issuer approval and assurance evidence.",
        "failureBehaviour": "Do not issue an active token without a confirmed decision.",
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      },
      {
        "id": "wallet-e3",
        "from": "wallet-issuer",
        "to": "wallet-token-service",
        "title": "Token issuance decision",
        "kind": "control",
        "mode": "asynchronous",
        "purpose": "Authorise token issuance and lifecycle state.",
        "failureBehaviour": "Reconcile mismatched issuer and token-service outcomes.",
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      },
      {
        "id": "wallet-e4",
        "from": "wallet-token-service",
        "to": "wallet-user",
        "title": "Device token and credential",
        "kind": "api",
        "mode": "synchronous",
        "purpose": "Deliver a constrained token representation and payment capability.",
        "failureBehaviour": "Suspend on device or lifecycle compromise.",
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      },
      {
        "id": "wallet-e5",
        "from": "wallet-user",
        "to": "wallet-merchant",
        "title": "Wallet payment",
        "kind": "api",
        "mode": "synchronous",
        "purpose": "Submit tokenised payment data bound to transaction context.",
        "failureBehaviour": "Reject replayed or context-mismatched credentials.",
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      },
      {
        "id": "wallet-e6",
        "from": "wallet-merchant",
        "to": "wallet-3ds",
        "title": "Authentication request",
        "kind": "message",
        "mode": "synchronous",
        "purpose": "Request 3-D Secure authentication when applicable.",
        "failureBehaviour": "Return a distinct unavailable or failed state.",
        "evidence": [
          {
            "ref": {
              "sourceId": "emvco-3ds",
              "locator": "Authentication request and response",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "EMV 3-D Secure public documentation"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      },
      {
        "id": "wallet-e7",
        "from": "wallet-3ds",
        "to": "wallet-issuer",
        "title": "Issuer authentication",
        "kind": "message",
        "mode": "synchronous",
        "purpose": "Let the issuer assess or challenge the cardholder.",
        "failureBehaviour": "Preserve challenge outcome and protocol evidence.",
        "evidence": [
          {
            "ref": {
              "sourceId": "emvco-3ds",
              "locator": "Issuer domain and access-control server",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "EMV 3-D Secure public documentation"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      },
      {
        "id": "wallet-e8",
        "from": "wallet-merchant",
        "to": "wallet-card-rail",
        "title": "Tokenised authorisation",
        "kind": "message",
        "mode": "synchronous",
        "purpose": "Request card authorisation with token and authentication context.",
        "failureBehaviour": "Do not equate authentication success with issuer approval.",
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      },
      {
        "id": "wallet-e9",
        "from": "wallet-card-rail",
        "to": "wallet-token-service",
        "title": "Token resolution and assurance",
        "kind": "control",
        "mode": "synchronous",
        "purpose": "Validate token state, domain, and transaction credential.",
        "failureBehaviour": "Decline invalid token or credential with controlled diagnostics.",
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      },
      {
        "id": "wallet-e10",
        "from": "wallet-card-rail",
        "to": "wallet-operations",
        "title": "Lifecycle and fraud event",
        "kind": "event",
        "mode": "asynchronous",
        "purpose": "Open a correlated investigation or token action.",
        "failureBehaviour": "Deduplicate repeated events and protect sensitive data.",
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ],
        "controls": [
          "Authentication and authorisation",
          "Integrity and replay protection",
          "Correlation and audit evidence"
        ],
        "lenses": [
          "interfaces",
          "data",
          "ledger",
          "controls",
          "operations",
          "resilience"
        ],
        "dataClassification": [
          "Payment instruction, status, and correlation metadata"
        ]
      }
    ],
    "views": [
      {
        "id": "context",
        "label": "Context",
        "plainPurpose": "Who depends on the architecture, which external service it reaches, and where value ultimately moves.",
        "nodeIds": [
          "wallet-user",
          "wallet-3ds",
          "wallet-card-rail"
        ],
        "interfaceIds": [],
        "placements": {
          "wallet-user": {
            "x": 80,
            "y": 100,
            "width": 244,
            "height": 126
          },
          "wallet-3ds": {
            "x": 444,
            "y": 100,
            "width": 244,
            "height": 126
          },
          "wallet-card-rail": {
            "x": 808,
            "y": 100,
            "width": 244,
            "height": 126
          }
        },
        "boundaries": [
          {
            "id": "context-network-boundary",
            "label": "External network boundary",
            "nodeIds": [
              "wallet-3ds",
              "wallet-card-rail"
            ],
            "kind": "network"
          }
        ]
      },
      {
        "id": "container",
        "label": "Container",
        "plainPurpose": "The major applications, stores, gateways, controls, and operational ownership boundaries.",
        "nodeIds": [
          "wallet-user",
          "wallet-issuer",
          "wallet-merchant",
          "wallet-3ds",
          "wallet-card-rail",
          "wallet-operations"
        ],
        "interfaceIds": [
          "wallet-e5",
          "wallet-e6",
          "wallet-e7",
          "wallet-e8",
          "wallet-e10"
        ],
        "placements": {
          "wallet-user": {
            "x": 80,
            "y": 100,
            "width": 244,
            "height": 126
          },
          "wallet-issuer": {
            "x": 444,
            "y": 100,
            "width": 244,
            "height": 126
          },
          "wallet-merchant": {
            "x": 808,
            "y": 100,
            "width": 244,
            "height": 126
          },
          "wallet-3ds": {
            "x": 80,
            "y": 326,
            "width": 244,
            "height": 126
          },
          "wallet-card-rail": {
            "x": 444,
            "y": 326,
            "width": 244,
            "height": 126
          },
          "wallet-operations": {
            "x": 808,
            "y": 326,
            "width": 244,
            "height": 126
          }
        },
        "boundaries": [
          {
            "id": "container-bank-boundary",
            "label": "Institution-controlled boundary",
            "nodeIds": [
              "wallet-user",
              "wallet-issuer",
              "wallet-merchant",
              "wallet-operations"
            ],
            "kind": "ownership"
          },
          {
            "id": "container-network-boundary",
            "label": "External network boundary",
            "nodeIds": [
              "wallet-3ds",
              "wallet-card-rail"
            ],
            "kind": "network"
          }
        ]
      },
      {
        "id": "component",
        "label": "Component",
        "plainPurpose": "The processing responsibilities and interface contracts that must cooperate for one payment.",
        "nodeIds": [
          "wallet-user",
          "wallet-provisioning",
          "wallet-token-service",
          "wallet-issuer",
          "wallet-merchant",
          "wallet-3ds",
          "wallet-card-rail",
          "wallet-operations"
        ],
        "interfaceIds": [
          "wallet-e1",
          "wallet-e2",
          "wallet-e3",
          "wallet-e4",
          "wallet-e5",
          "wallet-e6",
          "wallet-e7",
          "wallet-e8",
          "wallet-e9",
          "wallet-e10"
        ],
        "placements": {
          "wallet-user": {
            "x": 80,
            "y": 100,
            "width": 196,
            "height": 126
          },
          "wallet-provisioning": {
            "x": 376,
            "y": 100,
            "width": 196,
            "height": 126
          },
          "wallet-token-service": {
            "x": 672,
            "y": 100,
            "width": 196,
            "height": 126
          },
          "wallet-issuer": {
            "x": 968,
            "y": 100,
            "width": 196,
            "height": 126
          },
          "wallet-merchant": {
            "x": 80,
            "y": 326,
            "width": 196,
            "height": 126
          },
          "wallet-3ds": {
            "x": 376,
            "y": 326,
            "width": 196,
            "height": 126
          },
          "wallet-card-rail": {
            "x": 672,
            "y": 326,
            "width": 196,
            "height": 126
          },
          "wallet-operations": {
            "x": 968,
            "y": 326,
            "width": 196,
            "height": 126
          }
        },
        "boundaries": [
          {
            "id": "component-bank-boundary",
            "label": "Institution-controlled boundary",
            "nodeIds": [
              "wallet-user",
              "wallet-provisioning",
              "wallet-token-service",
              "wallet-issuer",
              "wallet-merchant",
              "wallet-operations"
            ],
            "kind": "ownership"
          },
          {
            "id": "component-network-boundary",
            "label": "External network boundary",
            "nodeIds": [
              "wallet-3ds",
              "wallet-card-rail"
            ],
            "kind": "network"
          }
        ]
      },
      {
        "id": "deployment",
        "label": "Deployment",
        "plainPurpose": "The trust zones, runtime dependencies, external connections, and recovery boundaries.",
        "nodeIds": [
          "wallet-token-service",
          "wallet-merchant",
          "wallet-3ds",
          "wallet-card-rail"
        ],
        "interfaceIds": [
          "wallet-e6",
          "wallet-e8",
          "wallet-e9"
        ],
        "placements": {
          "wallet-token-service": {
            "x": 80,
            "y": 100,
            "width": 244,
            "height": 126
          },
          "wallet-merchant": {
            "x": 444,
            "y": 100,
            "width": 244,
            "height": 126
          },
          "wallet-3ds": {
            "x": 808,
            "y": 100,
            "width": 244,
            "height": 126
          },
          "wallet-card-rail": {
            "x": 80,
            "y": 326,
            "width": 244,
            "height": 126
          }
        },
        "boundaries": [
          {
            "id": "deployment-bank-boundary",
            "label": "Institution-controlled boundary",
            "nodeIds": [
              "wallet-token-service",
              "wallet-merchant"
            ],
            "kind": "ownership"
          },
          {
            "id": "deployment-network-boundary",
            "label": "External network boundary",
            "nodeIds": [
              "wallet-3ds",
              "wallet-card-rail"
            ],
            "kind": "network"
          }
        ]
      }
    ],
    "traces": [
      {
        "id": "wallet-tokenized-payment",
        "label": "Provision and spend a token",
        "summary": "Follow a card from wallet enrolment to one authenticated, tokenised authorisation.",
        "viewId": "component",
        "steps": [
          {
            "id": "wallet-tokenized-payment-step-1",
            "title": "Start enrolment",
            "nodeId": "wallet-user",
            "interfaceId": "wallet-e1",
            "plainExplanation": "The wallet binds the request to the authenticated user and device.",
            "businessState": "Provisioning requested"
          },
          {
            "id": "wallet-tokenized-payment-step-2",
            "title": "Ask the issuer",
            "nodeId": "wallet-provisioning",
            "interfaceId": "wallet-e2",
            "plainExplanation": "The wallet requests issuer eligibility and any required verification.",
            "businessState": "Eligibility under review"
          },
          {
            "id": "wallet-tokenized-payment-step-3",
            "title": "Approve token issuance",
            "nodeId": "wallet-issuer",
            "interfaceId": "wallet-e3",
            "plainExplanation": "The issuer records the verification and assurance decision.",
            "businessState": "Provisioning approved"
          },
          {
            "id": "wallet-tokenized-payment-step-4",
            "title": "Issue a constrained token",
            "nodeId": "wallet-token-service",
            "interfaceId": "wallet-e4",
            "plainExplanation": "The token service creates a token with domain and lifecycle controls.",
            "businessState": "Token active"
          },
          {
            "id": "wallet-tokenized-payment-step-5",
            "title": "Bind the purchase",
            "nodeId": "wallet-merchant",
            "interfaceId": "wallet-e6",
            "plainExplanation": "The merchant binds amount, merchant, and channel before authentication.",
            "businessState": "Payment context fixed"
          },
          {
            "id": "wallet-tokenized-payment-step-6",
            "title": "Authenticate when required",
            "nodeId": "wallet-3ds",
            "interfaceId": "wallet-e7",
            "plainExplanation": "3-D Secure returns an outcome; it does not approve the payment.",
            "businessState": "Authentication outcome recorded"
          },
          {
            "id": "wallet-tokenized-payment-step-7",
            "title": "Authorise the tokenised payment",
            "nodeId": "wallet-card-rail",
            "plainExplanation": "The issuer decides the card payment using token and transaction context.",
            "businessState": "Card authorisation decided"
          }
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          },
          {
            "ref": {
              "sourceId": "emvco-3ds",
              "locator": "Three-domain architecture",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "EMV 3-D Secure public documentation"
          }
        ]
      }
    ],
    "stressCases": [
      {
        "id": "wallet-stress-provision",
        "label": "Provisioning outcome is lost",
        "trigger": "The token service response is lost after issuer approval.",
        "divergesAfterStepId": "wallet-tokenized-payment-step-3",
        "traceId": "wallet-tokenized-payment",
        "affectedNodeIds": [
          "wallet-issuer",
          "wallet-token-service",
          "wallet-provisioning"
        ],
        "affectedInterfaceIds": [
          "wallet-e3",
          "wallet-e4"
        ],
        "lastConfirmedState": "Issuer approval exists; token state is uncertain.",
        "settlementState": "No purchase settlement has occurred.",
        "fundsState": "No purchase funds moved.",
        "owner": "Issuer digital-card operations",
        "safeAction": "Query the token lifecycle by the original provisioning reference before retry.",
        "requiredEvidence": [
          "Issuer decision",
          "Token request ID",
          "Token-service lifecycle state"
        ],
        "recoverySteps": [
          "Confirm or cancel the existing token",
          "Synchronise wallet and issuer status"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ]
      },
      {
        "id": "wallet-stress-auth",
        "label": "3-D Secure is unavailable",
        "trigger": "Authentication cannot return a conclusive outcome.",
        "divergesAfterStepId": "wallet-tokenized-payment-step-6",
        "traceId": "wallet-tokenized-payment",
        "affectedNodeIds": [
          "wallet-merchant",
          "wallet-3ds",
          "wallet-issuer"
        ],
        "affectedInterfaceIds": [
          "wallet-e6",
          "wallet-e7"
        ],
        "lastConfirmedState": "The purchase context exists; authentication is unavailable.",
        "settlementState": "No card settlement has occurred.",
        "fundsState": "No issuer authorisation hold is confirmed.",
        "owner": "Merchant payment operations",
        "safeAction": "Apply the merchant, issuer, regulatory, and scheme fallback policy; do not label unavailable as authenticated.",
        "requiredEvidence": [
          "Protocol error",
          "Transaction reference",
          "Fallback rule"
        ],
        "recoverySteps": [
          "Return a clear outcome",
          "Retry only if the protocol permits",
          "Keep the new attempt distinct"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "emvco-3ds",
              "locator": "Authentication outcomes and error handling",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "EMV 3-D Secure public documentation"
          }
        ]
      },
      {
        "id": "wallet-stress-replay",
        "label": "Token credential is replayed",
        "trigger": "A transaction credential is reused outside its intended context.",
        "divergesAfterStepId": "wallet-tokenized-payment-step-7",
        "traceId": "wallet-tokenized-payment",
        "affectedNodeIds": [
          "wallet-token-service",
          "wallet-card-rail",
          "wallet-operations"
        ],
        "affectedInterfaceIds": [
          "wallet-e8",
          "wallet-e9"
        ],
        "lastConfirmedState": "The original payment attempt is already known.",
        "settlementState": "Settlement state of the original attempt must be checked separately.",
        "fundsState": "A second hold or posting must not be assumed valid.",
        "owner": "Issuer fraud operations",
        "safeAction": "Decline the replay, contain the token if policy requires, and correlate the original transaction.",
        "requiredEvidence": [
          "Token reference",
          "Credential and domain checks",
          "Original authorisation"
        ],
        "recoverySteps": [
          "Block repeated use",
          "Investigate compromise",
          "Replace or resume the token under controlled lifecycle rules"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ]
      }
    ],
    "overlays": [
      {
        "id": "wallet-overlay-tokenised",
        "label": "Tokenised wallet payment",
        "summary": "Show provisioning, token lifecycle, authentication, and card-rail boundaries.",
        "nodeIds": [
          "wallet-user",
          "wallet-provisioning",
          "wallet-token-service",
          "wallet-issuer",
          "wallet-merchant",
          "wallet-3ds",
          "wallet-card-rail"
        ],
        "interfaceIds": [
          "wallet-e1",
          "wallet-e2",
          "wallet-e3",
          "wallet-e4",
          "wallet-e5",
          "wallet-e6",
          "wallet-e7",
          "wallet-e8",
          "wallet-e9"
        ],
        "relatedFlowIds": [
          "flow-wallet-tokenized"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          },
          {
            "ref": {
              "sourceId": "emvco-3ds",
              "locator": "Three-domain architecture",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "EMV 3-D Secure public documentation"
          }
        ],
        "coverageGap": "Wallet and network-token details vary by provider and may require licensed specifications."
      },
      {
        "id": "wallet-overlay-cde",
        "label": "Cardholder-data boundary",
        "summary": "Highlight the controlled credential and token vault boundary without claiming automatic PCI scope reduction.",
        "nodeIds": [
          "wallet-user",
          "wallet-token-service",
          "wallet-merchant",
          "wallet-card-rail"
        ],
        "interfaceIds": [
          "wallet-e4",
          "wallet-e5",
          "wallet-e8",
          "wallet-e9"
        ],
        "relatedFlowIds": [
          "flow-card-authorization"
        ],
        "evidence": [
          {
            "ref": {
              "sourceId": "pci-dss",
              "locator": "Cardholder-data environment and connected-to systems",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "PCI DSS v4.0.1"
          }
        ]
      }
    ],
    "decisions": [
      {
        "id": "wallet-decision-token",
        "question": "Which system is authoritative for token lifecycle?",
        "options": [
          {
            "label": "Token service authoritative",
            "consequence": "Keeps issuance and lifecycle central but demands rapid issuer and wallet synchronisation."
          },
          {
            "label": "Issuer mirror authoritative",
            "consequence": "Improves issuer control but risks divergence unless every token event is reconciled."
          }
        ],
        "guidance": "Name one lifecycle authority and define reconciliation, suspension, and recovery for every participant.",
        "evidence": [
          {
            "ref": {
              "sourceId": "payments-signal-editorial",
              "locator": "Wallet, tokenisation, and cardholder-data boundaries",
              "label": "simplified-educational-illustration",
              "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "Payments Signal reference architecture v1"
          }
        ]
      },
      {
        "id": "wallet-decision-auth",
        "question": "How should authentication and authorisation states relate?",
        "options": [
          {
            "label": "Separate states",
            "consequence": "Preserves the fact that identity evidence and funds approval answer different questions."
          },
          {
            "label": "Single success flag",
            "consequence": "Hides unavailable, challenged, declined, and approved distinctions and weakens troubleshooting."
          }
        ],
        "guidance": "Store protocol outcome, issuer authentication outcome, and card authorisation outcome separately.",
        "evidence": [
          {
            "ref": {
              "sourceId": "emvco-3ds",
              "locator": "Authentication architecture",
              "label": "official-requirement"
            },
            "verifiedDate": "2026-07-23",
            "versionContext": "EMV 3-D Secure public documentation"
          }
        ]
      }
    ],
    "targets": [
      {
        "type": "flow",
        "id": "flow-wallet-tokenized"
      },
      {
        "type": "flow",
        "id": "flow-card-authorization"
      }
    ],
    "glossaryTermIds": [
      "3-d-secure",
      "cardholder-data-environment",
      "cryptogram",
      "network-token",
      "tokenisation",
      "token-service-provider",
      "wallet"
    ],
    "evidence": [
      {
        "ref": {
          "sourceId": "payments-signal-editorial",
          "locator": "Wallet, tokenisation, and cardholder-data boundaries",
          "label": "simplified-educational-illustration",
          "simplifications": "Wallet provisioning, token service, cryptogram, lifecycle, and liability rules differ by wallet, token service provider, card network, issuer, device platform, merchant channel, and applicable specification."
        },
        "verifiedDate": "2026-07-23",
        "versionContext": "Payments Signal reference architecture v1"
      },
      {
        "ref": {
          "sourceId": "emvco-3ds",
          "locator": "Three-domain architecture",
          "label": "official-requirement"
        },
        "verifiedDate": "2026-07-23",
        "versionContext": "EMV 3-D Secure public documentation"
      },
      {
        "ref": {
          "sourceId": "pci-dss",
          "locator": "Cardholder-data environment",
          "label": "official-requirement"
        },
        "verifiedDate": "2026-07-23",
        "versionContext": "PCI DSS v4.0.1"
      }
    ],
    "simplifies": "This blueprint shows responsibility and trust boundaries, not a licensed token-service or wallet specification. Device attestation, issuer identity-and-verification methods, token assurance, cryptographic protocols, liability, authentication exemptions, fallback, and PCI DSS scope must be assessed against the actual providers, channels, and current rules."
  },
  "sources": [
    {
      "id": "payments-signal-editorial",
      "publisher": "Payments Signal",
      "title": "Payments Signal editorial teaching models",
      "sourceType": "educational-simplification",
      "accessedDate": "2026-07-12",
      "applicability": "This site's own simplified teaching models.",
      "notes": "Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional."
    },
    {
      "id": "emvco-3ds",
      "publisher": "EMVCo",
      "title": "EMV 3-D Secure documentation",
      "sourceType": "official-standard",
      "accessedDate": "2026-07-23",
      "url": "https://www.emvco.com/dynamic/emv-3-d-secure-whitepaper-v2/3-d-secure-documentation/",
      "applicability": "Describes the EMV 3-D Secure three-domain model, message exchanges, data elements, and browser and application channels used to authenticate card-not-present transactions.",
      "notes": "Payments Signal links to the official documentation and does not reproduce licensed specifications. The architecture distinguishes 3-D Secure authentication from issuer authorisation."
    },
    {
      "id": "pci-dss",
      "publisher": "PCI Security Standards Council",
      "title": "Payment Card Industry Data Security Standard",
      "sourceType": "official-standard",
      "accessedDate": "2026-07-23",
      "url": "https://www.pcisecuritystandards.org/standards/pci-dss/",
      "applicability": "Provides baseline technical and operational requirements for entities that store, process, or transmit cardholder data or sensitive authentication data, and for systems that can affect the security of the cardholder-data environment.",
      "notes": "The public page identifies PCI DSS v4.0.1. A reference architecture cannot determine PCI DSS scope, compliance, or assessment outcome."
    }
  ],
  "relatedContent": [
    {
      "type": "article",
      "label": "3-D Secure 2 in practice",
      "href": "/2026/07/18/three-d-secure-2-in-practice",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Alternative payment methods and BNPL",
      "href": "/2026/07/18/alternative-payment-methods-and-bnpl",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Card authorization under the hood",
      "href": "/2026/07/18/card-authorization-under-the-hood",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Card clearing and settlement, explained",
      "href": "/2026/07/18/card-clearing-and-settlement-explained",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Card payments: the four-party model",
      "href": "/2026/07/18/card-payments-the-four-party-model",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Card tokenisation: from PAN to DPAN",
      "href": "/2026/07/18/card-tokenization-from-pan-to-dpan",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Cards vs account-to-account rails",
      "href": "/2026/07/18/cards-vs-account-to-account-rails",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Chargebacks and disputes, end to end",
      "href": "/2026/07/18/chargebacks-and-disputes-end-to-end",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Digital wallets, explained: pass-through versus staged",
      "href": "/2026/07/18/digital-wallets-explained",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "From tap to payout: a merchant's story",
      "href": "/2026/07/18/from-tap-to-payout-a-merchant-story",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "How network tokenisation protects a card",
      "href": "/2026/07/18/how-network-tokenization-protects-a-card",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Interchange, scheme fees, and the merchant discount",
      "href": "/2026/07/18/interchange-scheme-fees-and-the-merchant-discount",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "Payment orchestration and routing",
      "href": "/2026/07/18/payment-orchestration-and-routing",
      "coverage": "direct"
    },
    {
      "type": "article",
      "label": "PCI DSS: what it protects",
      "href": "/2026/07/18/pci-dss-what-it-protects",
      "coverage": "derived"
    },
    {
      "type": "article",
      "label": "PSP, gateway, acquirer: who does what",
      "href": "/2026/07/18/psp-gateway-acquirer-who-does-what",
      "coverage": "derived"
    },
    {
      "type": "flow",
      "label": "Card payment authorization",
      "href": "/explore/card-authorization",
      "coverage": "direct"
    },
    {
      "type": "flow",
      "label": "Tokenized wallet payment",
      "href": "/explore/wallet-tokenized",
      "coverage": "direct"
    },
    {
      "type": "glossary",
      "label": "3-D Secure",
      "href": "/glossary#three-d-secure",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Account funding transaction (AFT)",
      "href": "/glossary#account-funding-transaction",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Acquirer",
      "href": "/glossary#acquirer",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Acquirer processor",
      "href": "/glossary#acquirer-processor",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Alternative payment method (APM)",
      "href": "/glossary#alternative-payment-method",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Arbitration",
      "href": "/glossary#arbitration",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Authorisation code",
      "href": "/glossary#authorization-code",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Authorisation hold",
      "href": "/glossary#authorization-hold",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "BIN",
      "href": "/glossary#bin",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Buy now, pay later (BNPL)",
      "href": "/glossary#buy-now-pay-later",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Card network",
      "href": "/glossary#card-network",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Card scheme rules",
      "href": "/glossary#card-scheme-rules",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Card-not-present",
      "href": "/glossary#card-not-present",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Card-present",
      "href": "/glossary#card-present",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Chargeback",
      "href": "/glossary#chargeback",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Chargeback reason code",
      "href": "/glossary#chargeback-reason-code",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Clearing record",
      "href": "/glossary#clearing-record",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Contactless payment",
      "href": "/glossary#contactless-payment",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Device tokenisation",
      "href": "/glossary#device-tokenization",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Digital wallet",
      "href": "/glossary#digital-wallet",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "DPAN",
      "href": "/glossary#dpan",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "EMV chip",
      "href": "/glossary#emv-chip",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Four-party model",
      "href": "/glossary#four-party-model",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Interchange fee",
      "href": "/glossary#interchange-fee",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Issuer",
      "href": "/glossary#issuer",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Issuer processor",
      "href": "/glossary#issuer-processor",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Liability shift",
      "href": "/glossary#liability-shift",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Merchant acquiring",
      "href": "/glossary#merchant-acquiring",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Merchant discount rate",
      "href": "/glossary#merchant-discount-rate",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Merchant of record",
      "href": "/glossary#merchant-of-record",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Network token",
      "href": "/glossary#network-token",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "PAN",
      "href": "/glossary#pan",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Pass-through wallet",
      "href": "/glossary#pass-through-wallet",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Payment facilitator",
      "href": "/glossary#payment-facilitator",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Payment facilitator model",
      "href": "/glossary#payment-facilitator-model",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Payment gateway",
      "href": "/glossary#payment-gateway",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Payment orchestration",
      "href": "/glossary#payment-orchestration",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Payment service provider (PSP)",
      "href": "/glossary#payment-service-provider",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "PCI DSS",
      "href": "/glossary#pci-dss",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Presentment",
      "href": "/glossary#presentment",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Representment",
      "href": "/glossary#representment",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Scheme fee",
      "href": "/glossary#scheme-fee",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Staged wallet",
      "href": "/glossary#staged-wallet",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Stand-in processing",
      "href": "/glossary#stand-in-processing",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Three-party model",
      "href": "/glossary#three-party-model",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Token requestor",
      "href": "/glossary#token-requestor",
      "coverage": "derived"
    },
    {
      "type": "glossary",
      "label": "Wallet provider",
      "href": "/glossary#wallet-provider",
      "coverage": "derived"
    },
    {
      "type": "topic",
      "label": "3-D Secure and strong customer authentication",
      "href": "/learn/cards/three-d-secure-and-sca",
      "coverage": "derived"
    },
    {
      "type": "topic",
      "label": "Alternative payment methods and BNPL",
      "href": "/learn/cards/alternative-payment-methods",
      "coverage": "derived"
    },
    {
      "type": "topic",
      "label": "Authorization: the first journey",
      "href": "/learn/cards/card-authorization",
      "coverage": "derived"
    },
    {
      "type": "topic",
      "label": "Clearing and settlement for cards",
      "href": "/learn/cards/card-clearing-and-settlement",
      "coverage": "derived"
    },
    {
      "type": "topic",
      "label": "Digital wallets and network tokenization",
      "href": "/learn/cards/digital-wallets-and-tokenization",
      "coverage": "derived"
    },
    {
      "type": "topic",
      "label": "Disputes and chargebacks",
      "href": "/learn/cards/card-disputes-and-chargebacks",
      "coverage": "derived"
    },
    {
      "type": "topic",
      "label": "PSPs, gateways, and orchestration",
      "href": "/learn/cards/psps-gateways-and-orchestration",
      "coverage": "derived"
    },
    {
      "type": "topic",
      "label": "The four-party model",
      "href": "/learn/cards/card-four-party-model",
      "coverage": "derived"
    },
    {
      "type": "topic",
      "label": "Tokenization and PCI DSS",
      "href": "/learn/cards/card-tokenization-and-pci-dss",
      "coverage": "derived"
    }
  ]
}