Payment Security Evolution: From Card Controls to Dispute-Ready Identity Evidence

Payment security has never actually been about eliminating fraud; it's about deciding who absorbs the loss when fraud happens anyway. Every era of payment security technology, from passwords to passkeys, has reduced a specific kind of fraud, shifted liability for it in a specific direction, and left a specific category of dispute still sitting with the merchant.

Here is that history, read the way a merchant needs to read it: what got safer, who became liable, and what evidence each era actually left behind, before we even get to the modern chargeback meaning most merchants operate with today.

The Password and Encryption Era

Online payments started with the rise of eCommerce marketplaces like eBay and Amazon, which created demand for a new kind of intermediary: PayPal or a chargeback process through their credit card companies, since someone had to sit between a buyer's bank account or card and a seller's storefront.

The threat this era addressed was data theft and impersonation: could you verify that the correct user initiated a payment, and could you protect financial information in transit? The answer was encryption. First developed in 1995, Netscape developed Secure Socket Layer (SSL) to encrypt data across the web and authenticate users, providing the basis for Transport Layer Security (TLS) encryption, which we still use today.

What this era did not touch: liability. There was no card-network dispute framework yet resembling today's chargeback process; a PSP or bank simply decided case by case who ate a loss, and the evidence trail was whatever a login log and an email confirmation could provide.

The Early eCommerce and Payment Gateway Era

eCommerce kept growing through the late 1990s and early 2000s, remarkably, given that much of the hype around the internet faded with the dot-com bubble crash. The platforms that survived, Amazon, Shopify, Netflix, Zappos, had to connect inventory, order fulfillment, and payment acceptance into one working system, and fraudsters noticed the new attack surface immediately. Customer accounts and shopping carts were hackable, and card fraud grew alongside internet scams and phishing. One of the most visible incidents was a Denial of Service Attack in February 2000 on Yahoo!, CNN.com, eBay, and Amazon.

This era's threat was infrastructure-level: could the checkout and account systems even stay online and uncompromised. Liability during this period mostly followed card-present rules awkwardly ported onto card-not-present transactions, which meant merchants absorbed most card-not-present fraud by default, since there was no chip or physical signature to check. Evidence available to fight a dispute was thin: server logs and whatever order records the young infrastructure kept, long before a formal ecommerce fraud prevention discipline existed to standardize any of it.

The Authentication and Tokenization Era

Payment security's next answer was authentication at the moment of the transaction, not just encryption around it. The industry built several tools that still form the backbone of card security today:

• 3D Secure: Visa and Mastercard's original 3D Secure protocol asked for a second proof, a password or one-time code, in risky payment situations. The current version, 3D Secure 2 (3DS2), exchanges far more data (device fingerprint, transaction history, behavioral signals) so most legitimate customers authenticate silently, with a challenge only for higher-risk transactions.
• Tokenization: Security teams began substituting random tokens for sensitive card data, so a data breach exposes scrambled tokens instead of usable card numbers, shrinking both the damage of a breach and a merchant's PCI compliance scope.
• AVS and CVV checks: Address Verification and card security codes gave gateways an extra signal to compare against the cardholder's real information at the moment of purchase.
• Multi-Factor Authentication (MFA): Accounts holding sensitive financial data began requiring at least two proofs from three categories: something you know, something you have, and something you are. MFA is still a standard defense today.
• Biometrics: Verifying users by fingerprint, face, or voice added a layer that is far harder to steal or replicate than a password.

This era is where liability shift as merchants know it today actually starts. A successfully completed 3D Secure 2 authentication shifts liability for a fraud dispute from the merchant to the card issuer, but only for fraud: non-fraud disputes like product-not-received or billing errors stay with the merchant regardless of authentication. That distinction is exactly why compelling evidence still matters even on an authenticated transaction, and why understanding chargeback reason codes is what tells a merchant which disputes a completed authentication actually protects against.

The Regulation and Compliance Era

By this point payment security had grown unwieldy across borders: a bank, a card brand, and a payment gateway each had different security practices, and that inconsistency was itself a vulnerability. Governments and standards bodies stepped in with rules such as:

