What Happens During an Online Card Payment?
When a customer pays with a card on a South African website or app, a lot happens in the few seconds between clicking "Pay" and seeing the confirmation screen. The card details are captured securely, the cardholder is authenticated with 3D Secure, the issuing bank approves or declines the payment, and the merchant is notified of the result.
This page walks through each stage of the flow so you can understand where things can go wrong, why some payments take a detour through the customer's banking app, and when the money actually reaches the merchant.
Step 1: The Customer Enters Card Details
At checkout the customer enters the card number (PAN), expiry date and CVV, or selects a saved card or digital wallet. How the details are captured depends on the integration:
- Hosted checkout – the customer is sent to a payment page hosted by the payment provider.
- Embedded fields – secure input fields from the provider are embedded in the merchant's own page.
- API integration – the merchant's certified systems pass the details to the provider directly.
In all cases the goal is that raw card numbers never touch the merchant's servers, which keeps the merchant's PCI DSS burden low. See Hosted, Embedded and API Checkouts.
Step 2: The Card Details Are Tokenised
The gateway encrypts the card details and typically replaces them with a token, a reference that is useless to anyone who steals it. If the customer chose to save the card, the token is what gets stored for future payments. See Card Tokenisation and Network Tokens.
Step 3: The Cardholder Is Authenticated with 3D Secure
On South African e-commerce transactions the cardholder is normally challenged with 3D Secure before the payment is authorised. Depending on the issuing bank, the customer approves the payment in their banking app or enters a one-time PIN (OTP) sent by SMS. Banks such as Absa, FNB, Nedbank, Standard Bank, Capitec, TymeBank and Discovery Bank each run their own challenge experience.
If authentication fails or the customer abandons the challenge, the payment stops here and no money moves. See What Is 3D Secure?.
Step 4: The Payment Is Authorised
The authorisation request travels from the gateway through the acquirer and the card network (Visa or Mastercard) to the issuing bank. The issuer checks:
- The card is valid, active and not reported lost or stolen
- Funds or credit are available
- The transaction passes the issuer's fraud screening
The issuer returns an approval or a decline with a response code, and the answer flows back to the checkout within seconds. Approved funds are reserved on the cardholder's account but not yet paid to the merchant. Declines are covered in Why Do Card Payments Get Declined?.
Step 5: The Merchant Is Notified
The checkout shows the customer the result, and the merchant's systems are updated, usually via a webhook or callback, so the order can be released. Because customers can close browsers mid-payment, webhooks rather than the browser redirect should be treated as the source of truth. See Webhooks and Callbacks.
Step 6: Capture, Clearing and Settlement
Authorised transactions are captured (finalised for billing), submitted into clearing where the schemes exchange transaction records between the banks, and then settled. The acquirer pays the merchant the settled amount less agreed fees, typically within a few business days depending on the provider and settlement schedule.
The gap between authorisation and capture is also what makes pre-authorisation holds possible. See Authorisation, Capture and Pre-Authorisation.
Related Topics
Card-Present vs CNP
Learn the difference between card-present and card-not-present transactions and how it affects fraud risk, chargeback liability and processing fees.
Chip, Contactless and SoftPOS
Understand EMV chip-and-PIN, contactless tap-to-pay and SoftPOS technology that turns a smartphone into a card machine, and how each keeps cards secure.