Strong Customer Authentication: what actually decides whether a European advertiser's renewal goes through
An advertiser based in Germany has been paying for the same listing package for eight months. The card hasn't expired, hasn't been replaced, and has plenty of room on it. Then one renewal simply doesn't go through, the listing drops out of the queue a few days later, and the advertiser writes in confused and a little annoyed, because nothing on their end changed. Support pulls up the transaction log, sees a plain decline with no obvious reason attached, and does the only thing that seems available: asks the advertiser to re-enter their card details. The retry works. Two months later, the same advertiser gets declined again.
That pattern looks a lot like the ordinary business of a reissued card, the kind of failure that network update services exist specifically to catch, and a lot of operators chase it the same way: assuming the stored card number is stale and waiting for an update service to fix something it was never built to fix. A reissued card is a dead number. This is a live number that a European bank, acting on its own rules, is choosing not to let through without a second step the checkout never asked for.
That second step has a name: Strong Customer Authentication, the European rule that requires most electronic card payments to be verified with two independent factors before an issuing bank will approve them. Whether a renewal clears it depends on decisions made somewhere inside the payment stack, usually at signup, usually without anyone treating it as a decision at all.
What Strong Customer Authentication actually requires, and who it reaches
Strong Customer Authentication, SCA, is a requirement under the EU's revised Payment Services Directive, generally enforced since the early 2020s and applied through a technical standard overseen by the European Banking Authority. In practice, SCA is carried out through 3-D Secure version 2, the messaging protocol that lets a merchant's payment gateway and a card's issuing bank exchange enough information, about the transaction, the device, and the cardholder's session, for the issuer to decide the payment is genuinely coming from the person who owns the card. The verification itself can be a visible step for the cardholder, a one-time code, a prompt in a banking app, or it can happen invisibly in the background when the issuer's risk engine is already satisfied. Either way counts as SCA; a visible challenge screen is not the requirement, genuine two-factor verification is.
The most common assumption an operator outside Europe makes is that none of this applies to a business with no EU entity, no EU bank account, and an acquirer or payment gateway based somewhere else entirely. That assumption is worth examining directly, because getting it wrong shapes how much effort an operator is willing to put into fixing it. The EU rule extends to transactions carried out in the Union, and European regulators have been explicit that this reaches one side of a payment even when the other side sits outside the EEA: a card issued by a European bank keeps its issuer bound by the authentication requirement regardless of where the merchant or its acquirer is based. The business's own location, incorporation, or payment provider does not remove the obligation sitting on the issuing bank.
What actually varies, in practice, is not the legal obligation but whether it can be carried out at all. An issuing bank can only run 3-D Secure authentication if the merchant's gateway and acquirer are set up to exchange that data in the first place. A high-risk acquirer that never built full 3-D Secure 2.x support into its stack simply cannot pass the authentication request through, whatever the rule says. The issuer, unable to authenticate the cardholder through that channel, doesn't get to skip the decision; it falls back to its own fraud-risk judgment on an unauthenticated payment, which can mean an approval, a request for a verification the merchant's checkout has no way to deliver, or a plain decline. A joint report published by the European Central Bank and the European Banking Authority in December 2025 found that card payment fraud, measured as a share of transaction value, ran seventeen times higher on payments where the merchant receiving the funds was outside the EEA and authentication wasn't in place, compared with authenticated payments inside it. The report doesn't break that figure out by merchant category, and it isn't a claim about any one industry; it describes what happens generally when a payment reaches a European cardholder's bank without the verification that bank was built to expect. An issuer reading that pattern across its whole portfolio has every reason to treat an unauthenticated charge from an unfamiliar merchant with more suspicion, not less.
The first charge sets what every renewal after it is allowed to do
Subscription billing gets a specific, narrower allowance under the same rule: once the first payment in a recurring series has actually been authenticated, the renewals that follow can be exempted from going through SCA again each time, treated instead as a known, continuing arrangement rather than a fresh transaction needing fresh verification. That allowance is conditional on the first charge, not a general pass for recurring billing as a category.
This is where a decision made at signup, often made for reasons that have nothing to do with Europe specifically, quietly sets up every later failure. A checkout built to minimize friction at the moment of sale, skipping authentication on the first charge to avoid losing a hesitant new advertiser, has also skipped the one event that would have let every renewal after it claim the recurring exemption. There is no retroactive fix. A series that started without authentication doesn't get to borrow it from a later renewal; each charge in that series keeps facing the issuer's full, un-exempted risk judgment, indefinitely, because the one transaction that could have established it as a trusted series never happened.
The fix is not complicated once it's visible, but it has to happen at the right moment. The first charge from a new advertiser, if that advertiser's card was issued by a European bank, needs to actually go through full authentication, not be waved through for the sake of a smoother first impression. One moment of friction at the start, which in a well-built flow is often invisible to the cardholder anyway, is what makes every renewal afterward eligible to be treated as routine instead of suspicious.
Why a correctly flagged exemption can still come back declined
Even with that first charge handled correctly, a flagged exemption is a request, not a guarantee. A merchant's gateway can mark a renewal as exempt from authentication, citing the recurring arrangement, and the issuing bank's system still makes the final call. Issuers override exemption flags routinely, for reasons that have nothing to do with the advertiser doing anything wrong.
A few triggers show up often enough to be worth knowing by name. The authentication record tied to that original first charge doesn't last indefinitely; networks and issuing banks each set their own shelf life for it, and once it ages out, the issuer can no longer rely on it to cover a new renewal. A renewal amount that differs meaningfully from what was authenticated originally, which happens constantly with a trial period converting to a paid rate or a price increase applied mid-subscription, can also push the issuer to treat the charge as something new rather than a continuation. And an issuer's own fraud-risk scoring for a given cardholder shifts on its own schedule, for reasons that live entirely on the bank's side and have nothing to do with the merchant or the advertiser.
There is a specific tool built for exactly this gap: a feature of 3-D Secure 2.1 and later called 3RI, short for 3DS Requestor Initiated, that lets a merchant's gateway re-authenticate an off-session renewal by referencing data from the advertiser's original session, without pulling them back through a checkout screen or asking them to do anything at all. Not every processor that supports basic 3-D Secure 2 has also implemented 3RI specifically, and a merchant account opened purely for its lower fees, without that question ever being asked, can be missing it entirely. Finding out is a direct question to ask a processor, not something to discover from a pattern of declines months later.
What a successful authentication buys beyond fewer declines
Getting authentication right on these charges does more than reduce false declines. When a transaction is genuinely authenticated under SCA, not merely flagged as exempt, liability for a resulting fraud or unauthorized-use chargeback generally shifts from the merchant to the card-issuing bank, across the major networks. An advertiser who never paid declaring unauthorized use is a liability the merchant was carrying by default, and a properly authenticated payment moves a real piece of that exposure off the business.
That shift only covers chargebacks filed on fraud and unauthorized-use grounds specifically, and it's worth being precise about that, because it's easy to overstate. It does nothing for the other reasons an advertiser's charge comes back as a dispute, a service not delivered as described, a subscription an advertiser insists they tried to cancel, a duplicate charge from a billing error. Authentication narrows one real slice of chargeback exposure. It was never going to close all of it, and treating it as a complete fix for chargeback risk sets an operator up to be surprised by the next dispute that isn't a fraud claim at all.
Weighed against the alternative, the trade is straightforward. A small amount of friction once, at signup, for an advertiser whose card was issued by a European bank, buys a renewal history that an issuer is willing to treat as routine for as long as that history stays current. Skipping it buys one marginally smoother sign-up and a subscription that fails unpredictably starting at the second or third renewal, for a reason the advertiser never caused and support has no way to explain without knowing to look for it.
What to actually check this month
Start with a direct question to the payment processor: does the gateway support full EMV 3-D Secure 2.x message exchange with European issuing banks, not just basic card capture, and is it switched on for this specific merchant account rather than merely available in the contract. Those are different answers, and the second one is the one that determines whether any of this actually runs.
Confirm separately that authentication runs on the first charge from every new advertiser whose card was issued in the EU or UK, not only after a decline pattern has already shown up. A checkout tuned to minimize friction at signup for every market, without an exception for this one, is the single most common way this gets missed.
Ask explicitly whether the processor supports 3RI or an equivalent merchant-initiated re-authentication for renewals, since that is the specific feature that refreshes an aging authentication record without pulling the advertiser back through a verification screen. Basic 3-D Secure 2 support and 3RI support are not the same line item, and a sales conversation that covers one rarely volunteers the other.
Pull decline codes for the last few months and split them by the card's issuing country rather than looking at the aggregate rate. A meaningfully higher failure rate on EU and UK cards than on domestic ones is a specific, diagnosable signal, and it's the kind of detail worth bringing to the processor directly, with the codes attached, rather than describing as a general sense that European renewals feel unreliable.
None of this requires rebuilding checkout. It requires one set of direct questions to whoever already processes these payments, asked before the next advertiser with a European bank card signs up, not after their third quiet decline.
