{ "generatedFrom": "Payments Signal canonical architecture registry", "reviewDate": "2026-07-23", "blueprint": { "id": "architecture-card-payments", "slug": "card-issuing-acquiring-settlement-chargebacks", "title": "Card issuing, acquiring, authorisation, clearing, settlement, and chargeback architecture", "shortTitle": "Card payments", "family": "channel", "summary": "Separate the real-time decision to approve a card purchase from later presentment, settlement, merchant funding, and dispute work.", "audience": "Card architects, acquiring and issuing teams, payment engineers, fraud and dispute specialists, and business analysts.", "reviewDate": "2026-07-23", "versionLabel": "Payments Signal reference architecture v1", "status": "current", "nodes": [ { "id": "card-holder-channel", "title": "Cardholder and acceptance channel", "kind": "channel", "summary": "Captures card or token credentials, amount, merchant, device, and authentication context.", "responsibilities": [ "Collect only necessary payment data", "Bind the transaction to the merchant and amount" ], "owner": "Merchant or wallet acceptance owner", "inputs": [ "Authorised business instruction and correlated state" ], "outputs": [ "Versioned result, status, and audit evidence" ], "interfaceContracts": [ "Versioned cardholder and acceptance channel contract", "Stable identifier, state, error, and audit contract" ], "controls": [ "Secure capture", "No sensitive authentication data in logs", "Device and merchant context" ], "failureModes": [ "Compromised terminal or checkout", "Duplicate customer submission" ], "recovery": [ "Stop capture and rotate affected credentials", "Reuse the merchant transaction reference" ], "lenses": [ "applications", "interfaces", "data", "controls", "operations", "resilience" ], "evidence": [ { "ref": { "sourceId": "pci-dss", "locator": "Cardholder-data environment and security requirements", "label": "official-requirement" }, "verifiedDate": "2026-07-23", "versionContext": "PCI DSS v4.0.1" }, { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-merchant", "title": "Merchant commerce and order service", "kind": "application", "summary": "Owns the order, creates one payment attempt, and separates order state from card-scheme state.", "responsibilities": [ "Create a stable merchant reference", "Fulfil only under an explicit payment policy" ], "owner": "Merchant commerce team", "inputs": [ "Authorised business instruction and correlated state" ], "outputs": [ "Versioned result, status, and audit evidence" ], "interfaceContracts": [ "Versioned merchant commerce and order service contract", "Stable identifier, state, error, and audit contract" ], "controls": [ "Amount and currency integrity", "Idempotent payment attempt", "No PAN in general application logs" ], "failureModes": [ "Order captured twice", "Goods released on an ambiguous authorisation" ], "recovery": [ "Query the payment attempt before retry", "Place fulfilment on hold while payment state is uncertain" ], "lenses": [ "applications", "interfaces", "data", "controls", "operations", "resilience" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-acquirer", "title": "Acquirer gateway and merchant processor", "kind": "gateway", "summary": "Validates the merchant, routes authorisation and presentment, and maintains acquiring records.", "responsibilities": [ "Authenticate merchant and terminal", "Route under acceptance and scheme rules" ], "owner": "Acquirer processing", "inputs": [ "Authorised business instruction and correlated state" ], "outputs": [ "Versioned result, status, and audit evidence" ], "interfaceContracts": [ "Versioned acquirer gateway and merchant processor contract", "Stable identifier, state, error, and audit contract" ], "controls": [ "Merchant status", "Message integrity", "Duplicate and velocity checks" ], "failureModes": [ "Invalid merchant", "Network timeout", "Duplicate presentment" ], "recovery": [ "Return a precise decline or uncertain state", "Reconcile before any resubmission" ], "lenses": [ "applications", "interfaces", "data", "controls", "operations", "resilience" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-network", "title": "Card network and switch", "kind": "external-network", "summary": "Routes authorisation and clearing records between acquirer and issuer and calculates scheme positions.", "responsibilities": [ "Route using network and product rules", "Carry correlated authorisation, clearing, and dispute data" ], "owner": "Card scheme or domestic switch", "inputs": [ "Authorised business instruction and correlated state" ], "outputs": [ "Versioned result, status, and audit evidence" ], "interfaceContracts": [ "Versioned card network and switch contract", "Stable identifier, state, error, and audit contract" ], "controls": [ "Participant eligibility", "Message and reason-code validation", "Network duplicate control" ], "failureModes": [ "Unavailable route", "Late presentment", "Invalid clearing record" ], "recovery": [ "Apply network retry or stand-in rules", "Reject or defer with a reason" ], "lenses": [ "applications", "interfaces", "data", "controls", "operations", "resilience" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-issuer", "title": "Issuer authorisation and card-control service", "kind": "control", "summary": "Checks account, credential, available funds, fraud, limits, and card controls before approving or declining.", "responsibilities": [ "Make one explainable authorisation decision", "Place or release a hold under product rules" ], "owner": "Issuer cards and fraud operations", "inputs": [ "Authorised business instruction and correlated state" ], "outputs": [ "Versioned result, status, and audit evidence" ], "interfaceContracts": [ "Versioned issuer authorisation and card-control service contract", "Stable identifier, state, error, and audit contract" ], "controls": [ "Credential validation", "Available funds", "Fraud and velocity", "Card and merchant controls" ], "failureModes": [ "False decline", "Approval without funds hold", "Duplicate hold" ], "recovery": [ "Use reversal or expiry rules", "Investigate with original authorisation evidence" ], "lenses": [ "applications", "interfaces", "data", "controls", "operations", "resilience" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-ledgers", "title": "Issuer, acquirer, and merchant books", "kind": "ledger", "summary": "Records holds, clearing postings, scheme settlement, fees, and merchant funding without treating authorisation as final settlement.", "responsibilities": [ "Separate hold from booked transaction", "Reconcile scheme settlement to merchant funding" ], "owner": "Issuer, acquirer, and finance teams", "inputs": [ "Authorised business instruction and correlated state" ], "outputs": [ "Versioned result, status, and audit evidence" ], "interfaceContracts": [ "Versioned issuer, acquirer, and merchant books contract", "Stable identifier, state, error, and audit contract" ], "controls": [ "Balanced posting", "Presentment-to-authorisation match", "Fee transparency" ], "failureModes": [ "Hold never released", "Presentment amount mismatch", "Merchant funding break" ], "recovery": [ "Release under documented expiry or reversal", "Open a financial break before correcting books" ], "lenses": [ "applications", "interfaces", "data", "controls", "operations", "resilience" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-clearing", "title": "Clearing, settlement, and merchant funding", "kind": "service", "summary": "Matches presentments, calculates participant positions, settles, and funds the merchant according to the network and acquiring agreement.", "responsibilities": [ "Validate and aggregate clearing records", "Fund merchants only from confirmed and reconciled obligations" ], "owner": "Scheme settlement and acquirer treasury", "inputs": [ "Authorised business instruction and correlated state" ], "outputs": [ "Versioned result, status, and audit evidence" ], "interfaceContracts": [ "Versioned clearing, settlement, and merchant funding contract", "Stable identifier, state, error, and audit contract" ], "controls": [ "File completeness", "Net-position balance", "Settlement evidence", "Reserve and fee rules" ], "failureModes": [ "Settlement failure", "Unbalanced batch", "Duplicate merchant funding" ], "recovery": [ "Stop the affected cycle", "Recalculate from immutable presentments", "Resume funding by stable batch key" ], "lenses": [ "applications", "interfaces", "data", "controls", "operations", "resilience" ], "evidence": [ { "ref": { "sourceId": "bis-cpmi-pfmi", "locator": "Principles 8, 9 and 24", "label": "official-requirement" }, "verifiedDate": "2026-07-23", "versionContext": "CPMI-IOSCO Principles for financial market infrastructures" }, { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-disputes", "title": "Dispute and chargeback case management", "kind": "operations", "summary": "Tracks retrieval, representment, arbitration, evidence, reason codes, deadlines, and financial adjustments.", "responsibilities": [ "Apply the correct dispute stage and deadline", "Keep evidence and financial postings linked" ], "owner": "Issuer and acquirer dispute operations", "inputs": [ "Authorised business instruction and correlated state" ], "outputs": [ "Versioned result, status, and audit evidence" ], "interfaceContracts": [ "Versioned dispute and chargeback case management contract", "Stable identifier, state, error, and audit contract" ], "controls": [ "Case eligibility", "Reason-code validation", "Evidence completeness", "Maker-checker adjustment" ], "failureModes": [ "Missed deadline", "Wrong reason code", "Financial adjustment without case evidence" ], "recovery": [ "Escalate before expiry", "Correct with a traceable case and journal" ], "lenses": [ "applications", "interfaces", "data", "controls", "operations", "resilience" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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" ] } ], "interfaces": [ { "id": "card-e1", "from": "card-holder-channel", "to": "card-merchant", "title": "Checkout payment attempt", "kind": "api", "mode": "synchronous", "purpose": "Bind credentials or token, amount, merchant, and customer intent.", "failureBehaviour": "Do not create a second attempt when the first response is uncertain.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-e2", "from": "card-merchant", "to": "card-acquirer", "title": "Authorisation request", "kind": "message", "mode": "synchronous", "purpose": "Request an issuer decision through the acquiring route.", "failureBehaviour": "Return approved, declined, or uncertain distinctly.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-e3", "from": "card-acquirer", "to": "card-network", "title": "Network authorisation", "kind": "message", "mode": "synchronous", "purpose": "Route the authorisation with network correlation data.", "failureBehaviour": "Use only permitted retry or stand-in treatment.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-e4", "from": "card-network", "to": "card-issuer", "title": "Issuer authorisation", "kind": "message", "mode": "synchronous", "purpose": "Obtain the issuer's decision and response reason.", "failureBehaviour": "Preserve timeout and late-response evidence.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-e5", "from": "card-issuer", "to": "card-ledgers", "title": "Authorisation hold", "kind": "posting", "mode": "synchronous", "purpose": "Reserve available funds without recording final settlement.", "failureBehaviour": "Release or reverse the hold under explicit rules.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-e6", "from": "card-acquirer", "to": "card-clearing", "title": "Presentment and clearing batch", "kind": "file", "mode": "batch", "purpose": "Submit captured transactions for clearing.", "failureBehaviour": "Reject duplicates or invalid records without silently dropping the batch.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-e7", "from": "card-network", "to": "card-clearing", "title": "Network positions", "kind": "settlement", "mode": "batch", "purpose": "Provide balanced issuer and acquirer obligations.", "failureBehaviour": "Stop settlement when the position set does not balance.", "evidence": [ { "ref": { "sourceId": "bis-cpmi-pfmi", "locator": "Principles 8 and 9", "label": "official-requirement" }, "verifiedDate": "2026-07-23", "versionContext": "CPMI-IOSCO Principles for financial market infrastructures" }, { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-e8", "from": "card-clearing", "to": "card-ledgers", "title": "Settlement and merchant funding", "kind": "posting", "mode": "batch", "purpose": "Post scheme settlement and merchant payable or funding.", "failureBehaviour": "Reconcile settlement before replaying a funding batch.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-e9", "from": "card-ledgers", "to": "card-disputes", "title": "Dispute financial state", "kind": "operator", "mode": "operator", "purpose": "Link the case to the original authorisation, presentment, and posting.", "failureBehaviour": "Keep the financial adjustment pending when evidence or eligibility is incomplete.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": "card-e10", "from": "card-disputes", "to": "card-network", "title": "Chargeback and response", "kind": "message", "mode": "asynchronous", "purpose": "Exchange reason-coded dispute actions and evidence.", "failureBehaviour": "Do not resubmit after a deadline or under an invented reason.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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": [ "card-holder-channel", "card-merchant", "card-network", "card-ledgers" ], "interfaceIds": [ "card-e1" ], "placements": { "card-holder-channel": { "x": 80, "y": 100, "width": 244, "height": 126 }, "card-merchant": { "x": 444, "y": 100, "width": 244, "height": 126 }, "card-network": { "x": 808, "y": 100, "width": 244, "height": 126 }, "card-ledgers": { "x": 80, "y": 326, "width": 244, "height": 126 } }, "boundaries": [ { "id": "context-bank-boundary", "label": "Institution-controlled boundary", "nodeIds": [ "card-holder-channel", "card-merchant", "card-ledgers" ], "kind": "ownership" } ] }, { "id": "container", "label": "Container", "plainPurpose": "The major applications, stores, gateways, controls, and operational ownership boundaries.", "nodeIds": [ "card-holder-channel", "card-merchant", "card-acquirer", "card-network", "card-issuer", "card-ledgers", "card-disputes" ], "interfaceIds": [ "card-e1", "card-e2", "card-e3", "card-e4", "card-e5", "card-e9", "card-e10" ], "placements": { "card-holder-channel": { "x": 80, "y": 100, "width": 196, "height": 126 }, "card-merchant": { "x": 376, "y": 100, "width": 196, "height": 126 }, "card-acquirer": { "x": 672, "y": 100, "width": 196, "height": 126 }, "card-network": { "x": 968, "y": 100, "width": 196, "height": 126 }, "card-issuer": { "x": 80, "y": 326, "width": 196, "height": 126 }, "card-ledgers": { "x": 376, "y": 326, "width": 196, "height": 126 }, "card-disputes": { "x": 672, "y": 326, "width": 196, "height": 126 } }, "boundaries": [ { "id": "container-bank-boundary", "label": "Institution-controlled boundary", "nodeIds": [ "card-holder-channel", "card-merchant", "card-acquirer", "card-issuer", "card-ledgers", "card-disputes" ], "kind": "ownership" } ] }, { "id": "component", "label": "Component", "plainPurpose": "The processing responsibilities and interface contracts that must cooperate for one payment.", "nodeIds": [ "card-holder-channel", "card-merchant", "card-acquirer", "card-network", "card-issuer", "card-ledgers", "card-clearing", "card-disputes" ], "interfaceIds": [ "card-e1", "card-e2", "card-e3", "card-e4", "card-e5", "card-e6", "card-e7", "card-e8", "card-e9", "card-e10" ], "placements": { "card-holder-channel": { "x": 80, "y": 100, "width": 196, "height": 126 }, "card-merchant": { "x": 376, "y": 100, "width": 196, "height": 126 }, "card-acquirer": { "x": 672, "y": 100, "width": 196, "height": 126 }, "card-network": { "x": 968, "y": 100, "width": 196, "height": 126 }, "card-issuer": { "x": 80, "y": 326, "width": 196, "height": 126 }, "card-ledgers": { "x": 376, "y": 326, "width": 196, "height": 126 }, "card-clearing": { "x": 672, "y": 326, "width": 196, "height": 126 }, "card-disputes": { "x": 968, "y": 326, "width": 196, "height": 126 } }, "boundaries": [ { "id": "component-bank-boundary", "label": "Institution-controlled boundary", "nodeIds": [ "card-holder-channel", "card-merchant", "card-acquirer", "card-issuer", "card-ledgers", "card-clearing", "card-disputes" ], "kind": "ownership" } ] }, { "id": "deployment", "label": "Deployment", "plainPurpose": "The trust zones, runtime dependencies, external connections, and recovery boundaries.", "nodeIds": [ "card-merchant", "card-acquirer", "card-network", "card-ledgers" ], "interfaceIds": [ "card-e2", "card-e3" ], "placements": { "card-merchant": { "x": 80, "y": 100, "width": 244, "height": 126 }, "card-acquirer": { "x": 444, "y": 100, "width": 244, "height": 126 }, "card-network": { "x": 808, "y": 100, "width": 244, "height": 126 }, "card-ledgers": { "x": 80, "y": 326, "width": 244, "height": 126 } }, "boundaries": [ { "id": "deployment-bank-boundary", "label": "Institution-controlled boundary", "nodeIds": [ "card-merchant", "card-acquirer", "card-ledgers" ], "kind": "ownership" } ] } ], "traces": [ { "id": "card-purchase-settlement", "label": "Purchase to merchant funding", "summary": "Follow one card purchase through authorisation, presentment, settlement, and merchant funding.", "viewId": "component", "steps": [ { "id": "card-purchase-settlement-step-1", "title": "Capture the payment", "nodeId": "card-holder-channel", "interfaceId": "card-e1", "plainExplanation": "The channel protects the credential and binds it to amount and merchant.", "businessState": "Customer intent captured" }, { "id": "card-purchase-settlement-step-2", "title": "Create one attempt", "nodeId": "card-merchant", "interfaceId": "card-e2", "plainExplanation": "The merchant records one stable payment attempt.", "businessState": "Order awaiting authorisation" }, { "id": "card-purchase-settlement-step-3", "title": "Route through the acquirer", "nodeId": "card-acquirer", "interfaceId": "card-e3", "plainExplanation": "The acquirer validates the merchant and selects the network route.", "businessState": "Authorisation routed" }, { "id": "card-purchase-settlement-step-4", "title": "Reach the issuer", "nodeId": "card-network", "interfaceId": "card-e4", "plainExplanation": "The network carries the request and correlation references.", "businessState": "Issuer decision requested" }, { "id": "card-purchase-settlement-step-5", "title": "Approve and hold", "nodeId": "card-issuer", "interfaceId": "card-e5", "plainExplanation": "The issuer approves and places a hold; this is not final settlement.", "businessState": "Approved, not settled", "ledgerEffect": "Available funds reduced by an authorisation hold." }, { "id": "card-purchase-settlement-step-6", "title": "Clear and settle", "nodeId": "card-clearing", "interfaceId": "card-e8", "plainExplanation": "The captured purchase enters clearing and participant positions settle.", "businessState": "Presentment settled" }, { "id": "card-purchase-settlement-step-7", "title": "Fund and reconcile", "nodeId": "card-ledgers", "plainExplanation": "Issuer, acquirer, scheme, and merchant books are reconciled.", "businessState": "Merchant funding recorded" } ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "verifiedDate": "2026-07-23", "versionContext": "Payments Signal reference architecture v1" }, { "ref": { "sourceId": "bis-cpmi-pfmi", "locator": "Principles 8 and 24", "label": "official-requirement" }, "verifiedDate": "2026-07-23", "versionContext": "CPMI-IOSCO Principles for financial market infrastructures" } ] } ], "stressCases": [ { "id": "card-stress-timeout", "label": "Authorisation times out", "trigger": "The acquirer receives no final issuer response.", "divergesAfterStepId": "card-purchase-settlement-step-4", "traceId": "card-purchase-settlement", "affectedNodeIds": [ "card-acquirer", "card-network", "card-issuer" ], "affectedInterfaceIds": [ "card-e3", "card-e4" ], "lastConfirmedState": "The request was routed; approval state is uncertain.", "settlementState": "No clearing or settlement has occurred.", "fundsState": "An issuer hold may or may not exist.", "owner": "Acquirer payment operations", "safeAction": "Return an uncertain outcome and query or reverse under network rules; do not create a fresh customer charge blindly.", "requiredEvidence": [ "Merchant reference", "Network reference", "Issuer response or reversal evidence" ], "recoverySteps": [ "Resolve the original attempt", "Release any orphan hold", "Reconcile late responses" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "verifiedDate": "2026-07-23", "versionContext": "Payments Signal reference architecture v1" } ] }, { "id": "card-stress-late-presentment", "label": "Late or mismatched presentment", "trigger": "Clearing arrives after the permitted window or for a different amount.", "divergesAfterStepId": "card-purchase-settlement-step-6", "traceId": "card-purchase-settlement", "affectedNodeIds": [ "card-clearing", "card-issuer", "card-ledgers" ], "affectedInterfaceIds": [ "card-e6", "card-e8" ], "lastConfirmedState": "Authorisation existed; clearing does not match it cleanly.", "settlementState": "Settlement depends on scheme treatment.", "fundsState": "The hold and booked transaction may differ.", "owner": "Issuer clearing operations", "safeAction": "Apply the current scheme rule; do not force-match unlike records.", "requiredEvidence": [ "Authorisation", "Presentment", "Reason and timing data" ], "recoverySteps": [ "Classify unmatched presentment", "Post under approved product rules", "Release or adjust the original hold" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "verifiedDate": "2026-07-23", "versionContext": "Payments Signal reference architecture v1" } ] }, { "id": "card-stress-chargeback", "label": "Chargeback evidence is incomplete", "trigger": "A dispute deadline approaches without required evidence.", "divergesAfterStepId": "card-purchase-settlement-step-7", "traceId": "card-purchase-settlement", "affectedNodeIds": [ "card-disputes", "card-network", "card-ledgers" ], "affectedInterfaceIds": [ "card-e9", "card-e10" ], "lastConfirmedState": "The original transaction settled.", "settlementState": "Settlement is not undone merely by opening a dispute.", "fundsState": "Any provisional credit must remain linked to the case.", "owner": "Dispute operations", "safeAction": "Escalate the case and make only rule-supported provisional or final adjustments.", "requiredEvidence": [ "Reason code", "Eligibility date", "Customer claim", "Merchant evidence" ], "recoverySteps": [ "Complete or withdraw the case", "Post the supported adjustment", "Reconcile scheme and customer books" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "verifiedDate": "2026-07-23", "versionContext": "Payments Signal reference architecture v1" } ] } ], "overlays": [ { "id": "card-overlay-authorization", "label": "Card authorisation", "summary": "Show the request, issuer decision, hold, and ambiguous-timeout boundary.", "nodeIds": [ "card-holder-channel", "card-merchant", "card-acquirer", "card-network", "card-issuer", "card-ledgers" ], "interfaceIds": [ "card-e1", "card-e2", "card-e3", "card-e4", "card-e5" ], "relatedFlowIds": [ "flow-card-authorization" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "verifiedDate": "2026-07-23", "versionContext": "Payments Signal reference architecture v1" } ] }, { "id": "card-overlay-clearing", "label": "Card clearing and settlement", "summary": "Show presentment, scheme positions, settlement, fees, and merchant funding.", "nodeIds": [ "card-acquirer", "card-network", "card-clearing", "card-ledgers" ], "interfaceIds": [ "card-e6", "card-e7", "card-e8" ], "relatedFlowIds": [ "flow-card-clearing-settlement" ], "evidence": [ { "ref": { "sourceId": "bis-cpmi-pfmi", "locator": "Principles 8, 9 and 24", "label": "official-requirement" }, "verifiedDate": "2026-07-23", "versionContext": "CPMI-IOSCO Principles for financial market infrastructures" }, { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "verifiedDate": "2026-07-23", "versionContext": "Payments Signal reference architecture v1" } ] }, { "id": "card-overlay-chargeback", "label": "Card chargeback", "summary": "Show dispute ownership, evidence, deadlines, scheme exchange, and financial adjustment.", "nodeIds": [ "card-disputes", "card-network", "card-ledgers" ], "interfaceIds": [ "card-e9", "card-e10" ], "relatedFlowIds": [ "flow-card-chargeback" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "verifiedDate": "2026-07-23", "versionContext": "Payments Signal reference architecture v1" } ], "coverageGap": "Exact reason codes, time limits, and evidence rules require the current applicable scheme rulebook." } ], "decisions": [ { "id": "card-decision-state", "question": "May the merchant treat authorisation as settlement?", "options": [ { "label": "Treat as approval only", "consequence": "Keeps fulfilment policy honest about later clearing and settlement." }, { "label": "Treat as final cash", "consequence": "Creates avoidable breaks when presentment, reversal, or settlement differs." } ], "guidance": "Model authorisation, capture, presentment, settlement, merchant funding, and dispute as separate states.", "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "verifiedDate": "2026-07-23", "versionContext": "Payments Signal reference architecture v1" } ] }, { "id": "card-decision-scope", "question": "Where should cardholder data be allowed?", "options": [ { "label": "Constrained cardholder-data environment", "consequence": "Reduces exposure but requires clear token and service boundaries." }, { "label": "Broad application access", "consequence": "Simplifies some integrations but expands security and assessment scope." } ], "guidance": "Minimise storage and transmission of cardholder data; prove boundaries rather than assuming token use removes scope.", "evidence": [ { "ref": { "sourceId": "pci-dss", "locator": "Scope and cardholder-data environment", "label": "official-requirement" }, "verifiedDate": "2026-07-23", "versionContext": "PCI DSS v4.0.1" } ] } ], "targets": [ { "type": "flow", "id": "flow-card-authorization" }, { "type": "flow", "id": "flow-card-clearing-settlement" }, { "type": "flow", "id": "flow-card-chargeback" } ], "glossaryTermIds": [ "acquirer", "authorisation", "card-network", "chargeback", "clearing", "issuer", "merchant", "presentment", "settlement" ], "evidence": [ { "ref": { "sourceId": "payments-signal-editorial", "locator": "Card issuing, acquiring, clearing, settlement, and disputes", "label": "simplified-educational-illustration", "simplifications": "Card scheme rules, processor contracts, regional regulation, product settings, and merchant arrangements vary. The topology teaches responsibility boundaries and does not reproduce a scheme rulebook." }, "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" }, { "ref": { "sourceId": "bis-cpmi-pfmi", "locator": "Principles 8, 9 and 24", "label": "official-requirement" }, "verifiedDate": "2026-07-23", "versionContext": "CPMI-IOSCO Principles for financial market infrastructures" } ], "simplifies": "This reference architecture shows common issuer, acquirer, network, clearing, settlement, merchant-funding, and dispute responsibilities. It omits scheme-specific message layouts, fees, interchange, stand-in rules, regional regulation, and precise dispute rights, all of which require current authorised material." }, "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": "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." }, { "id": "bis-cpmi-pfmi", "publisher": "CPMI and IOSCO (Bank for International Settlements)", "title": "Principles for financial market infrastructures", "sourceType": "industry-paper", "publicationDate": "2012-04-16", "accessedDate": "2026-07-12", "url": "https://www.bis.org/cpmi/publ/d101.htm", "applicability": "International risk-management standards for systemically important payment systems and other financial market infrastructures.", "notes": "Published by the CPSS (now CPMI) and IOSCO; contains 24 principles plus responsibilities for authorities. This site uses it only for high-level concepts such as settlement finality." } ], "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 clearing & settlement", "href": "/explore/card-clearing-settlement", "coverage": "direct" }, { "type": "flow", "label": "Card payment authorization", "href": "/explore/card-authorization", "coverage": "direct" }, { "type": "flow", "label": "Chargeback lifecycle", "href": "/explore/card-chargeback", "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" } ] }