ExplorePayment Security

Payment Security

by Froga

How a card number is protected in storage, at the terminal, and at checkout -- PCI DSS, tokenization, EMV chips, and 3-D Secure, tied back to the encryption and certificates covered earlier in this path.

You're previewing this room. Log in or create a free account to answer the questions and track your progress.

Study material

Payment security overlaps with general web security but is not the same problem. A TLS connection (covered elsewhere in this path) protects data in transit, between a shopper's browser and a merchant's server. But a card number is valuable long after that connection closes -- it can be charged again, sold, or used somewhere else entirely. That is why payment security also covers how card data is stored, how long it is kept, who is allowed to see it, and what a business has to prove about all of that. The rules that formalize this are the Payment Card Industry Data Security Standard (PCI DSS), which applies to any business that stores, processes, or transmits card data -- not just banks.

A shopper's card number crosses a phone, a Wi-Fi router, a payment gateway, and a bank's systems before a purchase completes. What makes payment security a distinct topic from general web security, rather than something TLS alone solves?

multiple choice

TLS cannot be used on payment pages, so a separate encryption system is required.

The card number itself has value even after the connection closes, so it also has to be protected at rest, limited in where it is stored, and handled under rules that apply to every business that touches it -- not just kept safe in transit.

Card numbers are not sent over the internet at all, so web security does not apply to them.

Payment security only concerns the bank, not the merchant taking the payment.

Think about what happens to the number after the checkout page closes, not just while it is being typed in.

Ready to test yourself?