Credit cards still leak enough data to be guessed

A credit card does not need to be stolen in full to become usable. A criminal who sees a masked card number, the expiry date, the issuing bank, and a few payment responses may already have enough to start reconstructing the missing data. The attack is not cinematic. It is arithmetic, automation, and weak feedback loops. The uncomfortable point is that a card can be technically protected under PCI DSS and still be exposed to brute force guessing when merchants and payment flows reveal too many clues.

A fraud pattern built from small leaks

The recent account described by Metin Ozyildirim on May 1, 2026, is a useful case because it does not claim a giant database breach or a broken cryptographic primitive. It describes a smaller, messier, more ordinary problem. A saved card appeared in a merchant account with the first six digits, last four digits, cardholder name, and expiry date visible. The attacker allegedly breached that merchant account, saw the masked payment instrument, attempted a transaction, learned extra data from the payment journey, and then used other merchant validation endpoints to guess the remaining card number digits and CVV before spending the card at a merchant that did not force 3D Secure. Ozyildirim says the process took about six hours and ended in unauthorized charges that were routed through an e-wallet-like cash-out path before the bank later refunded the money.

That story is not proof that every card is exposed in the same way. It is a first-person report, not a regulator’s forensic finding. Yet the mechanism matches a known weakness in card-not-present payments: distributed guessing, also called enumeration or account testing. Newcastle University researchers warned in 2016 that inconsistent merchant validation practices could let attackers distribute guesses across many websites and infer which combinations of PAN, expiry date, and CVV were valid. Their work found that the issuing bank and payment network did not always see the pattern clearly when failed attempts were spread across merchants, while each merchant saw only a small slice of the attack.

The payment industry has not ignored this risk. Visa has published anti-enumeration guidance. EMVCo has developed EMV 3-D Secure to strengthen card-not-present authentication. PCI DSS 4.0.1 is now the active version of the main card data security standard supported by the PCI Security Standards Council. Still, the problem persists because the attack sits between formal control areas. PCI DSS restricts storage and display of sensitive card data, but it does not by itself guarantee that every merchant validation endpoint, issuer response code, retry policy, exemption decision, wallet top-up, and cash-out path will behave as one coordinated defense.

The weakness is not that PCI DSS is useless. PCI DSS reduces harm from many breaches. It restricts full card data exposure, bans storage of CVV after authorization, and requires controls around cardholder data environments. The weakness is that minimum compliant display rules can still leave a small enough search space for an automated attacker when the rest of the ecosystem provides confirmation signals. A masked card number may look safe to a consumer because most digits are hidden. To an attacker, those visible digits are a starting coordinate.

A sixteen-digit card number is not a random sixteen-digit password. It has structure. The first digits identify the issuer range. The final digit follows the Luhn check. If a merchant shows the issuer identification number and the last four digits, the unknown middle section is far smaller than it appears. Add an expiry date, issuer name, and payment gateway responses that distinguish “wrong card number” from “wrong CVV,” and the card becomes a puzzle with hints.

The brute force label can mislead. People imagine trying millions or billions of possibilities against one bank until a rate limiter reacts. A modern payment enumeration attack is subtler. The attacker spreads guesses across merchants, proxies, accounts, currencies, checkout forms, subscription validators, and low-value authorization attempts. Each endpoint may see two requests per second or less. Each merchant may think its own rate looks normal. The issuer may see scattered failed attempts, not always enough to tie them together quickly. The fraudster is not breaking the vault door. They are asking dozens of clerks slightly different questions until one of them confirms the missing fact.

PCI DSS protects stored data, not every inference

PCI DSS is often treated in public debate as a yes-or-no badge. Either the merchant is compliant, or it is negligent. That framing misses the engineering reality. PCI DSS is a baseline for protecting payment account data. The PCI Security Standards Council describes PCI DSS as technical and operational requirements intended to protect payment account data and support consistent security measures globally. PCI SSC also said PCI DSS v4.0.1 became the only active supported version after PCI DSS v4.0 was retired on December 31, 2024, with future-dated new requirements retaining the March 31, 2025 effective date.

The standard draws an important distinction between cardholder data and sensitive authentication data. Cardholder data includes the primary account number, cardholder name, expiry date, and service code. Sensitive authentication data includes full track data, card verification codes, and PIN-related data. PCI SSC’s public FAQ states that PCI DSS prohibits storage of card verification codes after authorization, including for future transactions.

That rule matters. A merchant that stores CVV after authorization creates obvious fraud risk. Banning that storage prevents a single compromised merchant database from giving attackers all values needed for many card-not-present transactions. But the rule does not prevent a different type of attack in which the CVV is never stored anywhere by the merchant. It is guessed later through authorization attempts.

The display rule is also narrower than many consumers assume. PCI DSS 4.0.1 requires PAN to be masked when displayed, with the bank identification number and last four digits as the maximum digits shown for users without a documented business need to see more. The purpose is sound: reduce direct exposure of full card numbers on screens, reports, and receipts.

Yet “maximum allowed to display” is not the same as “safe to disclose in every context.” A receipt, an account page, a support screen, an order history page, and a payment retry screen have different threat models. A consumer account that has been taken over is not a trusted internal finance screen. A merchant dashboard with saved card metadata is not just a display surface; it may be the first stage of a guessing chain. Compliance asks whether the full PAN is protected. Enumeration defense asks whether the visible fragments and system responses allow the missing data to be inferred.

This is where formal compliance and practical fraud control diverge. A merchant can hide the CVV, never store it, mask the PAN within the permitted range, and still leak enough information for a criminal to make the next attack cheaper. The masked card is not the breach. The breach is the combination of masked data, expiry visibility, issuer hints, differential response codes, weak rate controls, inconsistent 3D Secure enforcement, and cash-out-friendly merchants.

A fair reading of PCI DSS does not blame the standard for every fraud chain. PCI DSS was not written to be the sole fraud engine for all card-not-present behavior. Its core purpose is account data protection. Payment authorization, issuer risk scoring, merchant fraud screening, 3D Secure policy, chargeback rules, and scheme monitoring all sit around it. The problem is that many businesses and consumers treat PCI compliance as a stronger promise than it is.

The case described by Ozyildirim points at that gap. The merchant allegedly responded that showing the visible digits and expiry date was intentional and aligned with PCI DSS 3 and 4. If accurate, that response is technically understandable and strategically insufficient. The attack does not require the merchant to violate the masking rule. It exploits the fact that the masking rule is not a complete anti-enumeration model.

The arithmetic behind a masked card

A sixteen-digit payment card number contains less mystery than its length suggests. The first six or eight digits identify the issuer range under the ISO/IEC 7812 numbering system. The last digit is a check digit. The visible last four digits are often shown to help customers distinguish between saved cards. That leaves a smaller unknown region in the middle.

In the case described by Ozyildirim, the saved card display showed the first six and last four digits. For a sixteen-digit card, that leaves six unknown digits before accounting for the Luhn check digit. Because the final digit is already known and must fit the Luhn checksum, many candidate numbers are invalid without even touching the payment network. Ozyildirim estimated about 99,999 possible PAN candidates after visible digits and checksum filtering.

That number is not trivial for a human. It is small for software. The attacker does not need to try one hundred thousand full purchase attempts at one merchant in one burst. They can test candidate values through validation endpoints, account-linking flows, donation pages, trial subscriptions, stored-card checks, low-value authorizations, and payment gateways that return different failure messages. If those systems distinguish invalid card number from wrong expiry or wrong CVV, each response narrows the puzzle.

The expiry date matters because it collapses another dimension. Many saved card displays show expiry month and year because customers need to know which card is current. PCI DSS treats expiry date as cardholder data, not sensitive authentication data. That is reasonable for storage and display policy. In an enumeration attack, the expiry date is a powerful shortcut. If the attacker already has it, they no longer need to test dozens of month-year combinations.

CVV then becomes the last small secret. A three-digit CVV has 1,000 possibilities. A four-digit American Express card identification number has 10,000 possibilities. Rate limits should make guessing impractical. But rate limits fail when they are local to one merchant, one user account, one IP address, or one checkout form. The attacker’s advantage is that the payment ecosystem gives them many doors, while each defender often watches only one doorway.

The same logic applies to the card number stage. If a validation endpoint tells the attacker the card number is valid but CVV is wrong, the endpoint has acted as an oracle. The word “oracle” in security describes a system that answers a question the attacker should not be able to answer directly. The payment form is supposed to authorize a transaction, not provide a step-by-step card reconstruction service. But response messages, status codes, decline reason mappings, and retry behavior can create that service by accident.

The arithmetic also explains why masking more aggressively changes the economics. Showing only the last four digits leaves far more unknown PAN space than showing issuer digits plus last four. Using network tokens or merchant-specific tokens for saved card displays removes the reusable PAN from the merchant-facing account view. Hiding expiry dates unless needed reduces the attacker’s certainty. None of these controls is magic. They raise the cost and reduce the confidence of the guessing chain.

Merchant validation APIs as guessing machines

The most dangerous checkout endpoint is not always the one that takes money. A “validate card,” “add payment method,” “start subscription,” “verify account,” or “authorize one dollar” flow may be more useful to a criminal because it is built to answer whether credentials look valid. These flows are common because merchants need to reduce payment failures, confirm card ownership, store payment methods for later use, or prevent fake accounts from consuming services. The business reason is real. The security side effect is also real.

Visa’s 2023 merchant guidance defines enumeration as fraudulent card-not-present activity in which criminals systematically submit values such as PAN, CVV2, expiry date, or postal code to obtain valid payment information. The same guidance distinguishes account testing, where criminals use small transactions to confirm that an account is active.