• Payment Card Industry Data Security Standard (PCI DSS): Rules for handling card data, now on version 4.0.1, with every requirement mandatory as of 2025.
• Payment Services Directive (now PSD2, with PSD3 and the Payment Services Regulation in progress across the EU): Consumer protections and strong customer authentication requirements for electronic payments across the European Union.
• Fair and Accurate Credit Transactions Act (FACTA): U.S. rules on the use of financial information and fraud response.
• Gramm-Leach-Bliley Act (GLBA): Rules ensuring the confidentiality of consumer financial data.

These frameworks did not shift chargeback liability directly, but they set the minimum bar every payment service provider has to clear, and they standardized the kind of authentication evidence (SCA logs, PCI-compliant storage) that later became usable in a dispute.

The AI, Behavioral, and Passwordless Era

Today's layer builds directly on the authentication era rather than replacing it. Chargeflow uses AI-powered tools, including predictive analytics, tailored risk models, and rapid dispute resolution, to catch what static rules miss. Blockchain and distributed ledger technology offer decentralized, irreversible transactions with no intermediary to compromise. FIDO2 authenticators: use public key cryptography for passwordless logins, removing the password as an attack surface entirely. And behavioral biometrics, the way someone types, swipes, and navigates, add a verification layer that is nearly impossible for a fraudster to replicate. Pair any of this authentication data with chargeback alerts and a merchant can act on a risky pattern before a formal dispute is even filed.

The next chapter is already forming: as AI agents start initiating purchases on a customer's behalf, merchants face a new authentication question, addressed in Chargeflow's look at AI agent chargeback liability and the broader agentic commerce chargebacks evidence playbook. And regardless of how a transaction gets authenticated, it still counts toward network-level programs like VAMP, so a merchant's chargeback monitoring thresholds stay relevant no matter how advanced the authentication behind a transaction gets.

The table below lines up every era on the same three questions, so the comparison stays apples to apples across decades: what threat it primarily addressed, where liability landed by default, and what evidence it actually left a merchant to work with.

Notice what stays constant down every row: no era eliminated evidence collection as a merchant responsibility, it only changed what that evidence looks like. A percentage from a 2000-era infrastructure report is never placed next to a 2026 authentication statistic in this table; each row answers the same three qualitative questions instead.

Each Era Shifted Liability, None of Them Erased the Merchant's Evidence Burden

The throughline across every era is this: security technology keeps getting better at stopping fraud before it happens and better at deciding, after the fact, whose fault it was. What it has never done is remove the merchant's need to produce evidence when a dispute still lands. A 3D Secure 2 authentication protects against a fraud claim, not a "product never arrived" claim. A PCI DSS 4.0.1 compliant system protects card data, not a merchant's ability to prove delivery. Knowing which era's protection applies to which dispute is what separates a chargeback a merchant should win from one it will lose by default, and it's why prevention tools built on top of these standards still matter: prevent chargebacks before they happen instead of relying on any single era's technology to do it alone.

Frequently Asked Questions

Does 3D Secure 2 protect against all chargebacks?
No. A successful 3DS2 authentication shifts liability to the issuer only for fraud disputes. Non-fraud chargebacks, like product not received or a billing dispute, remain the merchant's responsibility regardless of authentication.

What replaced the original 3D Secure protocol?
3D Secure 2 (3DS2) replaced the original version. It uses far more data points during authentication, so most legitimate transactions pass silently instead of forcing every customer through a password or one-time code challenge.

Is PSD2 still the current EU payment regulation?
PSD2 remains in force, but the EU has finalized a follow-up framework, PSD3 and the accompanying Payment Services Regulation, that updates strong customer authentication and fraud-liability rules; merchants operating in the EU should track its rollout rather than assume PSD2 is the final word.

Does tokenization eliminate chargeback risk?
No. Tokenization protects stored card data from being useful if stolen, which reduces data-breach fraud, but it does not change chargeback liability rules or eliminate the need for transaction evidence.

What evidence should a merchant keep from an authenticated transaction?
The 3DS2 authentication result, device and IP data, delivery or fulfillment confirmation, and any customer communication. Authentication proves the cardholder was likely present; delivery and fulfillment records prove the merchant held up their end of the transaction.

Want to know how Chargeflow can protect you and your customers across every one of these eras? Set up a demo today.