Payment authentication: methods, 3DS, SCA, and best practices
Payments 101
Updated 29 May 2026
11 min
Andrii Kononenko
Head of Merchant Operations, Solidgate
Most authentication problems are configuration gaps. Here's how to find and fix them.
EU and EEA card fraud is when the merchant is located outside the region where Strong Customer Authentication isn't legally required. That gap isn't geography. It's payment authentication.
For payment teams, authentication failures don't announce themselves. They show up as declining approval rates, chargeback clusters in a specific market, or compliance declines that take days to trace back to a cause.
This guide covers the methods behind payment authentication, how they interact with your stack, and best practices for optimizing it.
TL;DR
- Authentication ≠ authorization. Authentication confirms who's paying before the issuer decides whether to approve. Getting this step wrong affects your approval rates, fraud exposure, and compliance standing – all at once.
- 3DS2 is the only method that satisfies SCA. CVV, AVS, and device fingerprinting contribute useful signals, but none of them replace 3DS2. They feed into it.
- When you send a 3DS2 request without device, browser, or account history signals, the issuer defaults to a challenge. Better data means more frictionless approvals.
- SCA has legitimate exemptions – and most merchants underuse them. Low-value transactions, merchant-initiated recurring charges, and low-risk TRA transactions can all bypass the challenge step without breaking compliance.
- Authentication is an ongoing operational metric. Track challenge rate, frictionless approval rate, and challenge completion by issuer and market. When a corridor underperforms, identify the specific BINs before touching your configuration.
What is payment authentication
Payment authentication is the process of verifying that a transaction is initiated by the legitimate account holder. It answers one question before a payment clears: is this person who they say they are?
Authentication is not the same as payment authorization. Authentication confirms identity – authorization is the issuer's decision to approve or decline the transaction once identity is established. Authentication happens first, and its outcome directly influences that decision.
For online payments, authentication matters more than in card-present environments. When a card is physically present, it confirms the cardholder is there. Online, that confirmation disappears – a fraudster with stolen card details can initiate a transaction that looks identical to a legitimate one. Payment authentication fills that gap by verifying identity through protocols, data signals, and active checks at the point of purchase.
, the regulatory framework under , was introduced specifically to address this risk. It requires that customer-initiated payments use at least two of three verification factors:
- Something the customer knows (e.g. a password)
- Something the customer has (e.g. a mobile device)
- Something the customer is (e.g. biometric data)
Payment authentication methods: The core protocols and tools
Several methods are used in digital payment authentication. They operate at different points in the transaction flow and serve different purposes – some verify identity directly, others contribute fraud signals that feed into that verification. Understanding the distinction matters when you're deciding which methods to configure and why.
3D Secure 2 (3DS2) – the primary protocol for card payments
3DS2 is the standard authentication protocol for card-not-present transactions. It routes each payment toward one of two outcomes:
- Frictionless flow: the issuer silently approves based on background risk signals, with no customer action required.
- Challenge flow: the issuer asks the cardholder to verify via OTP, biometric prompt, or banking app confirmation.
When a challenge is triggered, the customer verifies through one of two common mechanisms: OTP or biometrics. OTP delivers a temporary code via SMS or authenticator app. uses a fingerprint scan or facial recognition on the customer's own device to complete the step in under a second.
Biometric challenge completion rates tend to be higher than OTP rates for mobile users because there's no SMS dependency and no context switch away from the app.
What makes 3DS2 effective is the volume of context it sends to the issuer. Device data, purchase history signals, account age, and billing consistency all travel with the authentication request. The issuer uses this to make a risk decision – and the more complete the data, the more likely it is to approve without asking the customer to do anything. That’s why data quality in the authentication request matters as much as the protocol itself.
The current specification, 3DS v2.3, extends this further. It adds support for banking app authentication via a separate channel, biometric passkeys through WebAuthn, and native mobile SDK flows. This keeps the verification step inside the app rather than redirecting users elsewhere.
For a full breakdown, see our guide on.
One significant commercial benefit of running 3DS2 is the liability shift. When the issuer authenticates a transaction and fraud occurs, liability transfers from the merchant to the issuer. This makes 3DS2 valuable not just as a compliance mechanism but as a chargeback protection tool.
CVV (Card Verification Value)
CVV is the three or four-digit code printed on a physical card. Collecting it at checkout confirms the customer physically holds the card, not just its number.
Benefits:
- Provides a baseline check that the customer physically possesses the card, adding protection against fraud from stolen card numbers alone
- Requires no additional integration and adds no friction beyond a standard data entry field
Limitations:
- Doesn't satisfy SCA on its own – it's a single verification factor, not two-factor authentication
- Offers no protection if a fraudster physically holds the card or has written down the code
- Can be compromised in data breaches that expose full card details alongside the CVV
AVS (Address Verification System)
AVS checks whether the billing address entered at checkout matches the address the issuing bank has on file. The merchant receives a response code – full match, partial match, or no match – and decides whether to proceed. It verifies a data point, not an identity.
Benefits:
- Adds no visible friction to checkout and requires minimal implementation effort
- Provides a useful supplementary fraud signal for card-not-present transactions, particularly for US-based volume
Limitations:
- Available primarily in the US, Canada, and UK – it has no meaningful coverage across most global markets
- Billing address data is relatively easy for fraudsters to obtain, which limits its reliability as a standalone check
- Partial match responses require judgment calls that can produce false declines on legitimate transactions
Device fingerprinting and behavioral analytics
Device fingerprinting collects device-level signals – IP address, browser version, operating system, screen resolution – to assess whether the transaction matches the cardholder's known device profile. Behavioral analytics adds session-level signals: typing cadence, cursor movement, and time on page. Both run in the background with no customer interaction.
Benefits:
- Feed the 3DS2 data payload with signals that improve frictionless approval rates – the more context the issuer receives, the less likely it is to trigger a challenge
- Flag transactions that deviate from established patterns before they reach authorization, providing an early warning signal for potential fraud
Limitations:
- Neither method verifies identity directly – both contribute signals to a risk decision, not a definitive authentication outcome
- Device fingerprints can be spoofed by sophisticated fraudsters using privacy tools or virtual machines
Payment authentication methods [A comparison table]
| Method | Satisfies SCA? | Friction level | Where it sits | Primary role |
| 3DS2 | Yes | None – medium | Protocol level | Primary authentication protocol for card-not-present |
| CVV | No (alone) | Low | Checkout data entry | Baseline card possession check |
| AVS | No | Low | Checkout data entry | Supplementary fraud signal – US / UK / CA |
| Device fingerprinting | No | None | Background | Risk input into 3DS2 |
| Behavioral analytics | No | None | Background | Fraud pattern detection |
Core insight: 3DS2 is the only method in this list that directly satisfies SCA and verifies identity. CVV and AVS contribute supporting signals at the checkout data level. Device fingerprinting and behavioral analytics feed the background risk signals that determine which 3DS2 path each transaction takes. None of the supporting methods replace 3DS2 – they feed into it or sit alongside it.
7 best practices for optimizing payment authentication
1. Send complete data through 3DS2
The most common cause of unnecessary challenge flows isn't the protocol. It's incomplete data. When a merchant sends a 3DS2 authentication request without device fingerprint data, browser metadata, or account history signals, the issuer has no basis for a frictionless decision and defaults to a challenge.
Completing the 3DS2 data payload – including device channel, browser data, cardholder account information, and purchase history indicators – gives issuers the context to approve without interrupting the customer. This is the highest-leverage change most merchants can make to their authentication configuration before touching anything else.
2. Apply SCA exemptions strategically
SCA is mandatory in the EEA for customer-initiated payments. But the regulatory technical standards include legitimate exemptions that allow certain transactions to bypass the challenge step without breaking compliance:
- Low-value transactions under €30, subject to cumulative velocity limits.
- Merchant-initiated transactions (MITs): Recurring billing charges following an initial authenticated transaction. These don't require re-authentication per billing cycle. For businesses running, correct MIT classification is one of the simplest ways to reduce friction in renewal flows. is the mechanism that makes this work – the first transaction establishes consent, and subsequent renewals process without interrupting the customer.
- Transaction Risk Analysis (TRA): If the acquirer's fraud rate sits below defined thresholds, it can request exemptions for specific transactions based on real-time risk scores. Those are tied directly to the transaction amount – up to €100 at a fraud rate below 0.13%, up to €250 below 0.06%, and up to €500 below 0.01%.
- Trusted beneficiary: Customers can whitelist merchants so future payments bypass SCA automatically.
- One-leg-out transactions: SCA applies only when both the payer's issuer and the merchant's acquirer are located in the EEA. When either party sits outside the EEA, SCA doesn't apply – this is a scoping rule, not a standard exemption.
3. Build biometric flows for mobile and in-app
OTP delivery via SMS remains the most common challenge method – and one of the weakest in mobile contexts. It's slow, dependent on network availability, and increasingly targeted by SIM-swapping attacks. For in-app users, it interrupts the experience with a context switch to a messaging app.
Biometric flows built into 3DS2's mobile SDK replace OTP delivery with a fingerprint or facial scan that completes in under a second. The found that 22% of euro area consumers actively preferred biometric authentication for online payment verification.
4. Use network tokenization as an authentication trust layer
replaces the raw card number with a network-issued token. At the moment of purchase, the card network generates a unique cryptogram tied to that specific transaction – proof that the credential came through a verified, network-controlled channel.
This is why issuers treat tokenized transactions differently. The credential itself carries verification the issuer can trust. That reduces the need to interrupt the customer with a challenge step. Across our merchant base, tokenized transactions carry up to 15% better acceptance rates.
Solidgate's provider-agnostic stores and routes network tokens – remaining valid when a card is reissued or when the merchant switches acquirers.
For instance, when one of Zeely's acquirers shut down unexpectedly, every stored token transferred to the new providers with near-zero recurring payment loss.
→ See the full .
Network tokenization and 3DS2 work together. 3DS2 gives the issuer behavioral and device context. Network tokenization gives it credential-level trust. Used together, they reduce the likelihood of a challenge without adding friction on either side.
5. Calibrate adaptive authentication by market and issuer
Issuer behavior varies significantly by corridor. A 3DS2 configuration that produces strong frictionless rates in one market can generate challenge-heavy flows or unexpected declines in another. No amount of payload completeness will fix it because this is a configuration problem.
Calibration starts at the Bank Identification Number (BIN) level. When a corridor underperforms – lower frictionless rates than your baseline, or challenge completion rates that drop without explanation – identify which issuer BINs are driving the deviation before touching your configuration. Blanket adjustments in response to corridor-level data create new problems in the BINs that were working.
The adjustment levers are specific. Acquirer selection matters because different acquirers carry different processing relationships with issuers in specific markets, and those relationships affect authentication outcomes directly. Exemption strategy matters because TRA eligibility depends on the acquirer's fraud rate in that corridor – not just the individual transaction profile. If that rate sits above the applicable threshold, TRA is unavailable regardless of how clean the transaction looks. And some issuers in specific markets respond better to banking app authentication than to OTP – configuring for that reduces challenge abandonment without touching anything else in the stack.
6. Track regulatory changes by market
Payment authentication is a regulated domain, and requirements evolve. Several changes are active across major markets right now:
- EU: PSD3 is . The European Commission's proposals for a third Payment Services Directive and a Payment Services Regulation will refine SCA exemption criteria. They will also introduce new requirements around fraud liability and data sharing.
- Japan: Under , merchants must apply 3DS to all e-commerce credit card transactions from April 1, 2025, covering both domestic and cross-border transactions.
- India: The mandates Additional Factor of Authentication (AFA) for all domestic e-commerce card transactions. 3DS is the primary mechanism used to comply
| Market | Regulation | SCA requirement | Primary method |
| EEA | PSD2 | Mandatory for customer-initiated payments | 3DS2 |
| UK | UK FCA / PSR | Mandatory for customer-initiated payments | 3DS2 |
| India | RBI AFA mandate | Mandatory for domestic e-commerce | AFA / 3DS |
| Japan | METI Credit Card Security Guidelines 5.0 | Mandatory for all e-commerce credit card transactions | 3DS2 |
| US | No federal mandate | Optional | 3DS2 (optional) |
7. Monitor authentication as an ongoing operational metric
Most authentication problems accumulate. Issuers change how they evaluate risk, fraud patterns shift, and configurations drift – often without any visible trigger.
The metrics that matter:
- Challenge rate by issuer and market: how often customers are asked to verify
- Challenge completion rate: what proportion of challenged customers complete the step
- Frictionless approval rate: transactions approved without customer action
- Post-authentication conversion rate: whether customers who complete a challenge proceed to pay
- Authenticated vs. unauthenticated chargeback rate: the fraud impact of authentication coverage decisions
A high challenge rate with low completion points to an issuer configuration issue or a UX problem in the challenge flow. A low frictionless rate despite low fraud suggests the 3DS2 data payload is incomplete.
When a metric deviates, identify which issuer BINs and transaction types are driving it before changing the configuration. Blanket adjustments in response to isolated data points create new problems in corridors that were working.
When a corridor underperforms – high challenge rates, low frictionless approvals – the issue is often at the acquirer level. Different acquirers carry different processing relationships with issuers in specific markets, and those relationships affect authentication outcomes directly.
Solidgate's evaluates each transaction and routes it to the provider most likely to approve it – by market, issuer behavior, and cost. Merchants optimizing routing alongside authentication configuration consistently outperform those treating them separately.
and data shows whether authentication gaps have already translated into fraud losses – often before the authentication metrics flag the issue.
Core insight: Authentication performance is an operational KPI, not a one-time implementation decision. Merchants who treat it as a live metric consistently outperform those who configure and move on.
When to accept authentication friction
Reducing friction is the right goal in most payment authentication decisions – but not in all of them. Here are the profiles where accepting a challenge makes a commercial sense:
High-value one-time transactions. When the transaction amount significantly exceeds the cardholder's typical spend, an additional verification step reduces both fraud risk and chargeback exposure.
New devices on existing accounts. A cardholder authenticating from an unrecognized device for the first time is a common account takeover vector. A challenge at that point is less disruptive than a fraudulent transaction the cardholder disputes a week later.
Transactions flagged by behavioral or device signals. When the device fingerprint, IP address, or session behavior doesn't match the cardholder's history, a challenge provides a second verification layer. It stops fraud without permanently blocking the customer.
Specific issuer and country BIN corridors with elevated fraud rates. Some processing corridors carry structurally higher fraud rates. Applying stronger authentication to that traffic – even where exemptions technically apply – is a defensible tradeoff when the fraud rate in that corridor supports it.
Core insight: The question isn't whether to apply friction – it's whether the risk profile of that specific transaction justifies it.
Optimize payment authentication with Solidgate
Getting authentication right affects approval rates, fraud exposure, and compliance standing simultaneously. Every misconfigured decision has a measurable cost somewhere in those three.
Solidgate manages authentication as a connected system – adaptive 3DS, network tokenization, intelligent routing, and subscription billing with native MIT support.
to map your current setup and identify where improvements would move the needle.
Frequently asked questions
Authentication of payment confirms the payer's identity – verifying they are who they claim to be. Authorization is the issuer's decision to approve or decline the transaction based on account status, available funds, and risk assessment. Authentication typically occurs first; a successful authentication result is one input the issuer uses when making the authorization decision.
There's no universal answer as security depends on the transaction profile. For high-value or elevated-risk transactions, a 3DS2 challenge via banking app provides the strongest protection – OTP or biometric, either triggers a liability shift to the issuer if fraud occurs. For mobile recurring transactions, biometric challenge via 3DS2's mobile SDK is the stronger option: no OTP dependency, no context switch away from the app.
3D payment authentication isn't universally required. In the EEA and UK, SCA is mandatory for customer-initiated payments and 3DS2 is the primary compliance mechanism. Exemptions cover low-value transactions, merchant-initiated recurring charges, and low-risk transactions meeting TRA thresholds. Outside the EEA, India and Japan mandate 3DS for domestic e-commerce; the US has no federal requirement.
Authentication affects conversion at two points. At the challenge step, customers who don't complete verification abandon – every unnecessary challenge is a drop-off that better configuration could prevent. At the authorization step, well-authenticated transactions are more likely to be approved by the issuer. Better 3DS2 data quality and correct SCA exemption application reduce friction at both points simultaneously.
Not every failed authentication is the same situation. Soft failures mean the customer didn't complete the challenge – prompt a retry and present an alternative payment method if it fails again. Hard failures mean the issuer rejected authentication; direct the customer to their bank. Don't retry rejected authentications: excess attempts affect acquirer standing.
Recent articles