A validation API becomes unsafe when it returns too much information. A generic decline tells a user that the card cannot be used. A specific decline may tell an attacker which field was wrong. If one response maps to invalid PAN, another to expired card, another to CVV mismatch, and another to insufficient funds, a guessing script can progress quickly. The attacker does not need to know the processor’s internal code names. They only need a stable difference in behavior.

Developers often expose those differences for legitimate support reasons. Customer service teams want to know why a payment failed. Product managers want fewer checkout abandonments. Payment operations teams want clear logs. A shopper entering their own card incorrectly appreciates being told that the expiry date is wrong. Yet the same helpfulness becomes dangerous at scale. Every detailed decline code is a trade-off between user clarity and attacker feedback.

The payment stack often multiplies the problem. Merchant code calls a payment service provider. The PSP maps network and issuer responses into its own API schema. The merchant maps those into frontend messages. Fraud tools add risk flags. Logging systems capture full objects. Customer support dashboards display simplified labels. A tiny difference in any layer can reveal whether the PAN, expiry, CVV, postal code, or address matched. Attackers learn by observing those differences across many merchants.

Some merchants believe they are safe because their own endpoint rate-limits repeated failures. That helps against crude scripts. It does not defeat distributed enumeration if the control keys are too narrow. A rate limit tied to IP address fails against proxy rotation. A limit tied to merchant account fails when criminals create many accounts. A limit tied to card number fails when the attacker is testing many candidate card numbers. A limit tied to device fingerprint fails when automation frameworks simulate many devices. Strong defense needs cross-signal detection and coordination.

The Ozyildirim case alleges that attackers used multiple endpoints taken from unrelated e-commerce registration flows, running around six requests per second in total and about two requests per second per API. That is low enough to blend into normal traffic at many merchants, especially when IP addresses change and the tested card values vary.

This is why enumeration is an ecosystem risk rather than a single-merchant bug. A merchant with a clean validation endpoint can still suffer fraud if other merchants let attackers validate the card. An issuer with good controls may still face noise if acquirers pass through weak merchant attempts. A consumer may lose funds even though the merchant where their card was first exposed did not process the final fraudulent transaction. The clues and the cash-out point are often different businesses.

Differential responses are the hidden vulnerability

Security teams spend years teaching applications not to reveal whether a username exists. Login forms that say “wrong password” for valid accounts and “no such user” for invalid accounts are vulnerable to account enumeration. The credit card version is the same pattern with higher stakes. A payment form that says “invalid card number” for one guess and “incorrect security code” for another has confirmed that the card number and expiry are valid.

This is not only about text shown to a shopper. Attackers read HTTP status codes, API fields, error IDs, response timing, redirect behavior, fraud challenge triggers, and even which third-party script loads next. A frontend may display “payment failed,” while the network response contains a structured reason code. A mobile app may hide the reason, while the backend JSON includes it. A merchant may suppress errors in production, while the “add card” endpoint leaks details in a registration flow. Attackers test all of it.

The safest design for untrusted channels is blunt. The customer-facing response should avoid confirming which payment field was correct. Internal teams can still see detailed codes behind authentication and access controls. Fraud systems can use the detail. The public API should not. A payment endpoint should not let an unauthenticated or newly registered user learn that a specific PAN and expiry pair is valid while only the CVV is wrong.

This creates a usability tension. Real customers make mistakes. A customer who mistypes the expiry date wants clear correction. But payment data is not a normal form field. The cost of clarity is borne by cardholders across the network, not only by the merchant optimizing conversion. Good design can still reduce friction without leaking validation states: ask the customer to re-enter all fields, use secure hosted fields, trigger issuer authentication, or provide a generic decline with a support path for persistent failures.

The issue becomes sharper when merchants use “zero-dollar” or small-value authorizations. These are meant to verify a card without a normal purchase. They can be useful for account setup, subscriptions, and delayed billing. In weak configurations, they become free guessing probes. If the issuer or gateway returns granular results and the merchant passes them back, the attacker gets confirmation without buying goods.

Some gateways and processors offer tools to reduce this risk, including velocity checks, account updater controls, risk scores, device fingerprinting, bot detection, and rules around repeated authorization failures. The presence of those tools does not mean merchants configure them well. Payment products are often integrated under pressure, copied from examples, or left with defaults that favor conversion.

The right question for a merchant is not, “Do we display the full PAN?” It is, “Could our payment journey answer an attacker’s next guessing question?” That question covers registration, saved cards, receipts, customer support, webhooks, mobile APIs, logs, retries, validation calls, and checkout decline handling.

The old Newcastle warning still fits the new case

The 2016 Newcastle University research remains central because it described the systemic nature of the attack before the latest anecdotal case. The researchers studied online payment sites and found differences in required fields and validation responses. They argued that those differences allowed attackers to distribute guesses across sites and build up full card details. Newcastle’s public release said the “distributed guessing attack” could circumvent payment security features, and that neither the network nor banks were always able to detect multiple invalid attempts when spread across many websites.

The academic paper’s metadata lists Mohammed Aamir Ali, Budi Arief, Martin Emms, and Aad van Moorsel as authors, published in IEEE Security & Privacy in 2017. The article summary says the study examined online credit and debit card payment practices and the security challenges created by differences in how payment sites operate.

The key insight has aged well. Payment security often fails at the seams, not at the cryptographic center. EMV chip cards made counterfeit card-present fraud harder, but card-not-present commerce still depends on static values: PAN, expiry date, CVV, billing address, device context, risk history, and authentication policy. If those values are accepted inconsistently, the system leaks.

The Newcastle researchers also found that 3D Secure changed the visibility pattern because the issuing bank sees authentication attempts directed at a card, even when they are initiated across merchants. That matters because distributed attacks are hard to see when every merchant has only local telemetry. 3D Secure routes more risk context to the issuer and creates an authentication layer before authorization.

Yet the Ozyildirim case shows the limit of relying on 3D Secure as a universal answer. Some merchants still do not apply it to every transaction. Some transactions qualify for exemptions. Some merchants accept liability for frictionless or non-authenticated flows. Some recurring or merchant-initiated transactions behave differently. Some issuers and acquirers tune risk thresholds to avoid false declines. A criminal only needs one usable path that does not demand the cardholder’s one-time passcode or app approval.

The payment industry has changed since 2016. EMV 3-D Secure has replaced older 3DS patterns in many markets. PSD2 strong customer authentication changed European e-commerce. Issuers use better machine learning. Networks publish enumeration guidance. PSPs sell fraud stacks. But the structural flaw remains whenever attackers can combine information from one merchant with validation at others. The old warning was not that one brand had one bug. It was that inconsistent merchant behavior turns the whole card-not-present ecosystem into a distributed oracle.

Card-not-present fraud is the natural home of enumeration

Card-present payments benefit from physical controls. The chip, terminal, cryptographic transaction data, PIN or signature rules, and local possession of the card all add layers. Card-not-present payments replace possession with static credentials and risk scoring. That shift is convenient for e-commerce, subscriptions, travel, delivery, software, marketplaces, gaming, streaming, and digital wallets. It also creates the right environment for automated guessing.

EMVCo says EMV 3-D Secure is designed to help issuers and merchants prevent card-not-present fraud and improve e-commerce authentication. Visa Secure is Visa’s EMV 3-D Secure program for reducing friction and helping prevent card-not-present fraud. Mastercard describes Identity Check as an authentication service tied to secure online transaction flows, with CVC2 and address validation services used to mitigate card-not-present fraud.

Those services exist because CNP risk is structurally different. The merchant cannot see the card. The issuer may not know whether the person typing the details is the cardholder. The acquirer wants approvals. The merchant wants conversion. The consumer wants speed. The fraudster wants any merchant with weak controls.

Recent fraud data keeps the stakes visible. The European Central Bank said in December 2025 that total payment fraud in the European Economic Area rose to €4.2 billion in 2024 from €3.5 billion in 2023, while the overall payment fraud rate stayed around 0.002% of transaction value. The same ECB release said strong customer authentication remained effective against the fraud types it was designed to mitigate, especially for card payments.

That pair of facts is important. Fraud can be small as a percentage and large in absolute money. Strong authentication can work against many attacks and still leave gaps where authentication is not triggered, where credentials are tested before payment, where social engineering captures one-time codes, or where merchants route transactions through lower-friction paths. The industry’s challenge is not that all controls fail. The challenge is that criminals concentrate on the exceptions.

UK Finance’s 2025 half-year fraud data, as summarized by Take Five, reported that card-not-present cases increased by 22% in the first half of 2025, even as some other unauthorized fraud categories declined. The same update said criminals continued to trick victims into handing over one-time passcodes and registering digital wallets.

Enumeration sits inside that wider CNP pressure. It does not require phishing the cardholder for every missing field. It lets criminals turn partial data into complete data. It works best when credentials are static and validation feedback is rich. It becomes more profitable when the final spend point offers liquid goods, wallet top-ups, gift cards, crypto-like assets, travel credits, marketplace balances, or cash withdrawal options.

3D Secure helps, but exemptions create openings

3D Secure is often described as the extra password, SMS code, app approval, or biometric step used during online card payments. The newer EMV 3-D Secure model is broader. It supports risk-based authentication, richer data exchange, app and browser flows, frictionless approvals, and issuer decisioning. EMVCo says EMV 3DS helps issuers and merchants identify unauthorized e-commerce transactions quickly and accurately to prevent CNP fraud.

The security benefit is straightforward. When 3DS is invoked properly, the issuer sees the authentication request and can challenge the cardholder or approve based on risk. A distributed guessing attack becomes harder because the issuer gains a central view of attempts against the same card. The attack also becomes less useful if a successful PAN-expiry-CVV combination still cannot authorize without the cardholder’s authentication.

