The global payments graph

Payments 101

How a payment actually works. Payments are not a single line from A to B. They are a graph of customer experiences, rules, institutions, infrastructure, identifiers, messages, money movements and controls. This guide gives you the model to read that graph.

Method ≠ Scheme ≠ System. The brand a customer sees, the rules that govern it and the infrastructure that moves it are related—but not interchangeable.

01 · The payment graph

Start with the layers.

The same brand can appear in more than one role, but the roles remain conceptually distinct.

Read these as graph relationships, not four consecutive transaction hops. A method can use multiple schemes, a scheme can run across multiple systems, and an operator can run several methods, schemes or systems. In arrangements such as UPI or Pix, one branded ecosystem may fulfil several roles; Aurato keeps those roles separately queryable.

Then add the participants.

Organizations can perform more than one role. A PSP may also be an acquirer; a scheme operator may also operate infrastructure; a bank can issue, acquire and settle.

Payer

The person or organization whose account, balance or credit line funds the payment.

Merchant or payee

The recipient of the payment and the party that must reconcile the sale or transfer.

Issuer or payer bank

Provides the card or account, authenticates the payer and decides whether a card authorization or account instruction can proceed.

Acquirer or payee bank

Connects the merchant to acceptance and receives or settles funds on the merchant side.

PSP

Provides the merchant integration and may combine gateway, processing, acquiring, orchestration, fraud and reporting services.

Regulator

Defines or enforces the legal and supervisory perimeter, licenses participants and oversees market or systemic risk.

MarketsDefine jurisdiction, availability, local practice and regulatory scope.
CurrenciesDefine denomination, minor units, conversion and settlement context.
CardsRepresent individual issued products beneath card methods and schemes.
EconomicsAttach fees, rates and pricing rules to the layer and period where they apply.

02 · Transaction lifecycle

Information moves first. Money follows.

The familiar card lifecycle is useful, but not universal. Direct debits, instant transfers, wallets and vouchers combine or reorder some states.
  1. 01

    Initiation

    The payer or payee starts the payment and selects a method, amount, currency and recipient.

  2. 02

    Credential presentation

    A card, account, wallet token, alias, mandate or voucher credential identifies the funding source. Tokenization is used where the product supports it; it is not a universal step.

  3. 03

    Authentication

    The system establishes that the person is entitled to use the credential, for example with a PIN, biometrics, a banking app or 3D Secure.

  4. 04

    Authorization or validation

    The issuer, bank or provider checks status, funds or credit, limits, fraud signals and scheme rules. An approval reserves or validates value; it is not yet final settlement.

  5. 05

    Capture or confirmation

    For cards, the merchant confirms an authorized transaction for clearing. In other flows, confirmation may be part of initiation or occur only after the receiving party is credited.

  6. 06

    Clearing

    Participants exchange and reconcile payment data and calculate the obligations or net positions that must be settled.

  7. 07

    Settlement & funding

    Money moves between settlement accounts and is posted toward the payee. Settlement can be gross or net, real-time or deferred; merchant funding may still happen later.

  8. 08

    Reconciliation & exceptions

    Ledgers, fees and payouts are matched. Refunds, returns, reversals, disputes and chargebacks follow their own rules and do not simply replay the original payment backwards.

AuthenticationWho are you?
AuthorizationMay this payment proceed?
SettlementHave participant obligations been discharged?

03 · Payment methods

Different ways to pay create different flows.

A checkout label tells you what the user selects. It does not by itself tell you where funds are held, which scheme applies or how settlement works.

Cards

A card credential draws on debit funds, credit, charge or prepaid value. Four-party and three-party operating models distribute issuing, acquiring and network roles differently.

Bank Transfer / A2A

The payer moves funds from an account to another account through a credit-transfer scheme. Instant customer confirmation does not always mean real-time gross settlement.

Direct Debit

The payee collects from the payer’s account under a mandate. Clearing, settlement, return windows and refund rights differ from credit transfers.

Wallets

Pass-through wallets present a tokenized underlying credential; stored-value wallets maintain a balance or internal ledger. One brand can support both models.

BNPL

A credit product embedded at checkout. The provider pays or guarantees the merchant and collects from the consumer under an installment or deferred-payment agreement.

Vouchers

A code or stored entitlement is exchanged for value. Funding may have happened earlier through cash, card, bank transfer or payroll.

Offline

Cash and cash-assisted methods can begin or end outside a native digital flow, even when a digital reference, barcode or agent network coordinates the transaction.

Channel is not a rail. QR, contactless, in-app, web and in-person describe how a payment is initiated or accepted. The same QR code can initiate a card payment, bank transfer or wallet-ledger transfer.

Lifecycle dimensionCardInstant A2ADirect Debit
Primary instructionAuthorize and later capture a card transactionPush a credit transfer from one account to anotherCollect from the payer under a mandate
Who typically startsPayer at checkout; merchant capturesPayerPayee
Customer confirmationUsually authorization firstOften immediate for instant schemesOften notification rather than real-time approval
SettlementUsually separated from authorization and often nettedCan be real-time gross, real-time net or deferred netCommonly batch and net
Typical exceptionsReversal, refund, dispute, chargebackReject, return, recall, reimbursementReject, return, refund under scheme or legal rights

