Card payment process flowchart (purchase response to capture)
Card payment process flowchart for purchase initiation, secure data capture, authorization response, merchant proceed-or-cancel action, release messaging and capture handoff.
What the card payment process flowchart (purchase response to capture) process is
A card payment begins as a time-sensitive purchase conversation, not as settled money. The cardholder confirms the purchase, the merchant creates the order and amount, and the gateway or processor captures and protects the payment data. Invalid details loop back before authentication or merchant risk screening can create an authorization attempt.
When local controls permit the request, the acquirer validates it, the card network routes it, and the issuer returns an approval or decline. A local stop has its own non-authorization result because the issuer was never asked. After approval, the merchant decides whether the order remains active. Cancellation stays a merchant action, followed by a separate gateway or processor handoff for the supported reversal, advice and hold-release messaging. An active order is confirmed and submitted to capture with its authorization reference intact.
Downstream processing is deliberately compressed into three steps: the network exchanges clearing records and issues instructions from calculated positions, a settlement agent or bank settles the institutional obligations, and the acquirer releases merchant funding. Use the card transaction lifecycle or clearing and settlement template when those later states and exceptions need operational detail.
What this flowchart covers
In this template
- Purchase initiation and protected payment-data capture with correction before local controls run
- Authentication and merchant risk screening separated from the issuer's authorization decision
- Authorization request and response handoffs across the acquirer, card network and issuer
- Merchant proceed-or-cancel authority separated from gateway or processor reversal and hold-release messaging
- A capture correction loop and compact context for clearing, settlement and merchant funding
When to use this template
- Product, operations and finance teams use authorization, capture, clearing and settlement as if they were interchangeable events
- A merchant needs one vendor-neutral view of real-time handoffs without turning checkout into a settlement map
- Declines and capture exceptions are handled outside the order record, making ownership and customer outcomes unclear
- The real-time checkout flow is obscured by downstream settlement detail and the merchant decision point is missing
- Teams need a purchase-level map with an explicit boundary to later lifecycle and finance procedures
How it works
Map your actual parties
Replace generic lanes with the parties in your acquiring and processing arrangement. A provider may perform several roles, but the request, response and fund-movement responsibilities should remain visible.
Define the authorization controls
Document required payment data, authentication paths, merchant risk decisions, request references and customer-safe response handling for each supported channel.
Set capture triggers
State when capture may be submitted, who corrects rejected records, and how merchant cancellation requests the supported reversal or hold-release handling from the gateway or processor. Keep capture separate from the earlier authorization decision.
Keep downstream compact
Name the clearing-data owner, settlement agent or bank, and merchant-funding owner, then link to detailed clearing and reconciliation procedures rather than duplicating them here.
Define the handoff record
Choose the references and status fields that leave checkout with the accepted capture so later records can be tied back to the purchase without rewriting its real-time outcome.
Frequently asked questions
What are the main steps in a card payment process?
A purchase-level map creates the order and amount, captures protected payment data, performs authentication and merchant risk checks, routes an authorization request to the issuer, returns the response, lets the merchant proceed or decline, and hands an approved purchase to capture. Clearing, settlement and merchant funding appear only as downstream context.
Does authorization mean the merchant has received the money?
No. Authorization is an issuer decision that may reserve availability. Capture advances the transaction, clearing establishes participant positions, a settlement agent or bank moves funds between institutions, and merchant funding follows the acquiring agreement. Their timing and posting effect depend on the arrangement.
Why separate processor, network and settlement actors?
They are distinct logical roles even when one provider performs several. A processor transports merchant messages, a card network exchanges authorization and clearing data or issues settlement instructions, and a settlement agent or bank performs institutional fund movement. Annotate combined providers without assigning money movement to a data-routing role.
How should this template handle card declines and exceptions?
Keep local stops distinct from issuer declines and retain the original transaction reference for capture correction. If an approved order is canceled, record the merchant decision first, then send only the reversal, advice or hold-release message supported by the gateway or processor integration.
Where this process fits
In most operations this process hands off to Payment authorization process flowchart (request to capture).
It is one step in Card payment lifecycle.
Step 1: Card payment process flowchart (purchase response to capture) You are here
Card payment process flowchart for purchase initiation, secure data capture, authorization response, merchant proceed-or-cancel action, release messaging and capture handoff.
Step 2: Payment authorization process flowchart (request to capture)
Payment authorization process flowchart for data validation, authentication and risk controls, request routing, issuer response, unknown-outcome inquiry and capture handoff.
Step 3: Card transaction lifecycle flowchart (initiation to monitoring)
Step 4: Payment clearing and settlement process flowchart template
Step 5: Payment reconciliation process flowchart (records to settlement)