But 3DS is not universal, and it was never meant to be a simple always-on wall. Merchants and issuers balance fraud reduction against checkout friction. Regulation allows exemptions in some cases. Recurring payments and merchant-initiated transactions have special treatment. Low-risk transactions may be approved without a visible challenge. Some jurisdictions do not impose PSD2-style strong customer authentication. Some merchants accept higher liability in exchange for lower friction. Some acquirers or PSPs offer routing choices that affect authentication.

The Ozyildirim account alleges that the attackers first triggered unsuccessful 3D Secure SMS attempts at some merchants, then found another merchant that did not require 3D Secure and drained the remaining virtual card limit through multiple payments connected to a cash-out path.

That pattern matters because it separates credential validation from final monetization. Attackers do not need every merchant to be weak. They need enough merchants to guess the data and one merchant to spend it. A strong merchant may see failed attempts and block them. A weaker merchant later absorbs the fraud or pushes it into chargebacks. The consumer experiences the whole chain as one theft.

3DS also does not solve every validation leak before authentication. If a merchant’s “add card” flow leaks whether the PAN and expiry are valid before invoking authentication, the endpoint still helps enumeration. If 3DS is triggered only after a card passes preliminary validation, the preliminary responses may still be useful. A safe design treats authentication, validation, and error messaging as one fraud surface.

EMVCo’s 2022 update to EMV 3DS 2.3.1 introduced new data and features aimed at stronger card-not-present fraud prevention. That direction is right: richer issuer data, better device context, delegated and decoupled flows, and smarter challenge decisions. But standards improve security only when implementations resist attacker feedback.

The bank, merchant, acquirer, issuer, network and PSP all see different crimes

A card-not-present transaction involves several parties. The cardholder holds the card. The merchant sells the product or service. The acquirer enables the merchant to accept card payments. The payment service provider or gateway may handle technical processing. The card network routes messages and sets scheme rules. The issuer provides the card and authorizes or declines. Fraud tools sit around these parties. Each sees part of the event.

Enumeration exploits that fragmentation. The first merchant may only know that a customer account was accessed and a saved card was visible in masked form. The second merchant may only see failed validation attempts. The issuer may see declines across several merchants. The final merchant may see approved payments and later a chargeback. The network may see patterns at scale, but not every endpoint’s frontend behavior. The consumer sees alerts and missing funds.

This division makes responsibility hard. The merchant that exposed masked data may say it followed PCI DSS. The validation merchant may say it did not approve a fraudulent charge. The final merchant may say the issuer approved the payment. The issuer may say the merchant did not use 3DS. The acquirer may say it provided tools the merchant did not configure. The network may say it issued guidance. Everyone may be partly right, and the consumer still loses time, confidence, and access to funds.

The legal and commercial rules behind chargebacks assign losses after the fact. They do not fully prevent the attack. Liability shift can push costs toward the party that skipped authentication. Fraud monitoring programs can penalize merchants or acquirers with high fraud rates. But enumeration often begins below the loss threshold, through failed attempts that may not generate chargebacks. A merchant that acts as a validation oracle may not be the merchant that gets punished.

Visa’s enumeration guidance is explicit that controls must detect and block enumeration and account testing. Visa’s merchant best practices describe the criminal submission of enumerated PAN, CVV2, expiry, and postal code values. That is the right target. The harder task is making sure every party treats failed and declined attempts as fraud signals, not just noise.

A mature defense requires shared telemetry. Issuers need to know when many merchants are testing near-identical card ranges. Acquirers need to see merchant-level spikes in declines, even if each card sees few attempts. PSPs need rules for validation endpoint abuse. Networks need to correlate across acquirers. Merchants need to suppress public response detail. Consumers need controls to disable cards fast and set granular limits. No single party has enough visibility to solve distributed guessing alone.

The attack chain from account takeover to cash-out

The Ozyildirim case begins with an ordinary account takeover. That detail matters because it shows how card brute forcing may piggyback on common credential hygiene failures. A reused or old password, a breached email, or a weak merchant login can expose saved payment metadata without exposing the full card. The attacker does not need the merchant database. They only need to see what a logged-in customer sees.

Once inside, the attacker sees the masked PAN and expiry date. If the merchant’s checkout page or 3D Secure redirect reveals the bank name, that adds more confidence. The attacker may attempt a purchase, cancel at the authentication step, and leave. To the victim, the account breach may look contained after a password reset. To the attacker, the valuable phase has started.

The next step is candidate generation. The visible issuer digits and last four digits define the range. The expiry date is already known. Luhn filtering removes invalid card numbers. The attacker then uses merchant validation endpoints to identify the full PAN. Once the correct PAN is found, the CVV search begins. Each phase depends on response codes that reveal progress.

The final step is monetization. A stolen card is less useful if every merchant demands 3DS. Criminals look for merchants with low-friction payments, weak fraud screening, or goods that convert to cash quickly. E-wallet top-ups, marketplace balances, vouchers, game credits, digital gift cards, travel services, and merchants with in-store cash withdrawal features become attractive. In the reported case, the final path involved payments to an e-wallet-like account at a market that allowed cash withdrawal.

This structure explains why virtual cards and limits help but do not eliminate harm. A virtual card with a low limit reduces the maximum loss. It may also isolate the card from other accounts. But if the virtual card details are derived, the attacker can still spend up to the available limit unless the card is frozen, authentication blocks the transaction, or merchant controls intervene.

The six-hour timeline in the case is also plausible in operational terms. A criminal does not need high request speed when the search space is small and multiple endpoints provide feedback. Low-and-slow requests lower detection risk. The attacker can run candidate tests, wait for transient blocks, rotate proxies, and switch APIs. The final cash-out can occur minutes after the missing values are confirmed.

For consumers, the lesson is harsh: a suspicious 3DS attempt after a merchant account breach should be treated as possible card compromise, not only as a failed login. Freezing or replacing the card may be safer than reducing the limit and watching. For banks, the signal is also clear: failed 3DS attempts and suspicious merchant-account activity should feed into card risk immediately.

The Luhn check is not security

The Luhn algorithm is often mentioned in card-number discussions because it filters obvious typos. It is not a security mechanism. It is a check digit system. A valid Luhn result means the number has the right arithmetic shape, not that it belongs to an active card or a particular person.

For attackers, Luhn is useful because it removes bad guesses before they hit a payment endpoint. If a sixteen-digit card number has known issuer digits and known last four digits, software can generate only candidates whose check digit works. That reduces traffic and makes enumeration quieter.

The industry knows this. No serious payment security model treats Luhn as protection. The issue is that consumers see a masked card and infer that many hidden digits create strong secrecy. Luhn reduces the hidden uncertainty. Issuer ranges reduce it further. Expiry visibility removes another field. Response codes do the rest.

The newer eight-digit BIN structure can also affect masking calculations. PCI DSS 4.0.1 uses the term BIN and last four digits in Requirement 3.4.1, and the industry has moved from six-digit to eight-digit issuer identification numbers in many contexts. Showing an eight-digit BIN plus last four digits on a sixteen-digit card leaves fewer unknown digits than showing six plus four. PCI DSS includes business-need language, but the anti-enumeration question remains: does the display reveal more than the customer needs?

A merchant may need to show brand, last four, and expiry status for account management. It rarely needs to show issuer digits to a consumer. Card brand, issuing bank name, last four, and a tokenized card label are enough for most account views. Receipts may follow stricter local and scheme rules, but digital saved-card views can often be more conservative than the maximum PCI display allowance.

The right framing is simple: masking is not secrecy if the remaining search space is small enough to test. A masked card should be designed as if attackers will combine it with issuer ranges, checksums, breached account data, and external validation APIs. That does not mean every account page must hide every card clue. It means the display should expose the least reusable data needed for the user task.

Expiry dates deserve stricter treatment in saved-card views

Expiry dates are operationally useful. They tell customers when to update a card, help merchants avoid failed renewals, and support customer service. They are also a major shortcut for enumeration. If an attacker already has the expiry date, they avoid testing month-year combinations. In the Ozyildirim case, the expiry date was visible with the masked PAN, reducing the brute force problem.

PCI DSS does not classify expiry date as sensitive authentication data. That makes sense because expiry dates are printed on cards, used in many customer contexts, and stored for legitimate payment operations. But saved-card displays are not forced to show the full expiry date by default. A merchant can warn customers that a card is expiring soon without revealing the exact month and year to every logged-in session. It can show “expires soon,” “expired,” or “valid” and require step-up authentication to reveal more.

This is a small design change with a clear security benefit. A criminal who takes over a merchant account would see less. A legitimate customer could still manage payment methods. Customer support could still access details under role controls. The merchant would still retain the expiry internally for billing. The difference is that the account page would no longer hand attackers one of the required card-not-present fields.

The same logic applies to receipts and order histories. Physical receipt rules vary by jurisdiction and scheme, and some receipts show enough digits to identify the card used. Digital receipts and account order pages can be stricter. Consumers rarely need the first six or eight digits. They usually need brand, last four, transaction date, merchant name, and amount.

A conservative display model would show card brand and last four by default, hide expiry except when necessary, avoid issuer identification digits in consumer views, and never place masked PAN plus full expiry together on pages reachable after only password login. If a user needs full card management, the merchant can require multi-factor authentication or redirect to a secure payment method management session handled by a PSP.

The point is not that expiry date secrecy alone defeats fraud. It does not. The point is that enumeration depends on stacking small leaks. Removing one field forces attackers to spend more attempts, touch more endpoints, and create more signals. Good security often works by making the attack noisier.

The cash-out merchant is the fraud multiplier

A guessed card does not become money until it is spent somewhere useful to the attacker. That final merchant matters. A criminal who can only buy a physical item shipped to a traceable address faces more friction. A criminal who can top up a wallet, purchase liquid vouchers, move funds to another stored-value account, or withdraw cash faces less friction. The final merchant turns stolen credentials into proceeds.