04 · Data & routing

Every payment depends on shared language.

Identifiers say who or what is involved. Standards say how participants describe, protect and exchange the instruction.
BIN

Bank Identification Number / Issuer Identification Number

Identifies an issuer and account range for card routing and enrichment. Six- and eight-digit representations coexist, while product attributes may require more granular account-range data.

BIC

Business Identifier Code

An 8- or 11-character identifier for an organization or branch used in financial messaging and participant reference data.

BSC

Bank and branch sort code

A domestic bank or branch routing identifier. Its format, authority and use are market-specific rather than globally uniform.

MCC

Merchant Category Code

A four-digit classification of a merchant’s primary activity used in acceptance, pricing, rewards, controls and risk decisions.

Common standards

Explore standards

ISO 8583

A message format family widely used in card authorization, clearing and related exchanges. Implementations are network-specific.

ISO 20022

A shared financial-services data model and message catalogue, commonly serialized as XML. Market practice determines which fields and messages are actually used.

EMV

Specifications for chip, contactless, QR and other payment-acceptance interactions.

EMV 3-D Secure

A protocol for exchanging authentication data in card-not-present payments; it is distinct from the issuer’s authorization decision.

PCI DSS

A security standard for protecting payment account data in environments that store, process or transmit it.

Tokenization

Replaces a sensitive credential with a constrained token. Device, merchant, gateway and network tokens have different domains and lifecycle controls.

05 · Economics

The price is more than one fee.

“MDR” or merchant pricing is an outcome of several economic layers. The applicable components vary by method, market, participant and contract.
01

Interchange

When applicable, a fee transferred between acquiring and issuing sides under scheme or regulatory rules.

02

Scheme or system fees

Charges for participation, switching, processing, clearing, settlement, assessments or specific services.

03

Acquirer / PSP markup

Commercial pricing for acceptance, processing, risk services, reporting, support and the merchant relationship.

04

Additional economics

Cross-border assessments, FX, financing, fraud, disputes, refunds, reserves, payout timing and operational costs can materially change the all-in cost.

Pricing follows risk allocation.

The issuer may carry credit and account risk; the acquirer may carry merchant and chargeback exposure; the PSP operates controls and the integration; the merchant carries delivery, refund and some fraud risk; scheme and legal rules decide how losses can move between them.

06 · Risk & compliance

Rules surround every node.

Compliance requirements, technical standards, scheme rules and regulatory authorities are connected—but they are not the same record type.
RegulatorThe authority that supervises or enforces.
ComplianceThe obligation, control or legal domain to manage.
StandardThe specification, rulebook or implementation framework.
EconomicsThe fee, rate or pricing parameter and its scope.

07 · Worked examples

Read three payments as graphs.

These simplified paths show how a recognizable checkout choice maps to several distinct layers.

Card + pass-through wallet

An Apple Pay card purchase

  1. MethodApple Pay is the customer-facing wallet experience.
  2. CredentialA device or network token represents the underlying card; biometrics can authenticate the wallet user.
  3. Scheme & systemThe underlying card’s scheme rules and card system carry the authorization, clearing and settlement messages.
  4. ParticipantsThe merchant’s PSP/acquirer sends the request; the issuer decides whether to authorize it.
  5. MoneyAuthorization reserves value first. Capture, clearing, settlement and merchant funding follow separately.

Instant account-to-account

A Pix payment

  1. MethodPix is the payer-facing payment proposition, often initiated through a bank or wallet app.
  2. SchemePix rules define participation and the payment experience.
  3. DirectoryDICT can resolve a Pix key to the receiving account and participant.
  4. SystemFor inter-participant flows, SPI provides real-time settlement infrastructure.
  5. OperatorBanco Central do Brasil operates and oversees key parts of the arrangement.

Multi-app A2A ecosystem

A UPI app payment

  1. MethodThe user may choose BHIM, PhonePe, Google Pay or another UPI-enabled app.
  2. SchemeUPI rules define the interoperable account-to-account proposition.
  3. SystemNPCI switching and related infrastructure route and process instructions between participants.
  4. BanksThe payer and payee accounts remain with participating banks or other eligible account providers.
  5. OperatorNPCI operates the UPI arrangement and infrastructure roles represented as distinct connections in the graph.

Keep these distinctions

Six common shortcuts that break the model.

“Authorized” means “paid.”

Authorization is a decision or reservation. Clearing, settlement, posting and merchant funding are separate states.

“Instant” always means RTGS.

The customer can receive an immediate result while participant obligations settle gross, net or on a different timetable.

A wallet is a rail.

A wallet may pass through a card or bank-transfer rail, use its own stored-value ledger, or combine several funding paths.

Scheme and system are synonyms.

A scheme governs rights and obligations; a system performs technical processing, clearing or settlement functions.

The operator is another hop.

The operator owns or runs a graph node. A transaction message does not necessarily pass through the operator as a separate participant.

Overlay and underlying volumes can be added.

A wallet or checkout overlay and its underlying card or bank transfer can describe the same transaction. Analytics must define the counting layer to avoid double counting.