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.
What the payment authorization process flowchart (request to capture) process is
Authorization asks whether a payment may proceed; it does not settle funds. The flow validates the amount, credential and order context before protecting the data and running payer authentication and merchant risk controls. Only a request that passes locally receives an attempt reference and enters the acquirer and card-network route to the issuer.
A local stop returns its own non-authorization result and ends without passing through any issuer outcome question. For submitted requests, the flow distinguishes a received issuer response from a timeout or unknown result. An approval records the hold reference, while a decline closes as an issuer decision.
Unknown does not mean declined and does not authorize a blind retry. Status inquiry reuses the original attempt reference, and the order remains blocked until that attempt is resolved. Confirmed approval is then handed to capture only if the order is still valid; release handling owns an approval that is no longer needed. Inquiry and reversal capabilities should match the documented integration.
What this flowchart covers
In this template
- Payment and order data capture with a correction loop before protected authorization context is created
- Payer authentication and merchant risk screening with a local non-authorization path that bypasses issuer outcome handling
- Acquirer, card network and issuer handoffs tied to one authorization attempt reference
- Issuer approval or decline without describing authorization as clearing, settlement or merchant funding
- Timeout inquiry using the original reference, with retry blocked until the first attempt is resolved
When to use this template
- Checkout teams need a shared map of merchant, gateway, acquirer, card network and issuer responsibilities
- A timeout is currently converted into a new authorization attempt without checking the original outcome
- Authentication failures, merchant risk stops and issuer declines are stored as one ambiguous status
- Order systems proceed before a definitive authorization result or lose the reference needed for later capture
- Teams need to separate the payment authorization process from capture, clearing, settlement and chargeback handling
How it works
Define required request data
List the amount, currency, credential, merchant, order and channel context required by the integration. Validate it before creating the authorization attempt so corrections do not become duplicate requests.
Configure authentication and risk
Document the authentication paths and merchant risk controls that apply by channel. Keep a local stop distinct from an issuer decline and keep sensitive decision logic out of customer-facing responses.
Preserve one attempt reference
Generate or retain a reference that every participant and status query can associate with the same attempt. Record request, response and state transitions without overwriting earlier events.
Design unknown-outcome handling
Use supported inquiry or controlled investigation before any new request. Define how long an order can remain blocked and who owns an attempt whose definitive status cannot yet be recovered.
Set the capture handoff
Specify the approval data and business trigger required by capture. If the order is no longer valid, remove it from the capture queue and open the supported release or reversal handling.
Frequently asked questions
What happens during payment authorization?
The merchant validates the payment and order context, protects the data, and performs authentication and risk checks. A local stop returns without asking an issuer-outcome question. A permitted attempt is referenced and routed to the issuer; a received approval or decline follows one path, while a timeout enters status inquiry.
Does an authorization approval transfer funds?
No. Approval indicates that the issuer permits the request and may reserve availability. Capture, clearing, settlement and merchant funding are later states with separate records and owners. Approval should not be reported as collected cash.
What should happen after an authorization timeout?
Treat the result as unknown until the original attempt can be checked. Query with its reference and block retry because the first request may have succeeded even though the response was lost. If inquiry cannot resolve it, keep an owned investigation rather than inventing a decline.
When should an approved authorization be captured?
Capture should follow a confirmed approval and the merchant's business trigger, such as purchase acceptance or fulfillment. The handoff needs the approved amount and reference. Timing and support for delayed or adjusted capture come from the acquiring and processing arrangement.
Where this process fits
In most operations this process follows Transaction Risk Assessment Process Flowchart and hands off to Card transaction lifecycle flowchart (initiation to monitoring).
It is one step in Card payment lifecycle.
Step 1: 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.
Step 2: Payment authorization process flowchart (request to capture) You are here
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)
Card transaction lifecycle flowchart for definitive or unknown authorization outcomes, reference-based status inquiry, capture, clearing, settlement, funding and closure.
Step 4: Payment clearing and settlement process flowchart template
Step 5: Payment reconciliation process flowchart (records to settlement)