This is where payment risk and anti-money-laundering risk overlap. A merchant that allows credit card-funded balances to be withdrawn in cash or transferred onward is not just selling goods. It is operating a value conversion point. If 3DS is not enforced and velocity controls are weak, it becomes an attractive endpoint for stolen-card monetization.

The Ozyildirim account says the final fraud used a merchant without 3D Secure to withdraw the available card limit into an e-wallet of a market that allowed cash withdrawal. The blog also says that since the incident, the cash-conversion party no longer allows that flow without 3DS.

That change, if accurately described, is exactly the kind of targeted control needed. High-risk merchant categories should not treat card payments as ordinary checkout when funds become cash-like. Card-funded stored value needs stricter authentication, delayed withdrawal, name matching, device checks, account age rules, transaction monitoring, and limits. A new account receiving multiple card-funded top-ups should not immediately cash out.

Payment networks and acquirers already classify merchant risk in many ways. Fraud monitoring programs track dispute and fraud ratios. But the enumeration chain shows that risk should also consider cash-out utility. A merchant with low fraud volume but high liquidity may be dangerous if compromised card credentials can be converted quickly.

For consumers, cash-out merchants explain why fraud can happen immediately after card details are guessed. The attacker does not need to shop slowly. They search for routes that liquidate value before the cardholder or issuer reacts. Fast alerts and instant card freeze controls are the consumer-side answer. Merchant-side answers are stronger authentication and slower withdrawal of card-funded value.

PCI compliance can become a ceiling instead of a floor

The phrase “PCI compliant” often ends the conversation inside companies. Legal teams like it. Product teams rely on it. Customer support scripts invoke it. Executives hear it as assurance. The problem begins when compliance becomes the highest ambition rather than the minimum.

PCI DSS itself is more careful. PCI SSC describes the standard as a baseline of technical and operational requirements for protecting payment account data. A baseline is not a full fraud model.

A merchant that says “we are allowed to show the BIN and last four” is using a maximum allowance as a design default. Better design asks what is needed for this user, on this page, after this authentication level, for this purpose. The answer is often less than the maximum allowed. In a logged-in account page, last four and brand may be enough. In a support dashboard, role-based access and masking may differ. In a receipt, legal and scheme rules apply. In a public API, less is safer.

Compliance also tends to assess scoped environments, documented controls, evidence samples, and requirement mappings. Attackers do not care about scoping boundaries. They use forgotten endpoints, mobile APIs, test merchants, old checkout flows, support tools, and partner integrations. A payment ecosystem with dozens of compliant participants can still behave unsafely when their differences are chained.

This is not a reason to dismiss PCI DSS. Without PCI DSS, stored card data exposure would be worse. The standard has driven encryption, access control, vulnerability management, logging, segmentation, and secure development practices across millions of businesses. The point is narrower and more practical: PCI DSS compliance should not be used as proof that masked card displays and validation responses are safe against enumeration.

The right governance question for payment leaders is, “Where do our controls exceed PCI because our threat model demands it?” For merchants with saved cards, subscriptions, wallet balances, digital goods, or high account takeover exposure, the answer should include anti-enumeration controls.

A compact view of the leak chain

Data fragments that reduce the guessing problem

The table shows why the attack is cumulative. No single fragment always compromises a card. The risk appears when visible card metadata, validation feedback, and weak monetization controls line up in the same criminal workflow.

Rate limits need to follow the card, not only the IP address

Rate limiting is the first control many engineers mention when brute force attacks come up. It is useful, but only when keyed to the right objects. An IP-based limit catches noisy scripts from one source. A user-account limit catches repeated failures under one login. A merchant-level velocity rule catches sudden local spikes. Enumeration often avoids all three.

A stronger model watches combinations: PAN candidate patterns, BIN ranges, last-four clusters, device fingerprints, account age, cardholder identity mismatch, repeated CVV failures, expiry sweeps, billing postal code testing, merchant category, gateway response patterns, and acquirer-level decline ratios. The issuer should monitor attempts against the same card or nearby candidate ranges. The PSP should monitor merchants generating suspicious decline patterns. The acquirer should monitor merchant portfolios. The network should correlate across acquirers.

Visa’s anti-enumeration guidance focuses on adequate controls to detect and block enumeration attacks and account testing schemes. It defines the attack in terms of systematic submission of payment values, not merely high traffic from one source. That framing matters because low-and-slow enumeration may never look like a volumetric attack.

A practical merchant control set includes public error suppression, bot mitigation, device fingerprinting, velocity limits by card fingerprint and BIN range, blocking repeated declines, account-age rules, CAPTCHA or step-up checks after suspicious patterns, and automatic reporting to PSP or acquirer fraud teams. But merchants cannot rely only on local rules. They must configure the PSP’s risk tools and make sure validation attempts are included in fraud monitoring, not treated as harmless failures.

Issuers face a different challenge. They may see many declined attempts, but the attempts can involve generated PAN candidates, not the final real card until late in the process. The issuer’s model needs to detect suspicious sweeps across issuer ranges, not only repeated failures on one exact PAN. That requires careful tuning because legitimate failed payments happen constantly. False positives lock out real customers and hurt approval rates. Weak models let attackers continue.

Networks are in the best position to see cross-merchant patterns, but network rules are slower than attacker adaptation. The right direction is shared intelligence with near-real-time scoring. Visa describes products that identify enumeration and account testing in real time using historical and near-real-time transaction data. The exact product choice matters less than the principle: distributed attacks need distributed telemetry.

Generic decline messages are not enough by themselves

A common recommendation is to return generic payment errors. That is necessary but not sufficient. Attackers can infer success from other behavior. A generic message paired with different latency, different retry limits, different webhook events, different 3DS redirects, or different authorization hold behavior may still leak information.

For example, a merchant may display “payment failed” in all cases, but a wrong CVV triggers a different processor response time than an invalid PAN. Or a valid PAN with wrong CVV may create a temporary authorization record visible in another endpoint. Or a wrong expiry may stop before 3DS while a correct expiry triggers issuer authentication. Or a payment page may load different JavaScript after a preauthorization check passes. Attackers test these side channels.

A safer design normalizes the entire public behavior as much as possible. The same message, similar response timing, same retry guidance, same frontend path, and no public structured reason codes. Internally, the merchant and PSP can keep detailed information for support and fraud review. Externally, the endpoint should deny the attacker a clean learning signal.

This is familiar in authentication security. Login systems hide whether the email or password was wrong, equalize timing, and throttle attempts. Payment systems need the same discipline. The difference is that a payment failure involves more parties and more reasons. Fraud teams must work with product, support, engineering, PSP integration, and customer experience teams so the public behavior does not become an oracle.

Some product teams resist generic declines because they fear conversion loss. The better answer is risk-adaptive messaging. A trusted customer updating a card after strong account authentication may receive more helpful guidance. A new account, anonymous checkout, high-risk device, proxy traffic, repeated failed attempts, or unusual card range should receive less detail and more friction. The system should not give the same diagnostic power to a bot that it gives to a verified cardholder.

Saved cards are convenience features with security debt

Saved cards are central to modern commerce. They reduce friction, support subscriptions, speed repeat purchases, and increase conversion. They also create a stored map of where a card is used. Every merchant account with a saved card becomes a place where account takeover can expose partial payment data.

Tokenization reduces this risk when implemented correctly. A merchant should store a token from a PSP or network token service, not raw PAN. A network token can replace the PAN in some transactions and be limited by merchant, device, or domain. Merchant-specific tokens limit replay value. But tokenization does not automatically make the account page safe if the merchant still displays enough card metadata to aid enumeration.

A saved-card management page should be designed as a security-sensitive surface. It should require strong account authentication. It should avoid showing issuer digits. It should consider hiding full expiry. It should log views and changes. It should alert the customer when a payment method is used from a new device or after account recovery. It should let customers remove cards quickly. It should avoid storing stale cards that have not been used in years.

Account takeover controls belong in the payment discussion. A merchant may have perfect PCI storage practices and weak login security. If an attacker can access saved-card metadata through an old password, the payment system has a problem. Passkeys, multi-factor authentication, breached-password checks, device risk, session management, and suspicious login alerts all reduce the chance that card fragments leak in the first place.

Consumers also have a role, but it should not be overstated. People cannot audit merchant validation APIs. They cannot see acquirer routing choices. They cannot know which merchants are exempt from 3DS. They can use unique passwords, passkeys, virtual cards, spending limits, transaction alerts, and card freezes. Those steps reduce harm. The systemic controls still belong to merchants, issuers, acquirers, networks, and regulators.

Virtual cards reduce blast radius, not the underlying flaw

Virtual cards are useful because they create separation. A consumer can use one virtual card for one merchant, set a low limit, freeze it quickly, or replace it without changing the physical card. Businesses use virtual cards for travel, procurement, subscriptions, and vendor-specific spending. These controls reduce exposure when card data leaks or is guessed.

The Ozyildirim case involved a virtual credit card with limits and 3D Secure enabled. The attacker still allegedly derived usable details and spent the reduced available limit at a merchant without 3DS.

That does not make virtual cards worthless. It shows what they are. A virtual card is a containment control. It limits loss, isolates merchants, and speeds recovery. It does not prevent enumeration if the virtual PAN, expiry, and CVV can be guessed and accepted by a weak merchant. It also does not force every merchant to authenticate.

Issuer apps could strengthen virtual cards by adding merchant locking, default freeze after suspicious 3DS failures, per-merchant card numbers, dynamic CVV, temporary CVV refresh, low default online limits, and instant push approvals for first-time merchants. Some issuers already provide versions of these ideas. Adoption and interoperability vary.

