Appendices

Appendix C — Comparison Matrices

Side-by-side comparisons from across the book. Rows are terse by design — the chapter pointer has the nuance.

Network vs Gateway vs PSP vs Orchestrator

Who you contract with, who touches the money, who owns the risk. See Chapter 5.

DimensionCard networkGatewayPSPOrchestrator
What it isThe rails + rulebookTechnical message courierFull-stack acceptance providerRouter above multiple PSPs
Contracts with merchantNoSometimesYesYes (software contract)
Holds merchant fundsNoNoYes (merchant of record models vary)No
Owns fraud/credit riskSets rules, arbitratesNoYes, underwrites youNo
ExamplesVisa, MastercardAuthorize.net-styleStripe, Adyen, RapydSpreedly-style, in-house

Single-Message vs Dual-Message

One message or two — the split that separates PIN debit from everything else. See Chapter 10.

DimensionSingle-messageDual-message
Auth and clearingOne combined messageSeparate auth, then clearing
Typical usePIN debit, ATMCredit, signature debit, e-commerce
Capture later?No — immediateYes — tip adjust, delayed capture
ReversalsHarder, money movedVoid before capture is cheap

Network Tokens vs PSP Tokens vs Vault Tokens

Three tokens that all "replace the PAN" and behave nothing alike. See Chapter 12.

DimensionNetwork token (DPAN)PSP tokenVault token
Issued byCard networkYour PSPYour vault (own or third-party)
Survives card reissueYes — auto-updatedOnly via account updaterOnly via account updater
Portable across PSPsYesNo — lock-inYes — you control export
PCI scope for youLowLowVault provider dependent

Billing Model vs Payment Method Suitability

Match how you charge to how the money moves. See Chapter 17.

Billing modelCardsDirect debitBank transfer / VAWallets
Fixed subscriptionStrong (with dunning)Strong, cheap, revocableWeak — manualMarket dependent
Usage-based / meteredStrong — MIT on fileGood for large B2B sumsGood with VAs for B2BWeak
One-off invoice (B2B)Costly at sizePossibleStrong — VA reconciliationWeak
Marketplace payoutsN/A (push needed)N/AStrongRegional

Push vs Pull Rails

Who initiates decides who bears the failure modes. See Chapters 18 and 20.

DimensionPush (credit transfer, RTP)Pull (cards, direct debit)
Initiated byPayerPayee (with authorization/mandate)
Insufficient funds riskNone — fails upfrontReturns/declines after the fact
ReversibilityLow — often finalHigh — chargebacks, DD refunds
Merchant fearCustomer forgets to payMoney clawed back later
ReconciliationNeeds references/VAsBuilt into scheme reporting

Cards vs RTP vs Stablecoins vs Crypto

Loading interactive…

The cross-rail scorecard. See Chapter 29.

DimensionCardsRTP / instant transfersStablecoinsNative crypto
Speed to finalDays (T+1/T+2)Seconds–minutesSeconds–minutesMinutes–hours
ReversibleYes — disputesMostly noNo (issuer freeze aside)No
Consumer protectionStrong, scheme rulesThinContractual onlyNone
ReachGlobal brand acceptanceDomestic schemesWallet + ramp dependentNiche
Cost profilePercentage + interchangeFlat, lowNear-zero rail, ramps costVolatile fees

Closed-Loop vs Open-Loop Agentic Architecture

The cleavage that actually predicts agentic-payment traction. See Chapter 33.

DimensionClosed loop (e.g. Alipay)Open loop (Western stack)
Who owns model, catalog, railOne entity, one trust domainDifferent parties per layer
Credential handoffNone neededTokenized across trust boundaries
Risk visibilityFull transaction graphFragmented per participant
LiabilityOne responsible partyContested across the chain
Integration costZero incrementalAdapter glue at every seam
The Money AtlasAppendix C — Comparison Matrices