Every animated end-to-end flow on PayProbe, in one place — card authorization, clearing and settlement, 3-D Secure, tokenization, open banking, EUDI Wallet SCA, TR-34 key exchange, stablecoin checkout, cards, ramps and refunds, agentic payments and more. Each diagram steps through the actors and messages with an explanation per hop.
63 scenarios · 25 flows
Card Rails
Card Authorization
27 steps
💳
Card PresentIn-store chip or contactless payment — from card tap through online authorization, clearing, and final settlement of funds to the merchant.
🛒
E-commerce (3DS)Card-not-present online checkout with EMV 3-D Secure (SCA) — from checkout through risk-based or challenge authentication to authorization.
Auth → Clearing → SettlementThe three phases of a card payment. Authorization is real-time and only reserves funds; clearing and settlement run in batch (typically T+1/T+2) and actually move the money.
⚖️
Dispute & ChargebackWhen a cardholder disputes a transaction it enters a structured, multi-stage process between issuer, scheme, and acquirer — potentially ending in scheme arbitration.
Authorization (0100/0110)A request/response pair travels from the terminal to the issuer and back. The MTI changes from request (x100/x200) to response (x110/x210) on the return path.
↩️
Reversal (0400/0410)When a transaction fails after authorization — timeout, no response, or a void — a reversal unwinds the issuer hold so funds are not left reserved.
FrictionlessEMV 3DS2 risk-based authentication where the issuer ACS approves on data alone — no cardholder interaction. The common path for low-risk transactions.
🔐
ChallengeWhen risk or regulation requires a step-up, the issuer ACS challenges the cardholder directly (OTP, app approval, or biometric) before returning the result.
ProvisioningAdding a card to a wallet (Apple Pay / Google Pay). The real PAN (FPAN) is exchanged for a device token (DPAN) after the issuer verifies the cardholder (ID&V).
📲
Tokenized PaymentA wallet payment uses the DPAN and a one-time cryptogram. The network de-tokenizes back to the real FPAN before routing the authorization to the issuer.
Apple Pay — In-AppThe cardholder taps "Add to Apple Wallet" in the bank app. The bank never encrypts on the phone: its backend encrypts the card for the payment network using Apple’s certificate chain and a one-time nonce, and the network’s token service issues a Device Account Number into the Secure Element.
🤖
Google Wallet — PushThe Android bank app calls pushTokenize with an Opaque Payment Card (OPC): card data the issuer (or its processor) encrypted for the network token service. Google carries it without being able to read it; the TSP issues a cloud (HCE) token.
➕
Start in Apple WalletWith issuer Wallet Extensions (iOS 14+), the user starts in Apple Wallet itself — tap +, pick the bank — and adds the card without opening the bank app. Two app extensions do the work: one to list cards, one to sign the user in.
🟡
Yellow path — app-to-appThe issuer asked for more verification (manual add, or a risky push). Instead of an SMS code the wallet sends the user to the bank app, which confirms the token and returns an activation result.
PSP vault tokenThe classic card-on-file setup: the PSP stores the real card number (PAN) in its PCI DSS vault and gives the merchant an opaque reference. The merchant is out of PCI scope, but every payment still travels to the network with the real PAN.
🔐
Network token enrolmentA token requestor (usually the PSP, on behalf of the merchant) swaps the stored PAN for a network token from Visa Token Service or Mastercard MDES. The token only works at this merchant, in e-commerce, and follows the card when it is reissued.
🔑
Checkout with a cryptogramEach customer-initiated payment with a network token carries a one-time cryptogram that the token requestor fetches from the TSP just before authorizing. The network checks it, swaps the token for the PAN and sends the issuer both.
🔁
Recurring payment + card reissueA subscription charges the network token without the customer present. Later the bank reissues the card; the token stays the same and the next charge still goes through.
Vault tokenizationYour own token service with a vault: the card number is stored once, everything else in your systems holds a random token, and only the payment service can swap it back when it is time to authorize.
🔐
Vaultless FF1No database: the token is the card number encrypted with FF1 format-preserving encryption, so it has the same length and digits. Anyone holding the key can turn it back, so the key becomes the thing to protect.
🎁
Closed-loop cardStore, gift, fuel and campus cards need no Visa or Mastercard at all: the issuer is also the network and the acquirer, so its own token or card number is authorized in-house.
🎟️
Google Wallet passA gift or store card saved to Google Wallet as a pass. The pass carries the custom token as a rotating barcode, so a screenshot stops working after a few seconds, and the till checks it against the program host.
📶
Tap with your own appAn Android app uses host card emulation to present the custom token over NFC with its own application ID. Each tap carries a one-time cryptogram from a limited-use key, like a network wallet — but only terminals set up for this AID accept it.
Issuer on a network TSPThe common setup: Visa VTS or Mastercard MDES runs the token service, and the issuer answers its questions. It approves each new token, sends one-time codes when it wants step-up, and is told when the token is live.
🔒
Lost card lifecycleThe cardholder loses the plastic card. The issuer blocks the card but only suspends its tokens; when the new card is issued, it updates the TSP so every wallet and merchant token keeps working.
🏗️
Issuer as its own TSPA few issuers and domestic schemes run the token service themselves: they issue tokens from their own token BIN ranges, keep the vault, generate the cryptogram keys and de-tokenize in authorization.
Payment Initiation (Redirect)A "pay by bank" checkout under PSD2: the PISP creates the payment order over the ASPSP's API, the payer is redirected to their bank for SCA with dynamic linking, and the payment settles as a (usually instant) credit transfer — no card rails involved.
🔍
Account Access Consent (AIS)How an AISP gets read access to accounts: an explicit consent resource is created at the bank, the PSU authorises it with SCA once, and the AISP then reads balances and transactions within that consent's scope and lifetime.
SCA Payment AuthenticationPSD2 strong customer authentication run through the EUDI Wallet: the issuer's ACS acts as an OID4VP verifier, the wallet shows the holder the exact amount and payee, and the WSCD-signed presentation becomes an authentication code with dynamic linking built in.
🪪
Credential Issuance (OID4VCI)How a credential gets into the wallet over OID4VCI: the holder authenticates to the issuer at the required assurance level, the wallet proves possession of a hardware-bound key, and the issuer returns a selectively disclosable credential bound to that key.
Merchant-Presented (MPM)The merchant displays an EMV QR code (static or dynamic); the consumer scans it with their wallet app to initiate and authorise the payment.
📱
Consumer-Presented (CPM)The consumer's wallet generates a one-time QR / barcode; the merchant scanner reads it and pushes the transaction, like a contactless tap.
Pay-in (Payment Link)A customer tops up a platform account with stablecoins via a BVNK Payment Link: the platform creates a payment with a live quote, BVNK generates a unique deposit address, the customer sends funds on-chain, and BVNK converts and settles into the platform's wallet — in fiat, a different stablecoin, or the same one.
🔁
Pay-in (Channel Top-up)Channels are permanent, re-usable deposit addresses assigned one per customer: any amount sent at any time is converted at the spot rate and credited — the neobank pattern, with no new payment link per top-up.
📤
Payout (Two-step)A platform pays out stablecoins from a fiat balance with a locked quote: validate the destination address, create the payout with twoStep=true to freeze the rate, then confirm within the quote window to execute — BVNK handles conversion, gas, and broadcast.
Classic fiat settlementHow card settlement works today: authorization and clearing over ISO 8583 and clearing files, then net settlement in fiat through the network's settlement bank on business days — which is why a Friday-evening transaction is usually not settled until Monday.
🪙
Stablecoin settlementThe same authorization and clearing, but the network and its members settle in a regulated stablecoin on a public chain — every day of the week. Visa settles with issuers in USDC, EURC, PYUSD and USDG and is extending seven-day settlement to acquirers; Mastercard accepts six coins on eight chains.
🌍
Cross-border payoutA platform pays a freelancer abroad: fiat in, stablecoin across the border, local currency out through the destination country's instant-payment rail — the corridor pattern payout providers use instead of correspondent banking.
Unique deposit addressThe most common checkout: the processor quotes the order in a coin, issues a fresh deposit address for it, and the customer pushes a transfer from any wallet or exchange. Token transfers carry no payment reference, so the address is the reference.
🔳
Payment request (Solana Pay / EIP-681)The merchant encodes exactly what to pay — recipient, token, amount and a reference — in a URI or QR code, and the wallet builds the transfer. Solana Pay’s reference key makes the payment findable on-chain; EIP-681 on EVM chains has no reference field.
✍️
Signed authorization (EIP-3009)The customer signs an off-chain authorization instead of sending a transaction; the processor submits it and pays the gas. The payer needs no gas token, the amount and payee are exact, and the authorization’s nonce is a natural payment id. The same primitive underlies x402.
🔐
Authorize & capture (escrow)Card-style authorize, capture, void and refund on-chain: the payer signs once, an operator moves the funds into an escrow contract at authorization, and captures (fully, partially or in several parts) when the order ships. The open-source Commerce Payments Protocol on Base is the reference design.
💵
Merchant settled in fiatThe merchant accepts stablecoins but never holds them: the processor credits the merchant in dollars or euros and pays out to its bank account on a normal payout schedule. This is how most card-acquirer and PSP stablecoin acceptance launches.
Card on a custodial balanceA Visa or Mastercard card funded by a stablecoin balance the provider holds for the user. The merchant, acquirer and network see an ordinary card payment; the stablecoin is only the funding source, and the issuer can settle with the network in fiat or in USDC.
🗝️
Card on a self-custody walletThe user keeps the stablecoins in their own smart wallet or a collateral contract; the card issuer is allowed to pull from it within limits. Authorization still runs in seconds over ISO 8583, so the issuer approves against collateral it can already see, and moves the coins afterwards.
⚖️
Chargeback on a stablecoin cardBecause the payment ran on card rails, the cardholder keeps card dispute rights — something a direct on-chain payment never has. The chargeback runs through the network as usual; only the final credit lands in stablecoins.
On-ramp: buy with card or bankA user buys USDC with a card, ACH or SEPA payment and receives it in their own wallet. The provider’s core risk is releasing an irreversible token against a fiat payment that can still be reversed.
⬇️
Off-ramp: sell to a bank accountA user sells USDC for euros paid to their bank account. The order is mirrored: the irreversible leg (the on-chain transfer) comes first, so the provider’s risk shifts to compliance on the incoming funds.
🏭
Primary mint & redeemHow stablecoins come into and leave existence: an onboarded institution wires dollars to the issuer, which mints tokens 1:1 to the institution’s verified address — and burns them when they are sent back for redemption. Everyone else buys and sells on the secondary market.
B2B supplier payment (Travel Rule)A company pays a supplier invoice in USDC through regulated custodians on both sides. The compliance data travels between the custodians before the transfer; the invoice reference travels off-chain and is joined to the transfer by its hash.
🌉
Cross-chain USDC (CCTP burn & mint)Moving USDC between chains without a bridge’s wrapped token: Circle’s Cross-Chain Transfer Protocol burns USDC on the source chain and, once Circle attests to the burn, mints the same amount of native USDC on the destination.
RefundThere is no reversal on-chain: a refund is a new transfer from the merchant (or processor) to the customer. The hard part is not the transfer but where to send it.
🔄
Subscription (spend permission)Recurring billing without asking for an unlimited approval: the subscriber signs a permission that lets the merchant pull at most a fixed amount per period, until an end date, revocable at any time.
🚧
Exceptions: wrong chain, short, late, frozenWhat a processor does when a transfer does not match its invoice. Nothing can be reversed, so every exception is resolved with a decision and, usually, a new transfer — the matcher below applies these rules to any combination.
Human PresentThe user approves the exact checkout. The merchant signs the checkout, the user signs a closed Checkout Mandate and a closed Payment Mandate on a trusted surface — both bound to the checkout by its hash — and each verifier returns a signed receipt.
🌙
Human Not Present"Buy the tickets when they drop, at most $1000." The user signs open Checkout and Payment Mandates with constraints and the agent’s key, then leaves. The agent later signs the closed mandates itself; verifiers check the agent key, the binding and every constraint.
Tokenised-Deposit PaymentA cross-border payment on SWIFT's shared ledger: the sending bank records a commitment, smart-contract logic runs the compliance gate, the receiving bank confirms on-ledger, tokenised deposits move with immediate finality, and the ledger coordinates final settlement on existing infrastructure — available 24/7.
TR-34 Two-PassRemote symmetric key (KEK) distribution to an HSM/terminal using RSA. The two-pass protocol binds the key to a fresh nonce from the receiving device to prevent replay.
➡️
TR-34 One-PassA streamlined push where the host already holds the receiving device credentials, so no live nonce exchange is needed — used for bulk or pre-provisioned distribution.
Contactless Tap (ISO 14443)The low-level handshake between a contactless reader (PCD) and card/phone (PICC): RF activation, anti-collision, protocol activation, then the EMV application exchange.
DESFire EV3 (AES)A modern MIFARE tap: ISO 14443-4 activation, application selection, AES mutual authentication (AuthenticateEV2First), then encrypted-and-MACed reads and an atomic value transaction — the pattern behind transit purses and access badges.
⚠️
Classic (Crypto1) — brokenThe legacy MIFARE Classic 3-pass authentication over the proprietary Crypto1 cipher — worth understanding because a huge installed base still runs it, and because every step shown here has a published attack.
Trade → Risk → SettlementHow one trade moves through Nasdaq Calypso without leaving the platform: booked in the front office, it updates risk and P&L in real time, feeds collateral, and is confirmed, settled and booked to the sub-ledger — all off the same shared trade object.