Dynamic CVV is especially relevant. A static three-digit CVV is easy to search once the PAN and expiry are known. A CVV that changes in the issuer app or card display raises the attack cost. But dynamic CVV has usability and deployment limits. Merchants, issuers, and networks still need to support the transaction flow. It cannot be the only answer.

A more immediate improvement is merchant-specific tokenization. If a saved card at Merchant A is represented by a token that cannot be used at Merchant B, account takeover at Merchant A gives the attacker far less useful information. The public account view can show only last four of the tokenized credential or card art metadata rather than reusable issuer digits and expiry.

Issuer response codes need anti-enumeration design

Issuers and processors need detailed decline reasons. They must distinguish stolen card, expired card, wrong CVV, insufficient funds, suspected fraud, invalid account, do-not-honor, restricted card, and technical errors. Those reasons support fraud models, customer service, authorization decisions, and compliance reporting. The problem is not that detailed codes exist. The problem is when they are exposed to untrusted parties in ways that support guessing.

The issuer may send a code to the network. The network or gateway maps it. The acquirer receives it. The PSP surfaces it. The merchant displays it or logs it. Each step can choose how much detail travels further. Public channels need stricter mapping than internal settlement and risk channels.

A good response-code policy has layers. Issuers and networks retain detail for risk and operations. PSP dashboards expose detail to authorized merchant roles with monitoring. Merchant APIs receive categories needed for handling. Consumer-facing pages get generic outcomes unless the session is trusted and the risk is low. High-risk attempts get less information and more friction.

The same principle should apply to webhooks and developer logs. A merchant’s frontend should not receive raw processor decline fields if it does not need them. Mobile apps should not expose validation codes in API responses. Client-side scripts should not handle sensitive decision logic. Attackers reverse engineer apps and inspect network traffic.

This is not only a merchant education issue. PSPs and gateways should make safe response mapping the default. Developer examples should not teach merchants to display granular decline reasons. SDKs should separate public and private error fields. Dashboards should flag merchants whose integration leaks validation detail. Acquirers should treat granular public responses as an enumeration risk.

The consumer’s burden is too high

Consumer advice usually follows fraud stories: use strong passwords, enable alerts, check statements, use virtual cards, freeze cards quickly, and dispute unauthorized charges. That advice is useful. It is also evidence that too much responsibility has shifted to the least informed party.

A cardholder cannot know whether a merchant displays issuer digits unnecessarily. They cannot inspect hidden API response codes. They cannot tell whether an online market skips 3DS for certain transactions. They cannot see whether a PSP rate-limits by PAN candidate, BIN range, or IP address. They cannot distinguish a harmless failed 3DS attempt from the start of an enumeration chain.

The consumer can react only after signals arrive. In the Ozyildirim account, the first signal was an SMS for a purchase attempt from a known merchant account. The cardholder changed the password and reduced the virtual card limit. Later, more 3DS attempts arrived, followed by successful non-3DS transactions elsewhere.

A stronger consumer protection model would treat suspicious authentication attempts as card-risk events. Issuer apps could offer one-tap freeze from the 3DS alert. Banks could automatically step up all future transactions after failed 3DS attempts at unfamiliar merchants. Cardholders could set “3DS required for all online transactions” where scheme and merchant flows allow it. Virtual cards could default to merchant locking. Saved-card views could trigger alerts when accessed after a new login.

Regulation also matters. In Europe, strong customer authentication has reduced some card fraud, but exemptions and out-of-scope transactions remain. The ECB said in 2025 that SCA remains effective against the fraud types it was designed to mitigate, especially for card payments. That wording is precise. SCA works where it applies and where the attack matches its design. Enumeration and weak validation require additional controls before and around authentication.

Merchants need a stricter saved-card display policy

The simplest merchant change is to show less. Saved-card views should not automatically display the maximum PAN digits allowed by PCI DSS. They should display the minimum needed by the customer. For most consumer interfaces, brand plus last four is enough. If expiry status is needed, show “valid,” “expires soon,” or “expired” rather than full month and year. If full expiry must be shown, require step-up authentication.

This may sound small, but it changes the attack economics. Without issuer digits, the attacker cannot narrow the PAN range as easily. Without expiry, they must test more combinations. Without granular validation responses, they cannot cheaply confirm progress. Without weak cash-out merchants, they cannot monetize quickly.

Merchants should also review receipts, order pages, subscription pages, invoices, support dashboards, mobile APIs, and account exports. The risk is not only the visible frontend. Data can leak through CSV downloads, email templates, PDF invoices, customer support transcripts, analytics tools, and logs.

A strong policy should include:

• Consumer views show brand and last four by default, not issuer digits plus expiry.
• Full expiry display requires a clear user need and stronger session trust.
• Payment validation errors shown to users are generic under risky conditions.
• Detailed decline codes remain server-side and role-restricted.
• Saved-card metadata views are logged and tied to account takeover detection.
• Old unused payment methods are removed or require re-authentication before reuse.

This is not a radical security program. It is basic minimization. Payment data that is not shown cannot be copied during account takeover. A field that is not public cannot become an oracle clue.

PSPs should treat validation as a high-risk product feature

Payment service providers sit at a powerful point in the chain. They provide hosted fields, tokenization, vaults, checkout SDKs, validation endpoints, risk scoring, decline code mapping, and merchant dashboards. They influence thousands of merchants through defaults. A single unsafe default can scale across the ecosystem. A safe default can close many weak integrations at once.

PSPs should make anti-enumeration controls default for card validation endpoints. That includes generic public error responses, velocity limits across merchant portfolios, device and IP risk scoring, detection of PAN and CVV sweeps, suppression of detailed validation states in client APIs, and alerts for merchants with abnormal decline ratios. Validation endpoints should not be treated as low-risk because they do not always create settled transactions.

Developer documentation matters. Many payment weaknesses are copied from examples. If the example code says if cvv_failed then show "wrong CVV", merchants will ship it. If the SDK returns a safe public message and keeps the detailed reason server-side, safer behavior spreads. PSPs should publish explicit enumeration threat models in integration guides.

PSPs also need to monitor merchants that become guessing infrastructure. A merchant with many failed authorization attempts, high invalid PAN ratios, repeated CVV mismatches, short-lived accounts, proxy traffic, or suspicious low-value verification attempts should be reviewed. The merchant may be under attack, misconfigured, or abused as a validation oracle. In any case, the PSP has visibility the individual issuer may not.

Acquirers should ask PSPs for evidence: what anti-enumeration controls exist, how public errors are mapped, whether card validation attempts feed fraud systems, how decline velocity is measured, and how suspicious merchants are suspended or forced into stronger controls. Compliance questionnaires should include these questions, even where PCI DSS does not explicitly demand them.

Issuers need card-range intelligence, not only card-level blocking

Issuers traditionally focus on the card account. Did this card have unusual activity? Did the cardholder authenticate? Is the merchant risky? Is the amount unusual? Enumeration often starts before the real card is known. Attackers test generated candidates across an issuer range. Many attempts may hit nonexistent or invalid PANs. Waiting for repeated failures on one real card may miss the earlier pattern.

Issuers need models that detect sweeps across BIN ranges and account-number spaces. A sudden pattern of invalid PAN attempts, near misses, expiry tests, or CVV mismatches from many merchants should trigger range-level defenses. Those defenses might include temporary stricter CVV handling, 3DS step-up, blocking high-risk validation merchants, or notifying networks and acquirers.

The challenge is precision. Issuers cannot block large card ranges every time a merchant has a bad integration. False positives harm real cardholders and merchants. The right response may be graduated: tighter scoring, lower thresholds for challenge, watchlist rules, and collaboration with networks rather than blunt declines.

Issuer apps also matter. Consumers should have fast controls: freeze card, replace virtual card, require online approval, lower limits, block card-not-present transactions, block international online transactions, and view recent failed attempts. Many banks show approved transactions but not declined validation attempts. Showing suspicious failed attempts with plain-language warnings would help consumers react earlier.

A suspicious failed 3DS prompt should trigger issuer-side risk changes. If a cardholder cancels or denies an authentication attempt from an unfamiliar merchant, the card should enter a higher-risk state. Future non-3DS transactions should face stricter review. A cardholder who denies “I did not make this purchase” should not have to separately infer that their card metadata may be under attack.

Networks have the clearest ecosystem role

Card networks are among the few parties with enough scale to define common anti-enumeration expectations. They set scheme rules, publish guidance, run monitoring programs, and see transaction patterns across issuers and acquirers. Their role is not to inspect every merchant frontend, but they can require safer outcomes.

Visa has already published guidance and merchant best practices on enumeration and account testing. That is a foundation. The next question is enforcement and measurement. Are acquirers required to monitor validation abuse? Are merchants penalized for excessive declined authorization probes? Are granular public response mappings treated as a rule violation? Are cash-like merchants required to use 3DS or equivalent step-up for card-funded withdrawals? Are PSPs accountable for unsafe defaults?

Network rules should also reflect the eight-digit BIN era and modern saved-card displays. If maximum display allowances leave too small a search space in some contexts, scheme guidance should push merchants toward stricter consumer-facing masking. PCI DSS sets a baseline. Networks can issue stronger operational guidance for anti-enumeration.

The monitoring side needs to include failed attempts. Fraud programs often focus on confirmed fraud and disputes. Enumeration happens in failed authorizations before the final successful fraud. A merchant that generates massive invalid attempts but few settled fraud losses can still harm the ecosystem by helping attackers validate cards later. Networks should measure that behavior.

Cross-network coordination matters because criminals route around controls. If one network tightens validation and another lags, attackers shift. If one acquirer enforces and another tolerates weak merchants, attackers shift. Enumeration is not brand loyalty. It follows the weakest combination of data, feedback, and cash-out.

