Authorization, capture, void, and refund are different state changes
A developer lifecycle for choosing the right operation and waiting for asynchronous outcomes.
Source-checked guide
FOR DEVELOPERS / DESIGN FOR THE EXCEPTIONS
A successful request
is only one state.
Build a clearer model of the payment, the event and the ledger. These guides focus on failure handling and responsibilities—not copy-and-paste production guarantees.
BUSINESS INTENT
One order.
Name the operation and its stable identifier.
PROVIDER STATE
Several events.
Verify, deduplicate and check authoritative status.
YOUR RECORDS
A reconciled result.
Separate fulfillment, refunds and the eventual payout.
Original conceptual diagram. Not a provider protocol or implementation specification. Read the provider-specific sources in the guides below.
BUILD A RELIABLE MENTAL MODEL
Start at the failure boundary.
Retry a payment API call without creating a second operation
A developer pattern for stable operation identities, bounded retries, ambiguous outcomes, and reconciliation.
Source-checked guide
Treat payment webhooks as signed, repeated, out-of-order messages
A receiver design for raw-body signature verification, durable intake, deduplication, ordering, and replay-safe effects.
Source-checked guide
Hosted checkout reduces PCI scope; it does not erase the merchant boundary
A boundary map for redirects, embedded forms, scripts, merchant systems, providers, and SAQ eligibility.
Source-checked guide
Recover recurring payments without surprising the customer
A customer-safe dunning design that separates retryable failures, account updates, notices, grace, and cancellation.
Source-checked guide
Use ISO 20022 remittance data to match invoices, not just move richer text
An accounts-receivable workflow for identifiers, structured remittance, allocation rules, exceptions, and audit trails.
Source-checked guide
Developers & product teams / 5 READS
Build for the payment that goes wrong
Separate payment states, repeat requests safely, and handle delayed or duplicated events without charging twice.
01 / OPEN READING PATH →Curious readers & product teams / 5 READSFollow the instruction and the funds
Distinguish a push from a pull, an instant request from a payment, and useful data from settled money.
02 / OPEN READING PATH →