PSD2 and SCA for US Merchants
- Check both banks' locations. An EEA-issued card alone doesn't make a US-acquired payment subject to the same SCA duties as an EEA-acquired one. Ask your processor which route you use
- The liability shift is the payoff: eligible 3DS-authenticated payments can move fraud dispute liability to the card issuer
- Exemptions have conditions: low-value, low-risk TRA and qualifying recurring payments. Off-session merchant-initiated payments are a separate category
- Build the authentication fallback. If the issuer requires SCA, an unauthenticated payment can be declined
You sell to European customers and your business is registered in the US. Check where your acquirer and the customer's issuer are located. PSD2 (Payment Services Directive 2) is the European law. SCA (Strong Customer Authentication) is the authentication rule inside it.
The short version: Ask your processor which payments need SCA, then test your 3D Secure flow. A US registration alone doesn't answer that question. EBA scope guidance, Stripe's SCA guide. Checked 22 October 2026.
Does This Apply to You?
Check SCA for:
- Customer-initiated electronic payments where both issuer and acquirer are in the EEA
- Card-present payments too. Chip + PIN or a qualifying mobile wallet can satisfy SCA
- UK payments under the UK's separate SCA rules
Check the route separately for:
- An EEA issuer with a US acquirer: the acquirer isn't subject to PSD2, but the issuer can still request authentication or decline
- An issuer outside the EEA: don't assume the acquirer has no SCA duties
- Phone/mail orders and off-session merchant-initiated payments: flag the actual payment type correctly
The trigger isn't the customer's physical location. Check the issuer, acquirer and payment type.
What is SCA?
Strong Customer Authentication requires two of three factors:
| Factor | Examples |
|---|---|
| Knowledge | Password, PIN, security question |
| Possession | Phone, card, hardware token |
| Inherence | Fingerprint, face recognition, voice |
For card payments: 3D Secure (3DS) is the standard SCA implementation.
A banking-app challenge can combine:
- Knowledge: a password or PIN, or inherence: a biometric
- Possession: the registered phone
- Two independent factors. A biometric isn't a knowledge factor
How SCA Works for US Merchants
Without 3DS (Non-Compliant)
Result: If the issuer requires SCA and no exemption or out-of-scope route applies, it can decline the payment. Track those declines separately.
With 3DS (Compliant)
Result: Successful authentication lets the payment proceed to authorization. It doesn't guarantee approval. Check the payment's liability-shift status.
When SCA Is Required
| Transaction Type | SCA Required? | Notes |
|---|---|---|
| Initial card-not-present | Usually, if in scope | Check exemption eligibility; phone/mail orders differ |
| Recurring (after first) | Depends | Same-amount, same-payee recurring exemption has conditions |
| Card-present (chip + PIN) | Satisfied by chip + PIN | Card-present isn't outside SCA |
| Contactless under €50 | May be exempt | Cumulative amount/count limits also apply |
| Merchant-initiated (MIT) | Outside scope if correctly set up | Prior mandate; customer isn't initiating the payment |
The first payment or mandate setup may need authentication. Later payments aren't automatically exempt just because you call them subscriptions. Stripe explains recurring payments and MIT separately.
SCA Exemptions
European regulations let you skip SCA in a few specific cases:
| Exemption | Criteria | Merchant Burden |
|---|---|---|
| Low-value | Under €30 | Issuer tracks cumulative amount/count since the last SCA |
| Recurring payments | Same amount, same payee | Authenticate setup or the first payment; distinguish off-session MIT |
| TRA (Transaction Risk Analysis) | Low-risk payment and qualifying payment-provider fraud rate | Provider thresholds: 0.13% for €100, 0.06% for €250, 0.01% for €500; ask your processor which ceiling it can request |
| Trusted beneficiaries | Customer whitelists merchant | Customer must add you through the issuer's authenticated process |
| Corporate payments | Eligible lodged or virtual corporate-card payments | Not a blanket exemption for B2B cards |
| Secure corporate process | Dedicated qualifying payment processes | Confirm issuer approval and eligibility |
See: 3DS Exemptions for full details.
How to Comply (Implementation)
Step 1: Enable 3DS
If you're on Stripe:
- Check that you're using an SCA-ready integration, such as Checkout or Payment Intents
- Handle any authentication action Stripe returns
- Test challenges and failures. A legacy integration or outdated plugin may need changes
If you're on Shopify Payments: Turn 3D Secure on in your Shopify Payments settings under Fraud prevention. Shopify Payments only uses 3DS when the card-issuing bank requires it, and stores in a PSD2 region automatically use a 3DS checkout flow. See Shopify's 3D Secure guidance.
If you're on Square:
- Square supports 3DS through its Web Payments SDK and In-App Payments SDK
- Square Online and Invoices manage their integrations. Custom API integrations need the buyer-verification flow
- Outside mandated markets, check Risk Manager and whether your integration supports 3DS. Square's SCA guide, checked 22 October 2026
If you're on a traditional processor:
- Contact your processor to enable 3DS
- Integration required (varies by processor)
- Ask for an estimate against your checkout and SDK version, including challenge and failure testing
Step 2: Handle Redirects
A 3DS challenge may appear inside checkout, in a bank app or through a redirect:
- Customer enters card on your checkout
- Your processor requests authentication if needed
- Customer completes any challenge (password, biometric, etc.)
- Your checkout handles the result
- Submit or complete authorization
On mobile: follow your processor's supported SDK or redirect flow. Test the return to checkout.
Step 3: Request Exemptions When Possible
For a low-risk payment, your processor may request a TRA exemption:
- It can reduce friction
- The payment provider's fraud rate and other eligibility tests apply
- The issuer can refuse and require authentication
Stripe's SCA-ready products request exemptions when eligible. Test the authentication fallback. Stripe's guide.
Step 4: Flag Recurring Properly
For subscriptions:
- Get the customer's agreement for later charges
- Authenticate the first payment or card setup when required
- Flag qualifying off-session charges as MIT
- Build a return-to-checkout flow if the bank requires authentication
Check your processor's setup requirements. On Stripe, use Payment Intents or Setup Intents with the right future-use settings. Integration guidance.
What Happens If You Don't Comply
Immediate Impact
Issuers can decline payments missing required authentication:
- Track SCA-required declines separately from other failures
- Check failed and abandoned authentications
- Test the fallback after a rejected exemption
A decline costs you the sale. Don't treat every European decline as an SCA problem.
No Direct Penalties for Non-EU Merchants
For a US merchant using a US acquirer, the acquirer isn't subject to PSD2's SCA duties. The EEA issuer still has duties on its side and can require authentication or decline the payment. That's the one-leg-out case.
Check your acquiring route and contract before assuming either a direct fine or a processor pass-through applies. A US registration doesn't answer every regulatory question. EBA scope guidance.
PSD2 Beyond SCA
PSD2 covers a lot more ground than just SCA:
| PSD2 Component | What It Is | US Merchant Impact |
|---|---|---|
| SCA | Authentication requirement | Check acquiring route and payment type; support 3DS where needed |
| Open Banking | API access to bank data | Enables pay-by-bank methods |
| Payment initiation | Third-party payment initiation | Enables SEPA alternatives |
| Direct debit refunds | A SEPA Core payer can request a refund of an authorised debit within 8 weeks without justification; an authorised SEPA B2B debit has no corresponding refund right | Only if you take SDD. Cards aren't affected |
| Surcharging ban | Can't surcharge most EU cards | Check by country |
For most US SMBs: SCA is the part you'll build. It isn't the only part that reaches you.
Targeting consumers in EU Member States? Consumer contract law may apply on top
The 14-day withdrawal right isn't PSD2. It comes from EU consumer contract law. Member States were required to apply the new online withdrawal-function rules from 19 June 2026.
For a covered distance contract concluded through an online interface, the trader must keep a prominent, easily accessible "withdraw from contract here" function available throughout the withdrawal period. It must let the consumer provide or confirm their name, the contract identifier, and where electronic confirmation should be sent, then submit through a separately labelled "confirm withdrawal" function. An email address alone doesn't satisfy Article 11a. Before the consumer is bound, tell them where the function is. After submission, send an acknowledgement of receipt on a durable medium, including the statement's content and submission date and time, without undue delay.
This applies only where the contract falls within the Consumer Rights Directive, was concluded through an online interface, and carries a statutory withdrawal right; the directive's scope exclusions and withdrawal exceptions still apply. Member States transpose and enforce the harmonised rule nationally, so verify the current implementing law and penalties in each EU consumer market you serve.
US Merchant Compliance Checklist
□ Confirm your acquiring route and enable the supported 3DS flow
□ Test authentication challenges and failures using processor test cards
□ Handle embedded challenges, bank-app handoffs or redirects as your SDK requires
□ Get a mandate and flag qualifying off-session payments as MIT
□ Request TRA exemptions for low-risk transactions (if available)
□ Monitor European auth rates by issuer country, separating SCA declines from other reasons
□ Check if surcharging is allowed in target EU countries
□ Determine which EU consumer withdrawal rules apply to your contracts and online checkout
Test to Run
EU compliance audit (3 weeks):
Week 1: Geography check
- Calculate % of revenue from EU customers: ____%
- Pull auth rates for EU transactions
- Check if 3DS is enabled (look for "3DS" in transaction logs)
Week 2: Auth rate analysis 4. Compare EU auth rates before and after 3DS on the same issuer-country and customer segment 5. Investigate SCA decline codes, failed authentications and abandoned challenges separately 6. Track frictionless rate (% that don't see a challenge) alongside completed payments
Week 3: Exemption optimization 7. Check if TRA exemptions are being used 8. Monitor low-value exemptions (under €30) 9. Ensure recurring payments are MIT-flagged
Success criteria: required authentication works in your tests. On the same issuer-country and customer segment, compare completed payments, auth rates and fraud losses before and after. Investigate remaining SCA decline codes.
Scale Callout
Your sales volume doesn't create an SCA exemption. Start with the same checks at any size:
- Confirm issuer and acquirer locations
- Test required authentication and fallback behavior
- Monitor failed payments by issuer country
- Optimize exemptions only after the flow works
As European sales grow, assign someone to review challenge completion, fraud losses and processor support. Use your own traffic to decide when that needs dedicated time.
Where This Breaks
-
UK left EU but kept SCA: Check the UK's separate rules with your processor.
-
Issuer behavior differs: An exemption isn't a guaranteed approval. Keep an authentication fallback.
-
Card-present can satisfy SCA: Chip + PIN and qualifying mobile wallets can meet it. Don't treat in-person payments as outside scope.
-
Recurring isn't one category: Same-amount recurring exemptions and off-session MIT have different conditions. A bank can still request authentication.
-
TRA uses the payment provider's fraud rate: Ask which thresholds your processor qualifies for. Your own low fraud rate alone doesn't establish eligibility. Stripe's guide.
Common US Merchant Questions
"Do I need a European entity?"
Not necessarily. Check your acquiring route:
- EEA issuer and EEA acquirer: check in-scope SCA requirements
- EEA issuer and US acquirer: one-leg-out rules; issuer authentication requests can still matter
"What if I only sell B2B?"
Maybe exempt. Corporate cards can be exempt from SCA, but:
- Depends on card type (not all corporate cards are exempt)
- Issuer decides
- Safer to implement 3DS anyway
"Can I just block European customers?"
Yes, but:
- Check how many completed sales and attempted orders come from those markets in your own records
- Ask your processor which acquiring route and 3DS setup you need
- Test that setup before deciding to exclude customers
"Does this apply to PayPal?"
PayPal isn't outside SCA. PayPal handles authentication in its wallet flow, but card integrations have their own setup requirements.
If customers pay by card through PayPal: check your SDK and SCA settings, then test the challenge and return flow. PayPal's card integration guide, checked 22 October 2026.
Next Steps
Selling to Europe?
- Read 3D Secure guide for implementation
- Enable 3DS in Stripe dashboard (or verify it's enabled)
- Test with European test cards
Optimizing EU compliance?
- Review 3DS Exemptions for TRA/low-value
- Monitor frictionless authentication rates
- Send more data for better TRA qualification
Want alternatives to card checkout?
- Compare regional payment methods, such as iDEAL and Bancontact
- Check each method's authentication flow. Bank payments aren't a blanket escape from SCA
- Consider PayPal, then test the flow your integration uses
See Also
- 3D Secure - Full 3DS implementation guide
- 3DS Exemptions - TRA, low-value, recurring
- European Payment Methods - iDEAL, Bancontact, SEPA
- Going Global - International expansion strategy
- Stripe - Check an SCA-ready integration
- Checkout Conversion - Optimizing with 3DS
- Consumer Protection - EU consumer rights