Regulators should look beyond reimbursement

Payment regulation often focuses on who reimburses the victim after fraud. Reimbursement is necessary, but it is not enough. A refunded cardholder still loses time, faces stress, may lose access to funds temporarily, and must replace payment credentials. A merchant may absorb chargebacks. Banks may raise costs. The system should prevent the attack path, not only assign the bill.

European payment regulation has pushed strong customer authentication, and the ECB’s fraud reporting suggests SCA is effective for the fraud types it was designed to address. The next regulatory focus should include validation abuse, merchant feedback leakage, and cash-out controls.

Regulators can ask concrete questions. Do PSPs report suspicious validation attempts? Do acquirers monitor merchants with abnormal decline ratios? Do wallet-like merchants allow credit card-funded balances to be withdrawn without strong authentication? Do issuers provide consumers with controls to require step-up on online transactions? Do merchants minimize saved-card metadata after account takeover risk?

This does not require regulators to prescribe every API response. It requires supervisory expectations that payment firms treat enumeration as operational fraud risk. Banks and payment firms already manage phishing, mule accounts, APP scams, remote purchase fraud, and digital wallet provisioning. Enumeration belongs in the same risk map.

The EU’s evolving payment legislation and fraud discussions increasingly point toward shared responsibility, transaction monitoring, data sharing, and stronger fraud controls. Reuters reported in November 2025 that EU institutions reached agreement on rules aimed at strengthening online fraud protection, including obligations around suspicious transaction freezes and greater platform accountability, though formal adoption remained required at that time.

Enumeration fits that policy direction because it is a shared-system problem. It cannot be solved by telling consumers not to reuse passwords, and it cannot be solved by telling one merchant to be PCI compliant. It needs common expectations across the payment chain.

The economics favor attackers when validation is cheap

A brute force attack succeeds when the cost of guesses is lower than the expected payout. Payment systems unintentionally lower the cost when validation attempts are free, fast, informative, and distributed. Attackers do not need a high success rate if automation and weak endpoints make attempts cheap.

The attacker’s costs include infrastructure, proxies, breached accounts, scripts, merchant endpoint discovery, failed attempts, blocked cards, and cash-out risk. The payout depends on card limits, merchant acceptance, liquidity of goods, and speed before detection. A card with a low limit may not be worth a long attack. A card with a visible expiry, known issuer range, and multiple validation oracles becomes more attractive.

Defenders need to raise costs at each step. Less visible data raises search cost. Generic responses reduce information gain. Rate limits increase time. Shared telemetry increases detection risk. 3DS increases authentication cost. Cash-out delays reduce payout certainty. Cardholder alerts reduce time window. Merchant penalties reduce weak endpoints. None of these controls must be perfect alone. Together, they change the economics.

This is a better mental model than searching for one silver bullet. Fraud systems work by making attacks unprofitable, slow, noisy, and unreliable. Enumeration thrives when every participant makes a small local optimization for convenience and none sees the whole cost.

A second compact view of responsibility

Controls by party in the payment chain

The table shows why finger-pointing fails. The attack moves across organizational boundaries, so the defense must also cross them.

Better authentication must not become better tracking without safeguards

Richer fraud controls require more data: device signals, IP reputation, behavioral patterns, account age, merchant history, transaction context, and issuer risk scores. EMV 3-D Secure uses richer data exchange to support risk-based authentication. EMVCo’s 3DS materials describe data-sharing benefits for identifying unauthorized e-commerce transactions and improving authentication decisions.

That direction strengthens fraud defense, but it raises privacy and governance questions. Payment firms should not use anti-fraud data as a blank check for unrelated profiling. Consumers should know when authentication data is collected and how it is protected. Regulators should watch retention, access, and secondary use.

The balance is workable. Fraud models can use device and transaction signals under strict purpose limits. Data can be minimized, pseudonymized, and access-controlled. Stronger authentication does not need to expose full card data to merchants. Network tokens and issuer-side decisioning can reduce merchant data exposure while improving risk decisions.

The privacy point matters because trust is not only about avoiding unauthorized charges. Consumers also expect payment systems not to leak their purchase behavior, device identity, or account patterns unnecessarily. A secure CNP model should reduce reusable secrets and shift more decisioning to controlled payment infrastructure, not scatter more data across merchants.

Merchant exemptions need sharper risk rules

3DS exemptions and frictionless flows exist for a reason. Forcing every transaction through a challenge would hurt conversion, accessibility, and customer experience. Low-value, low-risk, recurring, trusted-beneficiary, and merchant-initiated scenarios need flexible handling. But exemptions become dangerous when they are available to cash-like, newly created, high-velocity, or account-takeover-adjacent flows.

A merchant selling low-risk physical goods to a long-standing customer may deserve frictionless handling. A merchant allowing card-funded balance withdrawal should face a higher bar. A newly registered account attempting multiple top-ups from a freshly added card should face step-up. A transaction following failed 3DS attempts elsewhere should face step-up. Risk rules need to account for what the merchant enables after payment.

The Ozyildirim case draws attention to merchants that can convert card payments into cash withdrawal. Those merchants should be treated as high-risk final spend points, even if their chargeback history appears manageable. Their controls should include strong authentication, withdrawal delay, velocity limits, identity checks, device binding, and monitoring for card testing patterns.

Acquirers and networks can enforce this through merchant category rules, risk reviews, and liability incentives. Issuers can also choose to challenge or decline transactions in high-risk categories when authentication is absent. The point is not to ban convenience. The point is to stop treating cash-like conversion as ordinary retail.

The role of AI in both attack and defense

Automation is already central to enumeration. Attackers need scripts to generate candidates, rotate proxies, parse responses, and manage endpoint lists. Generative AI may lower some barriers by helping criminals write scripts, understand API behavior, create fake accounts, and adapt to errors. The core attack, though, does not require advanced AI. It needs structured data and feedback.

Defenders use machine learning for authorization scoring, anomaly detection, bot detection, device intelligence, and network-level pattern recognition. Visa says its issuer protection tools identify enumeration and account testing using AI and deep learning across historical and near-real-time transaction data.

AI is helpful when the signal is distributed and noisy. A human analyst may not spot low-rate validation attempts across dozens of merchants and thousands of candidate card values. A model can detect unusual combinations: issuer range sweeps, repeated CVV mismatches, merchant decline spikes, proxy fingerprints, and cash-out timing. But models need good data and clear intervention rules. A model that scores risk without forcing step-up or blocking bad endpoints will not stop much.

The danger is overconfidence. Fraud teams should not assume AI compensates for leaky public responses. It is cheaper and safer to stop giving attackers detailed clues than to detect every clue’s misuse later. AI should sit on top of sound protocol and API design, not replace it.

The receipt problem is not dead

Physical receipts still matter because they can reveal card fragments. PCI DSS and other rules restrict how much PAN appears, but receipts may show first digits and last digits depending on context. Consumers often throw them away. Attackers can combine receipt data with other sources, especially when expiry dates or merchant account data are available elsewhere.

Ozyildirim explicitly argues that the same issue is not limited to e-commerce account breaches. A receipt showing first six and last four digits gives generous information if combined with other clues.

The practical risk varies. A receipt alone usually lacks expiry and CVV. But criminals do not rely on one source. They aggregate. A restaurant receipt, a breached loyalty account, a saved-card page, a phishing page, and validation endpoints can become one chain. Security design should assume fragments travel.

Merchants should truncate receipts more aggressively where allowed. Digital receipts should show less than physical receipts when no stronger need exists. Customer support should avoid asking customers to email receipts with visible card fragments. Consumers should not panic over every receipt, but shredding or tearing receipts with card data remains sensible.

Card brands and issuer differences should not be hidden from analysis

The Newcastle coverage focused heavily on Visa because the researchers’ experiments found differences between Visa and Mastercard handling at that time. Some headlines oversimplified the issue as “Visa can be hacked in six seconds,” which obscured the merchant and ecosystem factors. The core weakness was not that one brand’s card number was mathematically weaker. It was that authorization attempts and validation rules differed across merchants and networks.

Brand differences still matter because network rules, issuer products, tokenization programs, fraud scoring, and authentication policies differ. A cardholder cannot easily choose based on anti-enumeration posture because those controls are opaque. Merchants and issuers can choose providers and configurations, but consumers see only the card brand and bank.

Public analysis should avoid two errors. The first is blaming consumers for using a particular card brand without giving them actionable information. The second is treating all networks as identical. Payment systems have different monitoring programs, authentication products, issuer tools, and scheme rules. Better public reporting would disclose anti-enumeration controls at a higher level without giving attackers operational details.

The industry should also standardize minimum merchant behavior so attackers cannot exploit differences. If one merchant validates CVV first, another validates expiry first, and another reveals PAN validity, the system becomes an oracle. Consistent safe failure behavior is more important than brand reputation.

Chargebacks fix the ledger, not the security model

In many unauthorized card cases, consumers are reimbursed after investigation. That matters. It limits direct financial loss and preserves trust. But reimbursement is not the same as prevention. The cardholder may lose access to funds temporarily, spend hours contacting the bank and merchants, replace cards, update subscriptions, and worry about identity exposure. Merchants and issuers absorb operational costs. Fraudsters may keep proceeds if cash-out succeeds before reversal.

Chargebacks also arrive after the attack. They do not stop validation endpoints from helping the next attacker. A merchant that receives a chargeback may tighten controls. The merchants that leaked clues earlier may never hear about it. A PSP may see failed attempts but not connect them to the later chargeback at another merchant. The learning loop is weak.

