What happens after
you press Pay?
Follow an online card payment through fraud checks, authentication and authorisation, then trace the response and the money back. Choose a scenario and step through it.
An illustrative online card payment. The order of checks and the participants vary by provider and transaction.All stages in this scenario
Read the scenarios below. Enable JavaScript to follow them on the interactive map.
Approved
A card payment with fraud screening, frictionless 3DS and the full route to payout.
The customer presses Pay.
The customer agrees to the amount and submits the order.
The merchant creates an order reference and a payment attempt. Repeated clicks or a lost connection should not create duplicate charges.
For the merchant: Keep the basket and payment attempt linked. A submitted order is still unpaid.
Payment details go to the provider.
In this example, the provider’s payment fields collect the card details and return a reference.
Tokenisation lets the integration use a reference instead of passing the full card number through the merchant’s application. The provider also receives the amount, currency and relevant checkout data.
For the merchant: Check the amount on the server and handle duplicate requests consistently.
The provider checks for fraud.
This attempt passes the provider’s initial risk screening.
Signals can include the device, transaction history, unusual payment velocity and merchant rules. Some checks happen here; others depend on the issuer response. A low risk result is not a guarantee that a payment is genuine.
For the merchant: Review the signals and the outcome. An approved rule is only one part of the payment decision.
The 3DS request is prepared.
The 3DS server gathers the transaction and device information needed for authentication.
3D Secure is a separate exchange from payment authorisation. It can be requested because of the payment setup, applicable requirements or a risk decision. This example uses 3DS.
For the merchant: Keep the checkout open while authentication is in progress.
The request reaches the issuer’s ACS.
The scheme directory routes the authentication request to the issuer’s Access Control Server.
The issuer evaluates the available information and decides whether to authenticate without a visible challenge or ask the customer to do more. The scheme’s 3DS directory is a different service from its authorisation routing.
For the merchant: Measure authentication separately from authorisation. They can fail at different points.
The authentication result returns.
The issuer’s result returns through the 3DS services to the provider.
The provider can include the relevant authentication data in the authorisation request. Here, the issuer authenticates without a visible challenge: a frictionless 3DS flow.
For the merchant: Continue with authorisation. The order has not been paid yet.
Send an authorisation request.
The provider submits the payment to the acquiring side.
The request includes the amount, currency, merchant and card information, plus authentication data where applicable. Gateway, processing and acquiring services can belong to one business or several.
For the merchant: Use the same order reference, and distinguish this attempt from any earlier attempt.
The acquirer forwards the request.
The acquiring processor sends the authorisation message to the card network.
The acquiring side checks and formats the request for the relevant scheme. Technical acceptance of the message is not an approval of the customer’s payment.
For the merchant: Separate a routing or integration error from a payment decline.
The network routes it to the issuer.
The scheme sends the request to the card’s issuing side.
Routing identifies the issuer and its processor. Network services can provide additional checks or processing; stand-in and outage handling are outside this example.
For the merchant: Record the references needed to trace the request across providers.
The issuer checks the account and the risk.
The issuer assesses card status, funds or credit, limits and its own fraud controls.
The issuer’s decision is separate from the provider’s fraud screening. Supported security and address checks can also produce response data for the acquiring side. Not every issuer supplies the same detail.
For the merchant: A payment can pass provider screening and still be declined by the issuer.
The issuer sends an approval.
The issuer approves this attempt and places an authorisation hold.
The approval response travels back over the payment network. The hold reduces the customer’s available funds or credit; it does not put the money in the merchant’s bank account.
For the merchant: Treat this as authorised. Capture and settlement are still to follow.
The response returns through the network.
The scheme carries the issuer’s response back to the acquiring processor.
The response relates to the original authorisation attempt. Approval or decline information and available response data travel back with it.
For the merchant: Retain the response and reference, including for failed attempts.
The acquirer returns the result to the provider.
The provider receives the issuer response from the acquiring side.
The customer’s browser has not made this decision. A successful HTTP request or a checkout redirect alone cannot establish the payment outcome.
For the merchant: Update the payment using a verified provider result.
The provider checks the returned data.
The provider applies any remaining rules that depend on the response.
For example, CVC or address-check results may become available with authorisation. Depending on the setup, a rule can still lead to a review, rejection or reversal of an authorised payment. This example is allowed to continue.
For the merchant: Look at the provider’s final payment status as well as the issuer approval.
The merchant receives the authorisation.
The server records the authorised payment and the checkout shows the appropriate result.
Use a verified API result or signed webhook to update the order. An authorised payment waiting for capture should not be described as settled or paid out.
For the merchant: Keep the order, payment and customer confirmation consistent.
The merchant requests capture.
The merchant instructs the provider to capture the authorised amount.
Some integrations capture automatically; others send a separate request. This example captures the full authorised amount. Partial capture and changes to the amount have their own rules.
For the merchant: Capture the amount agreed with the customer before the authorisation expires.
The capture result updates the order.
The provider confirms the capture result and the merchant updates the order.
A successful capture is a different state from settlement and payout. The server should handle repeated notifications without creating duplicate fulfilment or duplicate records.
For the merchant: Send the customer the appropriate confirmation and record the payment once.
Clearing exchanges the financial records.
The captured transaction is presented through the acquiring side and scheme for clearing.
Clearing reconciles the transaction details and calculates obligations between participants, including the relevant scheme arrangements and fees. These are financial records; this message is not itself a merchant bank deposit.
For the merchant: Match the cleared amount and references to the captured payment.
Settlement moves value between participants.
The issuing and acquiring sides settle their obligations through the scheme’s arrangements.
Settlement commonly involves net obligations across many transactions. The diagram follows one payment to explain it; it does not imply a separate bank transfer for every purchase.
For the merchant: Expect the settlement record to include adjustments and fees under your agreement.
The provider records the merchant balance.
The payment is reflected in the merchant’s provider balance.
The merchant-facing provider may also be the acquirer. Available balance, reserves, fees and payout timing depend on the arrangement; a provider balance is not the same as money in the merchant’s bank.
For the merchant: Reconcile payments, adjustments and the provider balance.
The payout reaches the merchant’s bank.
The provider pays the available balance to the merchant’s bank account.
A payout can combine many payments, refunds, disputes and fees. Its schedule and bank-arrival time are separate from the time each customer paid.
For the merchant: Reconcile the bank deposit to the payout, then back to the underlying activity.
3DS challenge
The issuer asks the customer to verify, then makes a separate payment decision.
The customer presses Pay.
The customer agrees to the amount and submits the order.
The merchant creates an order reference and a payment attempt. Repeated clicks or a lost connection should not create duplicate charges.
For the merchant: Keep the basket and payment attempt linked. A submitted order is still unpaid.
Payment details go to the provider.
In this example, the provider’s payment fields collect the card details and return a reference.
Tokenisation lets the integration use a reference instead of passing the full card number through the merchant’s application. The provider also receives the amount, currency and relevant checkout data.
For the merchant: Check the amount on the server and handle duplicate requests consistently.
The provider checks for fraud.
This attempt passes the provider’s initial risk screening.
Signals can include the device, transaction history, unusual payment velocity and merchant rules. Some checks happen here; others depend on the issuer response. A low risk result is not a guarantee that a payment is genuine.
For the merchant: Review the signals and the outcome. An approved rule is only one part of the payment decision.
The 3DS request is prepared.
The 3DS server gathers the transaction and device information needed for authentication.
3D Secure is a separate exchange from payment authorisation. It can be requested because of the payment setup, applicable requirements or a risk decision. This example uses 3DS.
For the merchant: Keep the checkout open while authentication is in progress.
The request reaches the issuer’s ACS.
The scheme directory routes the authentication request to the issuer’s Access Control Server.
The issuer evaluates the available information and decides whether to authenticate without a visible challenge or ask the customer to do more. The scheme’s 3DS directory is a different service from its authorisation routing.
For the merchant: Measure authentication separately from authorisation. They can fail at different points.
The issuer asks the customer to verify.
The customer sees a challenge, such as approval in their banking app.
The issuer controls the authentication method. The challenge is an exchange with the cardholder; the acquirer is not asking the customer for their banking password.
For the merchant: Explain what the customer needs to do and preserve their order if they leave the checkout.
The customer completes the challenge.
In this example, the customer successfully completes the issuer’s check.
A completed challenge supplies an authentication result. It does not check that sufficient funds are available or guarantee that the subsequent payment will be approved.
For the merchant: Wait for the result. Do not treat a return to the website as proof of payment.
The authentication result returns.
The issuer’s result returns through the 3DS services to the provider.
The provider can include the relevant authentication data in the authorisation request. The customer completed a challenge.
For the merchant: Continue with authorisation. The order has not been paid yet.
Send an authorisation request.
The provider submits the payment to the acquiring side.
The request includes the amount, currency, merchant and card information, plus authentication data where applicable. Gateway, processing and acquiring services can belong to one business or several.
For the merchant: Use the same order reference, and distinguish this attempt from any earlier attempt.
The acquirer forwards the request.
The acquiring processor sends the authorisation message to the card network.
The acquiring side checks and formats the request for the relevant scheme. Technical acceptance of the message is not an approval of the customer’s payment.
For the merchant: Separate a routing or integration error from a payment decline.
The network routes it to the issuer.
The scheme sends the request to the card’s issuing side.
Routing identifies the issuer and its processor. Network services can provide additional checks or processing; stand-in and outage handling are outside this example.
For the merchant: Record the references needed to trace the request across providers.
The issuer checks the account and the risk.
The issuer assesses card status, funds or credit, limits and its own fraud controls.
The issuer’s decision is separate from the provider’s fraud screening. Supported security and address checks can also produce response data for the acquiring side. Not every issuer supplies the same detail.
For the merchant: A payment can pass provider screening and still be declined by the issuer.
The issuer sends an approval.
The issuer approves this attempt and places an authorisation hold.
The approval response travels back over the payment network. The hold reduces the customer’s available funds or credit; it does not put the money in the merchant’s bank account.
For the merchant: Treat this as authorised. Capture and settlement are still to follow.
The response returns through the network.
The scheme carries the issuer’s response back to the acquiring processor.
The response relates to the original authorisation attempt. Approval or decline information and available response data travel back with it.
For the merchant: Retain the response and reference, including for failed attempts.
The acquirer returns the result to the provider.
The provider receives the issuer response from the acquiring side.
The customer’s browser has not made this decision. A successful HTTP request or a checkout redirect alone cannot establish the payment outcome.
For the merchant: Update the payment using a verified provider result.
The provider checks the returned data.
The provider applies any remaining rules that depend on the response.
For example, CVC or address-check results may become available with authorisation. Depending on the setup, a rule can still lead to a review, rejection or reversal of an authorised payment. This example is allowed to continue.
For the merchant: Look at the provider’s final payment status as well as the issuer approval.
The merchant receives the authorisation.
The server records the authorised payment and the checkout shows the appropriate result.
Use a verified API result or signed webhook to update the order. An authorised payment waiting for capture should not be described as settled or paid out.
For the merchant: Keep the order, payment and customer confirmation consistent.
The merchant requests capture.
The merchant instructs the provider to capture the authorised amount.
Some integrations capture automatically; others send a separate request. This example captures the full authorised amount. Partial capture and changes to the amount have their own rules.
For the merchant: Capture the amount agreed with the customer before the authorisation expires.
The capture result updates the order.
The provider confirms the capture result and the merchant updates the order.
A successful capture is a different state from settlement and payout. The server should handle repeated notifications without creating duplicate fulfilment or duplicate records.
For the merchant: Send the customer the appropriate confirmation and record the payment once.
Clearing exchanges the financial records.
The captured transaction is presented through the acquiring side and scheme for clearing.
Clearing reconciles the transaction details and calculates obligations between participants, including the relevant scheme arrangements and fees. These are financial records; this message is not itself a merchant bank deposit.
For the merchant: Match the cleared amount and references to the captured payment.
Settlement moves value between participants.
The issuing and acquiring sides settle their obligations through the scheme’s arrangements.
Settlement commonly involves net obligations across many transactions. The diagram follows one payment to explain it; it does not imply a separate bank transfer for every purchase.
For the merchant: Expect the settlement record to include adjustments and fees under your agreement.
The provider records the merchant balance.
The payment is reflected in the merchant’s provider balance.
The merchant-facing provider may also be the acquirer. Available balance, reserves, fees and payout timing depend on the arrangement; a provider balance is not the same as money in the merchant’s bank.
For the merchant: Reconcile payments, adjustments and the provider balance.
The payout reaches the merchant’s bank.
The provider pays the available balance to the merchant’s bank account.
A payout can combine many payments, refunds, disputes and fees. Its schedule and bank-arrival time are separate from the time each customer paid.
For the merchant: Reconcile the bank deposit to the payout, then back to the underlying activity.
Fraud block
The provider stops the payment before it reaches the issuer.
The customer presses Pay.
The customer agrees to the amount and submits the order.
The merchant creates an order reference and a payment attempt. Repeated clicks or a lost connection should not create duplicate charges.
For the merchant: Keep the basket and payment attempt linked. A submitted order is still unpaid.
Payment details go to the provider.
In this example, the provider’s payment fields collect the card details and return a reference.
Tokenisation lets the integration use a reference instead of passing the full card number through the merchant’s application. The provider also receives the amount, currency and relevant checkout data.
For the merchant: Check the amount on the server and handle duplicate requests consistently.
The provider blocks the attempt.
A fraud rule stops this payment before an authorisation request is sent.
Provider screening can use transaction history, device and behavioural signals, velocity checks and merchant rules. A provider block is different from an issuer decline. This example stops before the issuer is contacted.
For the merchant: The order stays unpaid. Offer an appropriate next step without disclosing your fraud rules.
The block returns to the checkout.
The provider reports the unsuccessful attempt to the merchant.
There is no issuer approval, capture or payout in this example. The merchant may offer another payment method or review the attempt, depending on the situation.
For the merchant: Avoid blaming the customer’s bank for a decision made by the provider.
Issuer decline
Provider checks pass, but the issuer declines. Follow that decision back to the customer.
The customer presses Pay.
The customer agrees to the amount and submits the order.
The merchant creates an order reference and a payment attempt. Repeated clicks or a lost connection should not create duplicate charges.
For the merchant: Keep the basket and payment attempt linked. A submitted order is still unpaid.
Payment details go to the provider.
In this example, the provider’s payment fields collect the card details and return a reference.
Tokenisation lets the integration use a reference instead of passing the full card number through the merchant’s application. The provider also receives the amount, currency and relevant checkout data.
For the merchant: Check the amount on the server and handle duplicate requests consistently.
The provider checks for fraud.
This attempt passes the provider’s initial risk screening.
Signals can include the device, transaction history, unusual payment velocity and merchant rules. Some checks happen here; others depend on the issuer response. A low risk result is not a guarantee that a payment is genuine.
For the merchant: Review the signals and the outcome. An approved rule is only one part of the payment decision.
The 3DS request is prepared.
The 3DS server gathers the transaction and device information needed for authentication.
3D Secure is a separate exchange from payment authorisation. It can be requested because of the payment setup, applicable requirements or a risk decision. This example uses 3DS.
For the merchant: Keep the checkout open while authentication is in progress.
The request reaches the issuer’s ACS.
The scheme directory routes the authentication request to the issuer’s Access Control Server.
The issuer evaluates the available information and decides whether to authenticate without a visible challenge or ask the customer to do more. The scheme’s 3DS directory is a different service from its authorisation routing.
For the merchant: Measure authentication separately from authorisation. They can fail at different points.
The authentication result returns.
The issuer’s result returns through the 3DS services to the provider.
The provider can include the relevant authentication data in the authorisation request. Here, the issuer authenticates without a visible challenge: a frictionless 3DS flow.
For the merchant: Continue with authorisation. The order has not been paid yet.
Send an authorisation request.
The provider submits the payment to the acquiring side.
The request includes the amount, currency, merchant and card information, plus authentication data where applicable. Gateway, processing and acquiring services can belong to one business or several.
For the merchant: Use the same order reference, and distinguish this attempt from any earlier attempt.
The acquirer forwards the request.
The acquiring processor sends the authorisation message to the card network.
The acquiring side checks and formats the request for the relevant scheme. Technical acceptance of the message is not an approval of the customer’s payment.
For the merchant: Separate a routing or integration error from a payment decline.
The network routes it to the issuer.
The scheme sends the request to the card’s issuing side.
Routing identifies the issuer and its processor. Network services can provide additional checks or processing; stand-in and outage handling are outside this example.
For the merchant: Record the references needed to trace the request across providers.
The issuer checks the account and the risk.
The issuer assesses card status, funds or credit, limits and its own fraud controls.
The issuer’s decision is separate from the provider’s fraud screening. Supported security and address checks can also produce response data for the acquiring side. Not every issuer supplies the same detail.
For the merchant: A payment can pass provider screening and still be declined by the issuer.
The issuer declines the attempt.
The issuer does not authorise this payment.
The response may provide a usable reason, but merchants do not necessarily see the issuer’s complete decision. This is an issuer decline, not a provider fraud block.
For the merchant: Keep the order unpaid and choose the next action from the actual response.
The response returns through the network.
The scheme carries the issuer’s response back to the acquiring processor.
The response relates to the original authorisation attempt. Approval or decline information and available response data travel back with it.
For the merchant: Retain the response and reference, including for failed attempts.
The acquirer returns the result to the provider.
The provider receives the issuer response from the acquiring side.
The customer’s browser has not made this decision. A successful HTTP request or a checkout redirect alone cannot establish the payment outcome.
For the merchant: Update the payment using a verified provider result.
The checkout offers another way to pay.
The merchant receives the decline and gives the customer an appropriate next step.
The right response depends on the decline. A different payment method, corrected information or contacting the issuer may help; automatic repeated attempts are not always appropriate.
For the merchant: Preserve the basket and explain the next action without exposing internal fraud logic.
3DS retry
An authentication-required response comes back from the issuer. The provider authenticates and tries again.
The customer presses Pay.
The customer agrees to the amount and submits the order.
The merchant creates an order reference and a payment attempt. Repeated clicks or a lost connection should not create duplicate charges.
For the merchant: Keep the basket and payment attempt linked. A submitted order is still unpaid.
Payment details go to the provider.
In this example, the provider’s payment fields collect the card details and return a reference.
Tokenisation lets the integration use a reference instead of passing the full card number through the merchant’s application. The provider also receives the amount, currency and relevant checkout data.
For the merchant: Check the amount on the server and handle duplicate requests consistently.
The provider checks for fraud.
This attempt passes the provider’s initial risk screening.
Signals can include the device, transaction history, unusual payment velocity and merchant rules. Some checks happen here; others depend on the issuer response. A low risk result is not a guarantee that a payment is genuine.
For the merchant: Review the signals and the outcome. An approved rule is only one part of the payment decision.
This attempt proceeds without completed 3DS.
The provider initially attempts authorisation without a completed 3DS result.
Whether this is permitted depends on the transaction and setup. The issuer can still require authentication. This example follows that response and a supported retry.
For the merchant: Let the payment integration handle the required next action.
Send an authorisation request.
The provider submits the payment to the acquiring side.
The request includes the amount, currency, merchant and card information, plus authentication data where applicable. Gateway, processing and acquiring services can belong to one business or several.
For the merchant: Use the same order reference, and distinguish this attempt from any earlier attempt.
The acquirer forwards the request.
The acquiring processor sends the authorisation message to the card network.
The acquiring side checks and formats the request for the relevant scheme. Technical acceptance of the message is not an approval of the customer’s payment.
For the merchant: Separate a routing or integration error from a payment decline.
The network routes it to the issuer.
The scheme sends the request to the card’s issuing side.
Routing identifies the issuer and its processor. Network services can provide additional checks or processing; stand-in and outage handling are outside this example.
For the merchant: Record the references needed to trace the request across providers.
The issuer checks the account and the risk.
The issuer assesses card status, funds or credit, limits and its own fraud controls.
The issuer’s decision is separate from the provider’s fraud screening. Supported security and address checks can also produce response data for the acquiring side. Not every issuer supplies the same detail.
For the merchant: A payment can pass provider screening and still be declined by the issuer.
The issuer asks for authentication.
The issuer returns a soft decline indicating that authentication is needed.
No approval is granted on this attempt. For a supported authentication-required response, the provider can take the customer through 3DS and submit a new authorisation request.
For the merchant: Follow the provider’s authentication flow instead of repeatedly sending the same request.
The response returns through the network.
The scheme carries the issuer’s response back to the acquiring processor.
The response relates to the original authorisation attempt. Approval or decline information and available response data travel back with it.
For the merchant: Retain the response and reference, including for failed attempts.
The acquirer returns the result to the provider.
The provider receives the issuer response from the acquiring side.
The customer’s browser has not made this decision. A successful HTTP request or a checkout redirect alone cannot establish the payment outcome.
For the merchant: Update the payment using a verified provider result.
The checkout receives the next action.
The provider tells the integration that authentication is required before the payment can continue.
The checkout follows the provider’s next-action instructions and starts the customer authentication flow. The first authorisation remains declined; this is not a successful payment.
For the merchant: Keep the order pending and guide the customer into authentication.
The 3DS request is prepared.
The 3DS server gathers the transaction and device information needed for authentication.
3D Secure is a separate exchange from payment authorisation. It can be requested because of the payment setup, applicable requirements or a risk decision. This example uses 3DS.
For the merchant: Keep the checkout open while authentication is in progress.
The request reaches the issuer’s ACS.
The scheme directory routes the authentication request to the issuer’s Access Control Server.
The issuer evaluates the available information and decides whether to authenticate without a visible challenge or ask the customer to do more. The scheme’s 3DS directory is a different service from its authorisation routing.
For the merchant: Measure authentication separately from authorisation. They can fail at different points.
The issuer asks the customer to verify.
The customer sees a challenge, such as approval in their banking app.
The issuer controls the authentication method. The challenge is an exchange with the cardholder; the acquirer is not asking the customer for their banking password.
For the merchant: Explain what the customer needs to do and preserve their order if they leave the checkout.
The customer completes the challenge.
In this example, the customer successfully completes the issuer’s check.
A completed challenge supplies an authentication result. It does not check that sufficient funds are available or guarantee that the subsequent payment will be approved.
For the merchant: Wait for the result. Do not treat a return to the website as proof of payment.
The authentication result returns.
The issuer’s result returns through the 3DS services to the provider.
The provider can include the relevant authentication data in the authorisation request. The customer completed a challenge.
For the merchant: Continue with authorisation. The order has not been paid yet.
Send the new authorisation request.
The provider submits the payment to the acquiring side.
The request includes the amount, currency, merchant and card information, plus authentication data where applicable. Gateway, processing and acquiring services can belong to one business or several.
For the merchant: Use the same order reference, and distinguish this attempt from any earlier attempt.
The acquirer forwards the request.
The acquiring processor sends the authorisation message to the card network.
The acquiring side checks and formats the request for the relevant scheme. Technical acceptance of the message is not an approval of the customer’s payment.
For the merchant: Separate a routing or integration error from a payment decline.
The network routes it to the issuer.
The scheme sends the request to the card’s issuing side.
Routing identifies the issuer and its processor. Network services can provide additional checks or processing; stand-in and outage handling are outside this example.
For the merchant: Record the references needed to trace the request across providers.
The issuer checks the account and the risk.
The issuer assesses card status, funds or credit, limits and its own fraud controls.
The issuer’s decision is separate from the provider’s fraud screening. Supported security and address checks can also produce response data for the acquiring side. Not every issuer supplies the same detail.
For the merchant: A payment can pass provider screening and still be declined by the issuer.
The issuer sends an approval.
The issuer approves this attempt and places an authorisation hold.
The approval response travels back over the payment network. The hold reduces the customer’s available funds or credit; it does not put the money in the merchant’s bank account.
For the merchant: Treat this as authorised. Capture and settlement are still to follow.
The response returns through the network.
The scheme carries the issuer’s response back to the acquiring processor.
The response relates to the original authorisation attempt. Approval or decline information and available response data travel back with it.
For the merchant: Retain the response and reference, including for failed attempts.
The acquirer returns the result to the provider.
The provider receives the issuer response from the acquiring side.
The customer’s browser has not made this decision. A successful HTTP request or a checkout redirect alone cannot establish the payment outcome.
For the merchant: Update the payment using a verified provider result.
The provider checks the returned data.
The provider applies any remaining rules that depend on the response.
For example, CVC or address-check results may become available with authorisation. Depending on the setup, a rule can still lead to a review, rejection or reversal of an authorised payment. This example is allowed to continue.
For the merchant: Look at the provider’s final payment status as well as the issuer approval.
The merchant receives the authorisation.
The server records the authorised payment and the checkout shows the appropriate result.
Use a verified API result or signed webhook to update the order. An authorised payment waiting for capture should not be described as settled or paid out.
For the merchant: Keep the order, payment and customer confirmation consistent.
The merchant requests capture.
The merchant instructs the provider to capture the authorised amount.
Some integrations capture automatically; others send a separate request. This example captures the full authorised amount. Partial capture and changes to the amount have their own rules.
For the merchant: Capture the amount agreed with the customer before the authorisation expires.
The capture result updates the order.
The provider confirms the capture result and the merchant updates the order.
A successful capture is a different state from settlement and payout. The server should handle repeated notifications without creating duplicate fulfilment or duplicate records.
For the merchant: Send the customer the appropriate confirmation and record the payment once.
Clearing exchanges the financial records.
The captured transaction is presented through the acquiring side and scheme for clearing.
Clearing reconciles the transaction details and calculates obligations between participants, including the relevant scheme arrangements and fees. These are financial records; this message is not itself a merchant bank deposit.
For the merchant: Match the cleared amount and references to the captured payment.
Settlement moves value between participants.
The issuing and acquiring sides settle their obligations through the scheme’s arrangements.
Settlement commonly involves net obligations across many transactions. The diagram follows one payment to explain it; it does not imply a separate bank transfer for every purchase.
For the merchant: Expect the settlement record to include adjustments and fees under your agreement.
The provider records the merchant balance.
The payment is reflected in the merchant’s provider balance.
The merchant-facing provider may also be the acquirer. Available balance, reserves, fees and payout timing depend on the arrangement; a provider balance is not the same as money in the merchant’s bank.
For the merchant: Reconcile payments, adjustments and the provider balance.
The payout reaches the merchant’s bank.
The provider pays the available balance to the merchant’s bank account.
A payout can combine many payments, refunds, disputes and fees. Its schedule and bank-arrival time are separate from the time each customer paid.
For the merchant: Reconcile the bank deposit to the payout, then back to the underlying activity.
Capture later
Authorise first, fulfil the order, then capture before the hold expires.
The customer presses Pay.
The customer agrees to the amount and submits the order.
The merchant creates an order reference and a payment attempt. Repeated clicks or a lost connection should not create duplicate charges.
For the merchant: Keep the basket and payment attempt linked. A submitted order is still unpaid.
Payment details go to the provider.
In this example, the provider’s payment fields collect the card details and return a reference.
Tokenisation lets the integration use a reference instead of passing the full card number through the merchant’s application. The provider also receives the amount, currency and relevant checkout data.
For the merchant: Check the amount on the server and handle duplicate requests consistently.
The provider checks for fraud.
This attempt passes the provider’s initial risk screening.
Signals can include the device, transaction history, unusual payment velocity and merchant rules. Some checks happen here; others depend on the issuer response. A low risk result is not a guarantee that a payment is genuine.
For the merchant: Review the signals and the outcome. An approved rule is only one part of the payment decision.
The 3DS request is prepared.
The 3DS server gathers the transaction and device information needed for authentication.
3D Secure is a separate exchange from payment authorisation. It can be requested because of the payment setup, applicable requirements or a risk decision. This example uses 3DS.
For the merchant: Keep the checkout open while authentication is in progress.
The request reaches the issuer’s ACS.
The scheme directory routes the authentication request to the issuer’s Access Control Server.
The issuer evaluates the available information and decides whether to authenticate without a visible challenge or ask the customer to do more. The scheme’s 3DS directory is a different service from its authorisation routing.
For the merchant: Measure authentication separately from authorisation. They can fail at different points.
The authentication result returns.
The issuer’s result returns through the 3DS services to the provider.
The provider can include the relevant authentication data in the authorisation request. Here, the issuer authenticates without a visible challenge: a frictionless 3DS flow.
For the merchant: Continue with authorisation. The order has not been paid yet.
Send an authorisation request.
The provider submits the payment to the acquiring side.
The request includes the amount, currency, merchant and card information, plus authentication data where applicable. Gateway, processing and acquiring services can belong to one business or several.
For the merchant: Use the same order reference, and distinguish this attempt from any earlier attempt.
The acquirer forwards the request.
The acquiring processor sends the authorisation message to the card network.
The acquiring side checks and formats the request for the relevant scheme. Technical acceptance of the message is not an approval of the customer’s payment.
For the merchant: Separate a routing or integration error from a payment decline.
The network routes it to the issuer.
The scheme sends the request to the card’s issuing side.
Routing identifies the issuer and its processor. Network services can provide additional checks or processing; stand-in and outage handling are outside this example.
For the merchant: Record the references needed to trace the request across providers.
The issuer checks the account and the risk.
The issuer assesses card status, funds or credit, limits and its own fraud controls.
The issuer’s decision is separate from the provider’s fraud screening. Supported security and address checks can also produce response data for the acquiring side. Not every issuer supplies the same detail.
For the merchant: A payment can pass provider screening and still be declined by the issuer.
The issuer sends an approval.
The issuer approves this attempt and places an authorisation hold.
The approval response travels back over the payment network. The hold reduces the customer’s available funds or credit; it does not put the money in the merchant’s bank account.
For the merchant: Treat this as authorised. Capture and settlement are still to follow.
The response returns through the network.
The scheme carries the issuer’s response back to the acquiring processor.
The response relates to the original authorisation attempt. Approval or decline information and available response data travel back with it.
For the merchant: Retain the response and reference, including for failed attempts.
The acquirer returns the result to the provider.
The provider receives the issuer response from the acquiring side.
The customer’s browser has not made this decision. A successful HTTP request or a checkout redirect alone cannot establish the payment outcome.
For the merchant: Update the payment using a verified provider result.
The provider checks the returned data.
The provider applies any remaining rules that depend on the response.
For example, CVC or address-check results may become available with authorisation. Depending on the setup, a rule can still lead to a review, rejection or reversal of an authorised payment. This example is allowed to continue.
For the merchant: Look at the provider’s final payment status as well as the issuer approval.
The merchant receives the authorisation.
The server records the authorised payment and the checkout shows the appropriate result.
Use a verified API result or signed webhook to update the order. An authorised payment waiting for capture should not be described as settled or paid out.
For the merchant: Keep the order, payment and customer confirmation consistent.
The merchant waits for fulfilment.
The authorisation is held while the merchant prepares to deliver the goods or service.
Authorisations expire. The allowed window depends on the scheme, transaction and provider; use the actual capture deadline supplied for the payment. An expired hold may require a new authorisation.
For the merchant: Track the fulfilment status and capture deadline together.
The merchant requests capture.
The merchant instructs the provider to capture the authorised amount.
Some integrations capture automatically; others send a separate request. This example captures the full authorised amount. Partial capture and changes to the amount have their own rules.
For the merchant: Capture the amount agreed with the customer before the authorisation expires.
The capture result updates the order.
The provider confirms the capture result and the merchant updates the order.
A successful capture is a different state from settlement and payout. The server should handle repeated notifications without creating duplicate fulfilment or duplicate records.
For the merchant: Send the customer the appropriate confirmation and record the payment once.
Clearing exchanges the financial records.
The captured transaction is presented through the acquiring side and scheme for clearing.
Clearing reconciles the transaction details and calculates obligations between participants, including the relevant scheme arrangements and fees. These are financial records; this message is not itself a merchant bank deposit.
For the merchant: Match the cleared amount and references to the captured payment.
Settlement moves value between participants.
The issuing and acquiring sides settle their obligations through the scheme’s arrangements.
Settlement commonly involves net obligations across many transactions. The diagram follows one payment to explain it; it does not imply a separate bank transfer for every purchase.
For the merchant: Expect the settlement record to include adjustments and fees under your agreement.
The provider records the merchant balance.
The payment is reflected in the merchant’s provider balance.
The merchant-facing provider may also be the acquirer. Available balance, reserves, fees and payout timing depend on the arrangement; a provider balance is not the same as money in the merchant’s bank.
For the merchant: Reconcile payments, adjustments and the provider balance.
The payout reaches the merchant’s bank.
The provider pays the available balance to the merchant’s bank account.
A payout can combine many payments, refunds, disputes and fees. Its schedule and bank-arrival time are separate from the time each customer paid.
For the merchant: Reconcile the bank deposit to the payout, then back to the underlying activity.
Cancel a hold
Cancel an authorised payment before capture and follow the release back to the issuer.
The customer presses Pay.
The customer agrees to the amount and submits the order.
The merchant creates an order reference and a payment attempt. Repeated clicks or a lost connection should not create duplicate charges.
For the merchant: Keep the basket and payment attempt linked. A submitted order is still unpaid.
Payment details go to the provider.
In this example, the provider’s payment fields collect the card details and return a reference.
Tokenisation lets the integration use a reference instead of passing the full card number through the merchant’s application. The provider also receives the amount, currency and relevant checkout data.
For the merchant: Check the amount on the server and handle duplicate requests consistently.
The provider checks for fraud.
This attempt passes the provider’s initial risk screening.
Signals can include the device, transaction history, unusual payment velocity and merchant rules. Some checks happen here; others depend on the issuer response. A low risk result is not a guarantee that a payment is genuine.
For the merchant: Review the signals and the outcome. An approved rule is only one part of the payment decision.
The 3DS request is prepared.
The 3DS server gathers the transaction and device information needed for authentication.
3D Secure is a separate exchange from payment authorisation. It can be requested because of the payment setup, applicable requirements or a risk decision. This example uses 3DS.
For the merchant: Keep the checkout open while authentication is in progress.
The request reaches the issuer’s ACS.
The scheme directory routes the authentication request to the issuer’s Access Control Server.
The issuer evaluates the available information and decides whether to authenticate without a visible challenge or ask the customer to do more. The scheme’s 3DS directory is a different service from its authorisation routing.
For the merchant: Measure authentication separately from authorisation. They can fail at different points.
The authentication result returns.
The issuer’s result returns through the 3DS services to the provider.
The provider can include the relevant authentication data in the authorisation request. Here, the issuer authenticates without a visible challenge: a frictionless 3DS flow.
For the merchant: Continue with authorisation. The order has not been paid yet.
Send an authorisation request.
The provider submits the payment to the acquiring side.
The request includes the amount, currency, merchant and card information, plus authentication data where applicable. Gateway, processing and acquiring services can belong to one business or several.
For the merchant: Use the same order reference, and distinguish this attempt from any earlier attempt.
The acquirer forwards the request.
The acquiring processor sends the authorisation message to the card network.
The acquiring side checks and formats the request for the relevant scheme. Technical acceptance of the message is not an approval of the customer’s payment.
For the merchant: Separate a routing or integration error from a payment decline.
The network routes it to the issuer.
The scheme sends the request to the card’s issuing side.
Routing identifies the issuer and its processor. Network services can provide additional checks or processing; stand-in and outage handling are outside this example.
For the merchant: Record the references needed to trace the request across providers.
The issuer checks the account and the risk.
The issuer assesses card status, funds or credit, limits and its own fraud controls.
The issuer’s decision is separate from the provider’s fraud screening. Supported security and address checks can also produce response data for the acquiring side. Not every issuer supplies the same detail.
For the merchant: A payment can pass provider screening and still be declined by the issuer.
The issuer sends an approval.
The issuer approves this attempt and places an authorisation hold.
The approval response travels back over the payment network. The hold reduces the customer’s available funds or credit; it does not put the money in the merchant’s bank account.
For the merchant: Treat this as authorised. Capture and settlement are still to follow.
The response returns through the network.
The scheme carries the issuer’s response back to the acquiring processor.
The response relates to the original authorisation attempt. Approval or decline information and available response data travel back with it.
For the merchant: Retain the response and reference, including for failed attempts.
The acquirer returns the result to the provider.
The provider receives the issuer response from the acquiring side.
The customer’s browser has not made this decision. A successful HTTP request or a checkout redirect alone cannot establish the payment outcome.
For the merchant: Update the payment using a verified provider result.
The provider checks the returned data.
The provider applies any remaining rules that depend on the response.
For example, CVC or address-check results may become available with authorisation. Depending on the setup, a rule can still lead to a review, rejection or reversal of an authorised payment. This example is allowed to continue.
For the merchant: Look at the provider’s final payment status as well as the issuer approval.
The merchant receives the authorisation.
The server records the authorised payment and the checkout shows the appropriate result.
Use a verified API result or signed webhook to update the order. An authorised payment waiting for capture should not be described as settled or paid out.
For the merchant: Keep the order, payment and customer confirmation consistent.
The merchant cancels before capture.
The order is cancelled while the payment is still authorised.
Cancelling an uncaptured payment is different from refunding a captured one. The provider checks the payment state and submits a reversal where appropriate.
For the merchant: Choose the operation using the payment’s current state.
The reversal reaches the issuer.
The reversal request follows the payment chain to the issuing side.
The message identifies the original authorisation. Release timing and what the cardholder sees depend on the issuer and the payment state.
For the merchant: Retain the cancellation reference if the customer still sees a pending hold.
The issuer releases the hold.
In this example, the issuer releases the authorised amount.
No captured payment is being sent back. Available funds or credit are restored; the customer’s bank display can take time to reflect the change.
For the merchant: Explain that the pending authorisation is being released.
The result returns to the merchant.
The cancellation outcome is reported back through the provider.
Keep the cancelled order and payment record linked. If a payment was already captured, investigate the actual state rather than repeatedly cancelling it.
For the merchant: Close the order without creating a refund for money that was never captured.
Refund
Start with a captured payment and follow a successful refund through to the cardholder.
Start with a captured payment.
The merchant agrees to return a previous £48 payment.
This scenario begins after capture. A refund needs the original payment reference, an eligible amount and enough available balance under the provider’s arrangements.
For the merchant: Record why the refund is being made and link it to the original order.
The provider validates the refund.
The provider checks the payment, refund amount and available balance.
A submitted refund can be pending or fail. A successful request means the refund was created; it does not guarantee that a credit is already visible to the cardholder.
For the merchant: Check the refund status instead of relying only on the customer-facing confirmation.
The refund request reaches the issuing side.
The refund is submitted through the acquiring side and card network.
This example includes refund authorisation, used where supported or required by the card network. The exact processing differs from a purchase authorisation.
For the merchant: Retain both the payment and refund references.
The issuer response returns.
The issuing side accepts the refund in this example.
A refund may instead be declined or fail, for example because of an issue with the destination account. An accepted refund still has to be processed and posted.
For the merchant: Keep handling status updates until the refund has a final outcome.
The merchant receives the refund status.
The provider reports the refund’s current status to the merchant.
Provider status and the cardholder’s statement can update at different times. Tell the customer what has been submitted, using the provider’s guidance on timing.
For the merchant: Avoid promising that the money is already visible in their account.
The credit is cleared.
The participants exchange the records needed to return the captured amount.
The refund is linked to the original payment. Fees, deductions and the effect on the merchant’s balance follow the provider agreement.
For the merchant: Reconcile the refund separately from the original sale.
Value returns towards the issuer.
The refund is funded from the merchant’s provider balance and settled through the payment chain.
Scheme settlement can net refunds against other activity. This diagram isolates one refund for clarity rather than showing a separate transfer for each credit.
For the merchant: Account for the deduction in the provider balance and the relevant settlement records.
The issuer credits the cardholder.
In this completed example, the refund appears in the customer’s account.
The visible credit can arrive after the provider reports that the refund was processed. If it is missing, the refund reference and issuer trace information help with investigation.
For the merchant: Use the actual status and reference when helping a customer locate a refund.
Reconcile and close the request.
The merchant links the refund, order and balance adjustment.
The customer communication, refund status and accounting records should describe the same event. Keep the references for any later query.
For the merchant: Close the request once the outcome is recorded.
These are separate events.
- Authentication
- The issuer establishes confidence in the person using the card. A successful 3DS check does not guarantee payment approval.
- Authorisation
- The issuer approves or declines a payment attempt. An approval typically reserves the amount; the merchant has not received a payout.
- Capture and clearing
- Capture submits the authorised payment for completion. Clearing exchanges financial records and establishes obligations between participants.
- Settlement and payout
- Settlement fulfils obligations between payment participants. A payout sends the merchant’s available provider balance to its bank.
This map covers the main stages of an online card payment. Wallet provisioning, recurring payments, network stand-in, disputes and chargebacks involve other paths. Checks can run in parallel or continue after authorisation.