LearningMODULE 01 · PAYMENTS 101 · LESSON 01
Map the stack
Know who controls the checkout, credentials, messages, and money.The core model
Vault/Orchestration sits before the gateway.
The merchant owns the customer experience. The orchestration layer can decide where a transaction goes. The vault controls how payment credentials are stored and represented. Gateways and processors connect the request to acquiring services, networks, and issuers.
Interactive system map
Payments ecosystem
Checkout ownership
What system actually controls the merchant’s checkout?
The merchant owns the customer relationship, but another platform may render the payment experience, handle credentials, create tokens, or decide where the transaction goes.
Identify who renders the payment form, touches card data, creates the token, controls routing, and owns transaction state.
Vault data path
Collect safely. Return a token. Route only when needed.
A vault receives sensitive payment data, stores and tokenizes it inside a protected boundary, and returns a token that the merchant can keep. The token may be reused for future payments when the merchant’s use case and customer authorization allow it.
The vault provider renders the sensitive fields, so card data is submitted directly to the vault rather than the merchant’s systems.
Usually the smallest merchant data footprint.A provider library securely collects and sends payment data to the vault. The exact PCI scope depends on how the SDK and page are implemented.
More design control; verify the actual data path.The merchant server receives or transmits raw card data before calling the vault, putting that environment in a much larger PCI DSS scope.
Use when the control is worth the compliance burden.Payment method enters the vault boundary.
Vault protects the credential and creates a token.
Merchant stores the token—not the raw card number.
Token supports later payments and approved endpoints.
Outbound / forward proxy
Send a token to a payment endpoint.
The merchant sends a token and request toward the vault. Inside its protected boundary, the vault reveals the credential and forwards the request to an approved gateway, processor, or other endpoint. The merchant does not handle the raw value again.
Inbound / reverse proxy
Tokenize before data reaches the merchant.
The vault receives an incoming structured or unstructured payload, identifies and tokenizes sensitive fields, then forwards a sanitized payload to the merchant. The merchant receives tokens in place of raw payment data.
Orchestration control plane
One integration layer. Merchant-controlled payment logic.
An orchestrator—sometimes described as a routing or retry engine—holds the gateway integrations and gives the merchant one place to define how payment attempts should be sent, retried, observed, and reconciled.
Maintains the technical connectors, credentials, request mappings, webhooks, and provider-specific operations behind a normalized merchant interface.
Lets the merchant define rules using geography, currency, payment method, cost, performance, risk, availability, or business preference—and specify when another attempt is appropriate.
Creates a common transaction model across providers so authorizations, captures, refunds, failures, and provider responses can be analyzed together.
Surfaces payment KPIs and gateway performance by geography or segment. More complete platforms can also fetch settlement files and reconcile provider records against transaction activity.
The analysis layer
From provider events to merchant insight.
A useful dashboard explains approval performance, failure reasons, latency, retries, gateway health, and regional differences—not just total volume.
- Authorization and conversion KPIs
- Gateway performance by geography
- Decline and retry outcomes
- Provider latency and availability
- Settlement-file ingestion
- Reconciliation status and exceptions
Gateway boundary
A gateway contract creates a credential handoff.
When the merchant signs a gateway agreement, the provider issues security and account credentials. Those credentials must be configured in the upstream vault or orchestration platform—depending on the architecture—so it can authenticate and send transactions to that gateway.
- 01Contract
The merchant establishes the commercial and processing relationship.
- 02Credentials
The gateway provides API keys or secrets, merchant IDs, certificates, account identifiers, or routing configuration.
- 03Upstream configuration
The merchant configures those credentials in its vault, orchestration platform, or payment integration layer.
The boundary is fluid
The gateway may also provide the layers around the connection.
A gateway can be a simple connection, or it can bundle capabilities that otherwise sit in a vault, risk platform, authentication provider, or orchestrator.
Processor setup
The processor relationship creates a VAR sheet.
A VAR sheet—also called a tear sheet or parameter sheet—contains the merchant-account and processor configuration that the gateway needs to route and settle transactions correctly.
- 01Processor and acquiring relationship
The merchant is boarded to a processor and acquiring bank under a merchant account.
- 02VAR sheet issued
The processor, acquirer, or merchant-services provider supplies processor details, merchant and terminal identifiers, supported card types, and routing parameters.
- 03Gateway configured
The VAR-sheet parameters are entered into the gateway so it can connect the merchant account to the correct processor.
Processor
Runs the technical message path.
The processor sends and receives authorization, clearing, and settlement-related messages with the card network and maintains the technical connections and transaction processing required across the gateway, acquiring bank, and network.
- Authorization and response messaging
- Capture, clearing, refund, and reversal processing
- Network and acquirer connectivity
- Settlement records and operational files
Acquiring bank
Sponsors and underwrites the merchant.
The acquiring bank is the network member that sponsors the merchant into card acceptance, underwrites the merchant relationship, and establishes or issues the merchant account used to accept card payments.
- Merchant underwriting and risk ownership
- Network sponsorship
- Merchant-account relationship
- Settlement into the acquiring side
Roles, not logos
One provider may bundle several jobs.
Underwrites the cardholder, issues the account, and approves or declines each transaction.
Sponsors and underwrites the merchant and establishes the merchant-account relationship for card acceptance.
Connects the merchant checkout or payment stack to processing services.
Runs the technical message path across the gateway, acquiring bank, and card network and supplies merchant-account configuration through a VAR sheet.
Unifies gateway integrations, applies merchant routing and retry logic, normalizes transaction data, and may provide analytics, settlement-file ingestion, and reconciliation.
Collects, stores, and tokenizes credentials, then proxies them to approved endpoints so the merchant can reduce raw-data exposure and avoid dependence on one gateway’s token.
Gateway, processor, acquiring bank, and sales organization may be separate or bundled. Evaluate the capability, not the label.
A concrete example
Stripe can bundle the connection, processing, and orchestration layers.
A merchant may use Stripe as its gateway and payment-processing provider. With Stripe Orchestration, the same platform can also manage routing, retries, and performance across Stripe and other processors. One commercial name can therefore represent several different jobs in the stack.
Architecture choice
Bundled simplicity or modular resilience?
Neither extreme is automatically correct. The merchant chooses where simplicity is worth concentration risk—and where independence is worth added operating complexity.
- Fewer integrations, contracts, credentials, and vendor relationships
- More unified data, support, and operational workflows
- Greater concentration and lock-in risk
- A shared outage can affect several payment capabilities at once
- Independent vault, orchestration, and processing boundaries
- More options for failover, portability, and provider replacement
- More integrations, contracts, data normalization, and reconciliation
- More vendors and incident ownership for the merchant to coordinate
MODULE CHECK
