Module 1: Payment Security Landscape
How Card Payments Flow
Before you can protect card data, you need to know where it goes. A single tap of a card at a supermarket till in Nairobi or a click on "Pay now" on an online store sets off a chain of messages between several organisations in a few seconds. Each hop is a place where data could be intercepted, logged or stored. Understanding the flow is the foundation of everything else in PCI DSS, because scope, risk and responsibility all follow the data.
The parties in a card payment
- Cardholder: the customer whose card is used.
- Issuer: the bank or financial institution that issued the card and holds the cardholder's account. It approves or declines transactions.
- Merchant: the business accepting the payment.
- Acquirer (merchant bank): the bank that contracts with the merchant to accept card payments and receives the funds on the merchant's behalf.
- Payment processor and gateway: companies that connect merchants to acquirers and networks. A gateway securely captures online payment details; a processor handles transaction messages. Sometimes one company does both, and sometimes it is the acquirer itself.
- Card network (payment brand): Visa, Mastercard, American Express, Discover, JCB and others, which run the networks and set the rules that acquirers and merchants must follow.
The three stages: authorisation, clearing, settlement
- Authorisation: the merchant sends the card details and amount through its gateway or processor to the acquirer, which routes the request over the card network to the issuer. The issuer checks the account, available funds and fraud signals, then returns an approval or decline. This takes seconds.
- Clearing: later, usually in a daily batch, the merchant's approved transactions are submitted so that final amounts are confirmed and exchanged between acquirer and issuer through the network.
- Settlement: money moves from the issuer to the acquirer, and the acquirer pays the merchant, minus fees, according to the merchant agreement.
What card data is involved
PCI DSS divides account data into two groups:
| Cardholder data | Sensitive authentication data |
|---|---|
| Primary account number (PAN) | Full track data from the magnetic stripe or chip equivalent |
| Cardholder name | Card verification code (the three or four digits often called CVV2, CVC2 or CID) |
| Expiration date | PINs and PIN blocks |
| Service code |
The PAN is the defining element: if the PAN is present, PCI DSS applies. Sensitive authentication data must never be stored after authorisation, even if it is encrypted.
Worked example: three channels, three flows
Consider a hypothetical Nairobi electronics retailer, "Mwangaza Electronics", that sells in three ways:
- In store: customers tap or insert cards on a terminal supplied by the acquirer. The terminal encrypts the card data and sends it directly to the acquirer over the mobile network. The till system only receives "approved" and an amount.
- Online: the website redirects customers to a payment page hosted by a gateway. Card details are entered on the gateway's page, not the retailer's website. The retailer receives a token and the result.
- By phone: corporate clients call with card details, and a sales agent types them into the gateway's virtual terminal in a web browser on an office PC.
Each channel exposes card data differently. In store, the data passes only through the terminal. Online, it never touches the retailer's servers, though the website controls the redirect. By phone, the data is heard by the agent, typed on an office PC and could end up written on paper or in call recordings. The phone channel, which looks the most informal, may carry the most risk and pull the most systems into scope.
Card-present and card-not-present
Payments where the card is physically present at a terminal are called card-present. Online, phone and mail orders are card-not-present. Chip and contactless technology make card-present fraud harder, so criminals have increasingly targeted card-not-present channels, especially e-commerce sites, where stolen card numbers can be used or skimmed by malicious scripts on checkout pages.
Common mistakes to avoid
- Assuming the provider handles everything. Even with outsourced payments, your systems and people may still touch card data.
- Forgetting manual channels such as phone orders, paper forms and email.
- Confusing the acquirer with the card network. Your contract and compliance reporting are usually with your acquirer.
- Thinking encryption allows storage of sensitive authentication data. It does not.
Exercise
Choose a business you know, or your own, and list every way it accepts card payments. For each channel, write the sequence of systems and people the card data passes through from the customer to the acquirer, and mark any point where the data is seen, typed, written down or stored.
Key points
- A card payment involves the cardholder, merchant, gateway or processor, acquirer, card network and issuer.
- Payments go through authorisation, clearing and settlement.
- PCI DSS applies wherever the PAN is present; sensitive authentication data must never be stored after authorisation.
- Each sales channel exposes card data differently, and manual channels are often the riskiest.