A better post-fraud process would trace the chain. Which merchant account exposed the masked data? Which validation endpoints were used? Which PSPs returned granular responses? Which merchant accepted the final non-3DS transaction? Which acquirer monitored the merchant? Which issuer alerts fired? Privacy and legal limits make this hard, but without chain analysis the ecosystem repeats the same weakness.

Networks could support anonymized incident reporting for enumeration, similar to threat intelligence sharing. Merchants that are abused as validators should receive clear notices and required remediation steps. Issuers should be able to report suspected enumeration patterns to acquirers and networks quickly. Consumers should not have to become investigators.

The security value of merchant-specific tokens

Tokenization deserves special attention because it changes the attacker’s prize. If a merchant stores a reusable PAN, even masked, the card metadata has cross-merchant relevance. If the merchant stores and displays a merchant-specific token with only non-sensitive presentation data, account takeover gives the attacker little that can be used elsewhere.

Network tokenization replaces the PAN with a token for digital transactions and can bind it to a merchant or device domain. PSP vault tokens can also prevent merchants from storing raw PAN. The details vary, but the principle is to reduce the spread of reusable card numbers.

Tokenization does not remove all risk. The merchant may still process charges through the token. An account takeover at that merchant may allow purchases at that merchant. A token vault breach may expose mappings if controls fail. Display metadata may still leak. But tokenization limits cross-merchant brute force utility.

Saved-card pages should be designed around tokens, not PAN fragments. The customer can see “Visa ending 7890” or a bank nickname without seeing issuer digits or full expiry. When a payment method is updated, the PSP handles sensitive collection through hosted fields. The merchant never receives raw CVV and does not need to expose validation detail.

Tokenization is especially powerful for subscriptions. A merchant can bill the token without storing the PAN. Account takeover can be met with step-up authentication for shipping address changes, new device purchases, or unusual orders. The attacker cannot easily extract data for spending elsewhere.

Dynamic CVV and app approval address the static-secret problem

The CVV was designed as a card-not-present check against some forms of copied PAN data. It is printed on the card and not supposed to be stored after authorization. That helps against database breaches. It does not help enough when attackers can guess three digits through validation feedback.

Dynamic CVV changes the model by making the code time-varying or app-generated. If the CVV changes periodically, a guessed code may expire. If the code is generated in the issuer app after user authentication, stealing static card metadata is less useful. Some card products and issuer apps have explored or deployed such models, though adoption is not universal.

App-based transaction approval is another route. Rather than relying on static CVV, the issuer asks the cardholder to approve a transaction in a trusted app. 3DS challenge flows already support this in many markets. The problem is coverage. If merchants can skip authentication or route transactions through exemptions, static credentials remain enough in some cases.

A consumer-level setting that requires app approval for first-time online merchants would reduce enumeration monetization. It may create friction, but many users would accept it for higher-risk cards. Business card programs could require approvals based on category, amount, merchant, or country. Virtual cards could default to approval-required until locked to a merchant.

These controls shift security from knowledge of static numbers to possession of an authenticated device. They are not immune to social engineering, SIM swap, malware, or push fatigue. But they reduce the value of brute-forced CVV.

Account takeover and card enumeration are converging

Fraud teams often separate account takeover from card fraud. The first belongs to identity and login security; the second belongs to payment risk. The Ozyildirim case shows how closely they interact. A merchant account takeover exposed card fragments. Card fragments enabled enumeration. Enumeration enabled card-not-present fraud. The final loss occurred at a different merchant.

This convergence means merchants with saved cards must treat account security as payment security. A weak password policy is not just an account problem. It is a payment data exposure problem. Login alerts are not just user experience. They are fraud signals. Viewing saved payment methods should be monitored like changing a payout bank account.

Strong account controls include passkeys, multi-factor authentication, breached credential detection, device recognition, session invalidation after password change, suspicious login alerts, rate limits, bot protection, and step-up authentication for payment method actions. Merchants should also consider hiding saved-card details until the user passes a fresh authentication challenge.

Account recovery is another weak point. If an attacker resets a password and immediately sees saved payment metadata, the recovery process becomes a card-data exposure route. Cooling-off periods, step-up checks, email confirmations, and card detail suppression after recovery reduce that risk.

The same applies to loyalty and marketplace accounts. A loyalty account may not look like a bank account, but if it stores payment methods, gift card balances, points convertible to value, or order history, it is a financial target.

Testing for enumeration should be part of payment security reviews

Merchants and PSPs should test for enumeration the same way they test for injection, cross-site scripting, broken authentication, and exposed secrets. The test is practical: can an attacker learn which payment field is correct by varying one field at a time and observing responses?

A proper test covers:

• Checkout payment failure messages.
• Add-card and save-card flows.
• Subscription signup.
• Free trial and authorization-only flows.
• Donation and low-value payment pages.
• Mobile app APIs.
• Webhooks and frontend network responses.
• 3DS redirect behavior.
• Customer support and admin dashboards.
• Logs exposed to analytics or support tools.
• Rate limits across IPs, accounts, devices, cards, and BIN ranges.

The result should be a map of public signals. If a tester can distinguish invalid PAN from wrong CVV, the merchant has work to do. If rate limits reset per account or IP but not per card range, the merchant has work to do. If a validation endpoint can be used without a real purchase intent, the merchant has work to do. If 3DS is skipped for cash-like flows, the merchant has work to do.

This testing belongs before launch and after payment integration changes. PSP upgrades, new checkout pages, mobile app rewrites, and subscription platform migrations can reintroduce leaks. Fraud controls decay when product teams change flows without threat modeling.

PCI DSS assessments may include application security and vulnerability management requirements, but enumeration-specific testing should be explicit. A system can pass many standard checks and still reveal too much through business logic.

Search engines and AI answer systems need careful wording on this topic

Public articles about card brute forcing often drift into unsafe specificity. Explaining the risk is valuable. Providing operational attack steps, endpoint discovery tactics, scripts, or evasion methods is not. Responsible coverage should describe mechanisms at a level useful for defense without turning the article into a playbook.

The right public message is clear: masked card data can reduce but not eliminate risk; granular payment responses are dangerous; distributed validation across merchants defeats local rate limits; 3DS reduces risk where applied; cash-like merchants need stricter controls; consumers should freeze cards after suspicious authentication attempts.

Search and AI systems should also avoid oversimplified claims such as “PCI DSS is broken” or “all cards can be hacked in seconds.” The truth is more precise. PCI DSS protects stored and displayed card data within its scope, but card-not-present fraud controls fail when compliant data fragments are combined with validation oracles and weak authentication coverage.

That precision matters for trust. Merchants need to know what to fix. Consumers need to know what to do without panic. Regulators need to know where responsibility sits. Issuers and PSPs need to recognize the signal patterns. Good analysis should raise the security bar, not merely dramatize the risk.

Practical steps for consumers after a suspicious 3DS prompt

A suspicious 3D Secure SMS, push notification, or app approval request is not just a failed transaction. It may mean someone has enough card data to attempt payment. The safest response is immediate action.

Deny the transaction. Freeze or lock the card in the issuer app. Contact the bank through the app or number on the card. Replace the card if the issuer recommends it. Change the password on the merchant account that triggered the first alert. Remove saved cards from breached or old accounts. Review recent declined and approved transactions. Lower virtual card limits only as a temporary measure; freezing or replacing is safer when details may be known.

Use unique passwords or passkeys for merchant accounts that store payment methods. Enable multi-factor authentication where available. Prefer virtual cards for subscriptions and merchants you do not fully trust. Set transaction alerts for online purchases. Keep online card limits lower than main account balances. Review saved cards periodically and remove unused ones.

These steps do not fix merchant validation APIs, but they reduce the time window and blast radius. Speed matters. If an attacker is in the enumeration phase, freezing the card interrupts the chain before monetization. If the attacker already has the full details, replacement is the cleanest answer.

Consumers should also watch for follow-on scams. After a card fraud event, criminals may impersonate the bank, merchant, delivery service, or fraud department. Use official app channels or known phone numbers. Never approve a transaction or share a one-time code because someone calls and claims to be helping.

Practical steps for merchants

Merchants should start with a payment data minimization review. Look at every page, API, receipt, email, invoice, support screen, and export that shows card metadata. Remove issuer digits from consumer views where possible. Hide full expiry unless needed. Show brand and last four by default. Require fresh authentication for sensitive payment method views and changes.

Next, review payment error handling. Public responses should not distinguish invalid PAN, wrong expiry, wrong CVV, AVS mismatch, or other field-level states in high-risk contexts. Client APIs should not expose raw processor codes. Mobile apps should not receive detailed validation fields. Detailed decline reasons should stay server-side, access-controlled, and monitored.

Then review validation flows. Do you allow card verification without a purchase? Do you perform zero-dollar or low-value authorizations? Are those attempts rate-limited by card fingerprint, BIN range, account, device, and IP? Do failed validation attempts feed fraud monitoring? Are suspicious patterns reported to the PSP or acquirer? Are bots challenged before they can test cards?

Review 3DS policy. High-risk transactions, first use of a saved card after a new login, cash-like products, digital goods, gift cards, wallet top-ups, and unusual shipping changes should face stronger authentication. Exemptions should be justified by risk, not just conversion preference. Merchants that allow value withdrawal need stricter controls.

Finally, treat account takeover as payment risk. Require strong login security for accounts with saved cards. Alert users when saved payment methods are viewed from a new device. Step up authentication after password reset. Remove old saved cards. Monitor abnormal access to payment settings.

Practical steps for PSPs and gateways

PSPs should make enumeration resistance a default product property. Hosted payment fields and SDKs should return safe public errors. Detailed processor responses should be available only server-side and role-restricted. Validation endpoints should be monitored as high-risk surfaces. Developer documentation should warn against exposing field-level decline reasons.

