Demystifying card payments

An overview of payments pt.1

Product Knowledge

Written by Janka Bergner
18 September 2020

This is the first in a series of articles explaining card payments, systems and products. Here, we explain who does what, in a typical payments process, the main payments actions and events (and the difference between the two), and Worldpay's approach.

Who's involved?

There are six main players in standard card transactions:

  • Customer - anybody or anything who has a card from an issuing bank (see below) and uses this card account to pay for something, e.g. groceries, clothes or movie tickets.
  • Merchants - any business that lets customers pay by card for its goods or services (e.g. grocery store, movie theater or airline).
  • Merchant banks (or acquiring banks / acquirers) - these banks set up and maintain merchant accounts, which let merchants accept deposits from card payments.
  • Payment processors - companies that process card transactions (e.g. Worldpay). They make card payments possible by connecting merchants, merchant banks and card associations.
  • Issuing banks (or issuers) - banks, credit unions and other financial institutions (e.g. Citi, Halifax or HSBC) that issue cards to customers via card associations.
  • Card Networks (e.g. Visa, Mastercard or American Express) - these networks have various responsibilities including setting guidelines and acting as an honest broker for other players, such as issuing banks and merchant banks.

How are payments processed?

Card payments are processed in three separate phases:

  • Authorization
  • Settlement
  • Funding

Authorization - this process usually takes under a second.

  1. A customer uses their card to buy something from a merchant. This might happen in a store (e.g. a supermarket), through an eCommerce portal (e.g. flights); or through an application, such as a mobile device (e.g. movie tickets or video games).
  2. The merchant asks their payment processor to authorize the payment.
  3. The payment processor submits the transaction to the relevant card network.
  4. Using card-specific details, such as its expiry date and CVC code, the card network asks the issuing bank to authorize the payment.
  5. The issuing bank approves or declines the payment. A payment may be declined for a number of reasons, including insufficient funds or credit, a closed account or an expired card.
  6. The issuing bank sends their yes/no decision back down the same line to the merchant.

Settlement and funding - this process is usually completed in a few hours.

  1. Merchants send authorized transactions to their payment processor in batches.
  2. The payment processor passes the transaction details to the relevant card networks.
  3. The card network passes on the transaction debit details to the relevant issuing banks in their network.
  4. The issuing bank charges the customer's account for the transaction amount.
  5. The issuing bank then moves that money to the merchant bank (after subtracting their interchange fees).
  6. The merchant bank credits the merchant's account with those funds.

Payments actions and events

These are the main actions and events that may occur during a typical card payment - but what's the difference?

  • An action is a deliberate instruction by the merchant involved (e.g. authorize this transaction);
  • An event is a response to an action (e.g. transaction authorized)
Action/ EventDescription
AuthorizeAn action instructing the merchant's payment processor to check if the customer can complete the transaction - i.e. is there an active account with enough funds available? If so, authorization reserves the funds and starts the clock on settling the transaction.
AuthorizedAn event that says yes, there's an active account; yes, it contains enough money; yes, funds are potentially reserved; and yes, the clock is now ticking on settling the transaction.
SaleA single action that reserves available funds and also starts settlement (i.e. both authorize and settle).
RefusedEvent notifying the merchant that the payment request has been declined, either by the issuing bank, by the merchant bank or by a risk tool. A risk tool is a product that automatically prevents fraudulent payments from being processed before they can be authorized - for example, by preventing payments from cards issued in specific countries.
ErrorAn event showing that a request was invalid or could not be processed.
Cancel AuthorizationAn action instructing the cancellation of an authorization and removal of the reservation on funds in the customer's account.
Sent for CancellationAn event notifying a merchant bank that a previous authorization has been cancelled and the payment can no longer be acted upon.
SettleAn action that starts the settlement process and begins the transfer of funds from the customer's account to the merchant's account.
Sent for SettlementAn event confirming that the settlement process has been started with the merchant bank and the issuing bank.
RefundAn action that begins a refund process that allows the return of funds from a merchant's account to a customer's account.
Sent for RefundAn event confirming that the refund action has been started with the merchant bank and issuing bank.
ReverseAn action to begin either a cancellation or a refund when it is unknown whether a Settle action has already been processed.