Portfolio-level detection is crucial. A PSP can see patterns across merchants that each merchant misses. It can detect repeated CVV mismatches, invalid PAN sweeps, BIN testing, proxy-heavy validation, and abnormal decline ratios. It can throttle, challenge, or suspend abused endpoints. It can warn merchants when integrations leak too much.

PSPs should also provide merchant dashboards that separate genuine customer payment failures from suspected enumeration. A merchant seeing a spike in invalid attempts needs plain guidance: block source patterns, enable stronger bot controls, suppress detailed responses, and contact the acquirer. Fraud teams should not need to reverse engineer their own checkout logs.

Default 3DS routing should reflect product risk. A merchant selling gift cards, wallet value, or cash-like services should not have the same default authentication posture as a low-risk physical goods merchant. PSP onboarding should ask what happens after payment: shipment, digital delivery, stored value, transfer, withdrawal, or subscription access.

Practical steps for issuers and banks

Issuers should treat failed attempts as meaningful data. Declines are not only non-events. Repeated invalid attempts across merchants, especially near an issuer range, can indicate enumeration. Models should watch for range sweeps, CVV testing, expiry testing, merchant clusters, and suspicious low-value authorizations.

Customer controls should be faster and clearer. A 3DS prompt should include a prominent “freeze this card” option when the user denies the transaction. Apps should let users require approval for online payments, block card-not-present transactions, set merchant and category limits, and create merchant-locked virtual cards. Declined suspicious attempts should be visible in transaction history with plain explanations.

After a denied 3DS attempt, the issuer should raise risk on subsequent non-authenticated CNP transactions. If a criminal tries several merchants with 3DS and then moves to a non-3DS merchant, the issuer should not treat that final transaction in isolation. The denied authentication attempts are part of the signal.

Issuers should also share suspected enumeration events with networks and acquirers. A single issuer may see attacks against its own range. Networks can see whether the same merchants or PSPs appear across issuers. Faster sharing reduces the value of abused validation endpoints.

Practical steps for acquirers and payment networks

Acquirers should monitor merchants for decline abuse, not only chargeback ratios. A merchant with many failed validation attempts can be harming the ecosystem even before fraud is confirmed. Acquirer reviews should examine public error mappings, validation endpoint controls, bot defenses, and 3DS policy. Merchants with cash-like flows deserve deeper scrutiny.

Networks should set clearer anti-enumeration standards. Guidance exists, but the industry needs measurable expectations. Examples include limits on public decline detail, monitoring of failed attempts, stronger rules for validation endpoints, and authentication requirements for high-risk cash-out categories. Network monitoring programs should include indicators of testing infrastructure, not only settled fraud.

Networks can also push safer display practices. PCI DSS allows certain maximum PAN display digits, but networks can recommend or require stricter consumer-facing masking for saved cards. The rule should reflect real attack economics, not only storage risk.

Cross-border coordination matters because attackers route through merchants and acquirers in weaker jurisdictions. UK Finance-related reporting has repeatedly noted that large shares of e-commerce card-not-present fraud can involve merchants acquired outside the domestic market, illustrating how fraud routes through global acceptance networks.

The business impact for merchants is larger than chargebacks

Merchants sometimes view card fraud mainly as a chargeback cost. Enumeration risk is broader. A merchant abused as a validation oracle may face higher processing scrutiny, acquirer pressure, network monitoring, fraud tooling costs, customer trust damage, and account takeover fallout. Even if the final fraudulent spend happens elsewhere, the merchant that leaked useful card metadata may lose customer confidence.

Saved-card convenience also becomes a trust issue. Customers save cards because they expect the merchant to reduce friction without raising risk. If a breached merchant account exposes enough data to support card guessing, customers may remove saved cards, use one-time virtual cards, or avoid the merchant. Conversion gains from saved cards can reverse into reputational loss.

There is also engineering cost. Retrofitting safe response mapping after an incident is harder than designing it in. Payment integrations touch checkout, subscriptions, customer support, analytics, mobile apps, fraud tools, and finance operations. A small public error leak may require changes across many systems.

The positive business case is clear. Merchants that minimize displayed card data, use strong tokenization, enforce 3DS for risky flows, and suppress validation detail reduce fraud exposure and support trust. They also reduce the chance of being used as criminal infrastructure. This is not only a compliance matter; it is operational resilience.

The technical fix is boring, and that is good

Security debates often chase new protocols. The credit card brute force problem needs some advanced network intelligence, but many fixes are boring engineering discipline.

Show less card metadata. Return less public detail. Rate-limit by smarter keys. Treat validation as risky. Use 3DS for high-risk flows. Tokenize saved cards. Step up after suspicious account activity. Delay cash-out. Share fraud signals. Monitor failed attempts. Remove unused saved cards. Give consumers instant freeze controls.

None of these fixes requires breaking e-commerce. Some may reduce convenience in edge cases. Most can be risk-based. A trusted returning customer buying a normal product does not need the same friction as a new account trying to top up a cash-withdrawable wallet from a card just added after a suspicious login.

The hard part is incentives. Each merchant benefits from lower friction. The cost of validation leakage may fall on another merchant, issuer, or cardholder. PCI compliance gives a defensible minimum. Chargebacks assign losses after the fact. Attackers exploit the gap between local incentives and system risk. Better rules and defaults must close that gap.

A more honest definition of card safety

A safe card payment is not one where the full PAN is never displayed. It is one where partial data cannot be turned into full credentials cheaply, where failed attempts do not educate attackers, where authentication is triggered for risky transactions, where cash-like value is protected, and where suspicious patterns are shared across the parties that can act.

That definition is stricter than many current implementations. It also matches the real attack. Brute force card fraud is not just about guessing numbers. It is about systems that confirm guesses. The card number, expiry date, CVV, 3DS behavior, merchant risk, and cash-out path all interact. Weakness in one area may be survivable. Weakness across several areas becomes fraud.

The Ozyildirim case is valuable because it shows the lived version of a known academic and industry warning. A masked card looked safe. A merchant account breach looked contained. 3DS looked enabled. PCI DSS looked satisfied. Yet the combination still allegedly led to unauthorized charges through distributed guessing and a non-3DS cash-out merchant.

The right response is not panic. It is a narrower, stronger demand: stop treating compliant card fragments as harmless, stop exposing field-level validation feedback, and stop allowing cash-like online card payments without strong authentication. Credit card security fails less from one dramatic breach than from many small confirmations given to the wrong party.

Reader questions on credit card brute force attacks

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

Credit cards are vulnerable to brute force kind attacks
First-person case report by Metin Ozyildirim describing masked card exposure, merchant validation endpoints, CVV guessing, 3D Secure bypass on some merchants, and cash-out fraud.

PCI Data Security Standard
PCI Security Standards Council overview of PCI DSS as the baseline global standard for protecting payment account data.

Just published PCI DSS v4.0.1
PCI Security Standards Council announcement explaining the PCI DSS v4.0.1 revision, support timeline, and effective-date context.

Frequently asked question 1574
PCI Security Standards Council FAQ stating that card verification codes must not be stored after authorization.

Six seconds to hack a credit card
Newcastle University release summarizing the distributed guessing attack research on online card payment systems.

Does the online card payment landscape unwittingly facilitate fraud
Newcastle University publication record for the IEEE Security & Privacy paper by Mohammed Aamir Ali, Budi Arief, Martin Emms, and Aad van Moorsel.

Does the online card payment landscape unwittingly facilitate fraud
University of Birmingham publication page summarizing the peer-reviewed paper on inconsistent online payment practices and distributed attack risk.

Does the online card payment system unwittingly facilitate fraud
Newcastle University thesis record expanding on card-not-present payment security weaknesses and fraud mechanisms.

Visa guidance to guard against enumeration attacks and account testing schemes
Visa guidance for acquirers, issuers, processors, and agents on detecting and blocking enumeration and account testing.

Anti-enumeration and account testing best practices for merchants
Visa merchant guidance defining enumeration attacks and account testing in card-not-present payment flows.

EMV 3-D Secure
EMVCo overview of EMV 3-D Secure for preventing card-not-present fraud and improving e-commerce authentication.

EMVCo updates EMV 3DS specifications to help issuers and merchants combat growing CNP fraud risks
EMVCo announcement on EMV 3DS version 2.3.1 and its card-not-present fraud prevention updates.

Visa Secure EMV 3-D Secure for merchants
Visa merchant resource describing Visa Secure as its EMV 3-D Secure program for helping prevent card-not-present fraud.

3D Secure your guide to safer transactions
Visa explanation of 3D Secure authentication and its role in safer e-commerce payments.

Secure identity authentication and payment optimization
Mastercard page describing online authentication, address validation, and CVC2 tools for card-not-present risk.

Mastercard Identity Check
Mastercard developer resource for Identity Check authentication in online transaction flows.

Joint EBA-ECB report on payment fraud
European Central Bank release summarizing 2024 EEA payment fraud figures and the continued role of strong customer authentication.

ECB and EBA publish joint report on payment fraud
European Central Bank release on payment fraud data for the first half of 2023, including card fraud rates.

Over £600 million stolen by fraudsters in first half of 2025
Take Five and UK Finance public update on 2025 fraud trends, including card-not-present case growth.

Annual fraud report 2025
UK Finance report covering UK fraud patterns, prevention figures, and payment card fraud context.

Half year fraud report 2025
UK Finance half-year report with payment card fraud categories and 2025 trend data.

Card fraud losses worldwide 2024
Nilson Report article describing global card fraud loss context and the concentration of card-not-present fraud in the United States.

Global card fraud losses at $33 billion
Newswire summary of Nilson Report’s 2024 worldwide card fraud loss estimate.

EU agrees on new rules for online fraud protection
Reuters report on EU-level agreement for stronger online fraud protection rules and payment provider obligations.