Strong customer authentication (SCA): Ecommerce business guide

What is strong customer authentication?

Strong Customer Authentication (SCA) is a security requirement under PSD2 that strengthens how customers are authenticated for certain electronic payments.

Instead of relying on a single credential, SCA requires authentication using at least two independent factors from three categories:

For example, a customer could authenticate a payment using a password and a fingerprint, or a trusted device and a PIN.

The two factors must come from different categories. A password and a security question are both “knowledge”, so together they do not count as two SCA factors.

But SCA doesn’t stop at verifying the customer’s identity; for certain transactions, the authentication must also be tied to the specific payment being authorized.

What is dynamic linking in SCA?

For certain remote electronic payment transactions, SCA also requires the authentication process to be dynamically linked to the specific transaction being authorized.

This means the authentication should be tied to key transaction details, such as the amount and payee, so that an attacker cannot use a valid authentication event to authorize a different transaction.

For example, if a customer is authorizing a $100 payment to a particular merchant, the authentication mechanism should be linked to that transaction rather than simply confirming that the customer has authenticated successfully.

Dynamic linking defeats attacks that alter the amount or payee between the customer and the payment service provider.

Regulatory note: Strong Customer Authentication (SCA) is primarily associated with the PSD2 requirements applicable to payment service providers in the European Economic Area.

The UK has a separate SCA framework under its own payment-services regulations. If your business operates outside these regions, SCA may not directly apply, although its authentication and risk-based principles remain relevant to payment security.

The EU framework is also being revised through the Payment Services Regulation (PSR) and the Third Payment Services Directive (PSD3).

How does strong customer authentication work?

The basic SCA process can look like this:

1. A customer initiates an online payment.
2. The payment request is evaluated to determine whether SCA is required.
3. If authentication is required, the customer provides two independent authentication factors.
4. The issuing bank or authentication provider validates those factors.
5. The authentication result is returned to the payment flow.
6. The transaction proceeds to authorization or is declined.

For ecommerce merchants, the payment provider, card issuer, and authentication infrastructure handle much of this process rather than the merchant directly. This is where 3D Secure 2 (3DS2) becomes important.

What is the role of 3D Secure 2 in SCA?

3D Secure 2 is one of the primary technologies used to authenticate customers during online card payments and support SCA requirements.

A simplified 3DS2 flow looks like this:

One of the major improvements in 3DS2 is that authentication does not necessarily mean displaying an OTP or password challenge to every customer.

Instead, the issuer can evaluate transaction information to determine whether the payment appears low- or high-risk.

A low-risk transaction may be authenticated without requiring an additional customer challenge, while a higher-risk transaction may trigger an authentication step.

That answers the main ecommerce objection to SCA: how to add security without putting a challenge in front of every checkout.

What is a soft decline?

A soft decline occurs when an issuer declines a transaction because additional authentication is required before it can be approved.

This can happen when a merchant or acquirer processes a payment without SCA, including when an SCA exemption such as Transaction Risk Analysis (TRA) is requested. The issuer may still decide that authentication is necessary.

A soft decline does not necessarily mean a lost sale. If the payment flow supports it, the payment platform can detect the response and trigger 3DS2 authentication.

The customer then completes SCA, and the payment is resubmitted for authorization.

Handling soft declines correctly helps prevent transactions that could succeed after authentication from appearing as simple payment failures.

Is strong customer authentication required for every ecommerce payment?

No. SCA applies to certain electronic payments within the relevant regulatory scope, but not every payment automatically requires a customer challenge. There are exemptions and transaction scenarios that can affect whether SCA is required.

The exact applicability can depend on factors such as:

• Where the merchant is located
• Where the customer’s payment account is located
• The type of transaction
• Transaction value
• Whether the payment is recurring
• Whether the customer has established a trusted beneficiary
• The transaction’s fraud risk
• Whether an applicable exemption is available

So do not implement SCA as a rule of “always challenge”. Make it one input to the payment decision.

Common SCA exemptions ecommerce businesses should understand

Exemptions let merchants skip the challenge where the rules allow it.

Common categories include:

Low-value transactions

Certain low-value payments may qualify for an exemption, subject to applicable limits and conditions.

For businesses with a high volume of small orders this matters: a challenge on every low-value purchase adds friction out of proportion to the risk.

Transaction risk analysis

A transaction can qualify for a risk-based exemption when it meets the applicable conditions and the payment provider or issuer judges it to fall under the fraud-risk threshold.

This is where fraud detection and authentication meet.

The better the risk evaluation, the better the call on when a challenge is needed.

Note: TRA can be claimed by the issuer or by the acquirer/payment provider, depending on the payment flow, and whichever party claims the exemption also assumes the liability if the transaction later turns out to be fraudulent.

Recurring transactions

Certain recurring or subscription payments can receive different treatment depending on the transaction pattern and applicable requirements.

For subscription businesses, it is important to distinguish between:

• The initial customer-initiated payment
• Subsequent recurring payments
• Changes to payment details
• New payment instruments

Treat them all the same and you get needless challenges or failed renewals.

Trusted beneficiaries

Customers may be able to designate certain merchants or beneficiaries as trusted, subject to the applicable rules and issuer capabilities.

That removes the challenge from repeat payments without stepping outside the rules.

Important: Exemptions are not switches a merchant flips. Whether one applies depends on the payment flow, the regulation, the payment provider, the issuer and the transaction. Ask your payment provider which exemptions you can request and how they handle the decision.

SCA vs. 3D Secure: What is the difference?

SCA and 3D Secure are related, but they are not the same thing. SCA is a regulatory authentication requirement.

3D Secure is a payment authentication protocol used to authenticate online card payments. The table below sets the two side by side.

The distinction matters because “having 3D Secure” does not mean every transaction gets the same authentication experience.

What SCA means for ecommerce fraud prevention

SCA makes unauthorized payment fraud harder. It is not a complete fraud prevention solution.

Authentication answers an important question: Can this customer be authenticated?

Fraud detection asks a broader question: Does this transaction look legitimate?

Those are not always the same thing.

A legitimate customer’s credentials can be compromised. A fraudster may also gain control of a legitimate account, device, email address, or authentication method.

So a transaction can pass authentication and still be fraud.

For example, consider an account takeover scenario:

1. A fraudster gains access to a customer’s ecommerce account.
2. The account contains a saved payment method.
3. The fraudster changes account or delivery information.
4. A transaction is initiated.
5. Authentication is successfully completed.
6. The order is shipped to a location controlled by the fraudster.

The authentication event on its own says nothing about the address change or the new device. Merchants need the wider fraud signals alongside it.

How SCA and risk-based authentication work together

Risk-based authentication decides how much security each transaction gets.

Merchants assess the customer’s device, location, transaction history and behavior, and the resulting risk assessment decides whether the transaction goes through a frictionless flow, qualifies for an exemption, or needs a challenge.

Low-risk transaction

A returning customer:

• Uses a recognized device
• Logs in from a consistent location
• Uses a trusted payment method
• Has a positive transaction history
• Places a typical-value order

A transaction with these signals may be suitable for a frictionless 3DS flow or, where applicable, an SCA exemption.

Medium-risk transaction

A transaction may require more scrutiny when the customer:

• Uses a new or unfamiliar device
• Changes their shipping address
• Makes a purchase that is significantly larger than usual

The merchant or issuer may require additional authentication or verification before approving the payment.

High-risk transaction

A transaction may be considered high risk when it shows signals such as:

• Suspicious device activity
• Unusual IP behavior
• High transaction velocity
• Multiple failed authentication attempts
• Account changes shortly before checkout
• Previous associations with fraud

These transactions may require stronger controls, additional authentication, or rejection.

The goal is not to add authentication to every transaction. It is to apply stronger security when the risk justifies it while keeping low-risk payments as frictionless as possible.

Keeping the checkout from leaking customers

Additional authentication can improve security, but every extra step can also increase the chance that a customer abandons checkout.

Customers may:

• Fail to receive an OTP
• Enter an incorrect authentication code
• Lose access to their authentication device
• Get confused by a bank’s authentication page
• Abandon checkout because authentication takes too long
• Face an authentication failure despite being legitimate

Track authentication performance next to fraud and conversion metrics.

A setup that cuts fraud but lifts checkout abandonment can still lose money. The target is the balance between security, authentication success and customer experience.

What ecommerce businesses should measure

Do not measure SCA by the number of transactions authenticated. Watch the whole payment funnel.

The metrics that matter

1. Authentication rate: How many transactions enter an authentication flow?
2. Challenge rate: How often are customers challenged? A high challenge rate can indicate unnecessary friction in the payment ecosystem.
3. Authentication success rate: How many customers complete authentication?
4. Authentication failure rate: How many transactions fail during authentication?
5. Checkout abandonment: How many customers leave after being presented with an authentication challenge?
6. Fraud rate: How much fraud occurs among authenticated and non-authenticated transactions?
7. False-positive rate: How many legitimate customers are unnecessarily challenged, declined, or blocked?
8. Conversion rate: How does authentication affect completed purchases?
9. Chargeback rate: Are successfully authenticated transactions still generating chargebacks or disputes?

Read together, these show whether the authentication strategy is working.

How ecommerce businesses can build a stronger SCA strategy

1. Map your payment flows

Start by identifying:

• Where your customers are located
• Where your business is located
• Which payment methods you support
• Which payment providers you use
• Which transactions may fall within SCA requirements
• Which exemptions are available to your payment flows

That shows the risk and payment teams where authentication has to happen.

2. Use 3DS2 where appropriate

Work with your payment provider to confirm your checkout supports the right 3D Secure implementation.

The goal is not to challenge every transaction. Use the frictionless flow where the risk allows it and the challenge where it does not.

3. Evaluate exemption opportunities

Understand which exemptions your payment provider supports and when they can be requested.

Monitor how frequently exemptions are:

• Requested
• Accepted
• Rejected
• Followed by fraud
• Followed by legitimate transactions

Those numbers tell you which exemptions are worth requesting.

4. Add risk signals beyond authentication

Authentication should be combined with broader fraud signals such as:

• Device intelligence
• IP intelligence
• Behavioral analytics
• Account history
• Transaction velocity
• Payment history
• Geographic signals

These catch the cases where the fraudster can authenticate.

5. Monitor authentication and conversion together

Do not tune authentication on its own. A lower fraud rate is worth having; so is a healthy conversion rate. Balance security, compliance and conversion together.

Common mistakes businesses make with SCA

Five mistakes come up again and again.

Assuming SCA means every transaction requires an OTP

SCA does not mean every customer types an OTP. Authentication can use different factors and flows, and exemptions may apply.

Treating 3D Secure as a complete fraud solution

3DS2 authenticates the payment. It does not replace fraud detection, and merchants still need to see devices, accounts, behavior and transaction patterns.

Ignoring false positives

A real customer who keeps getting challenged eventually gives up. Measure that friction alongside fraud reduction.

Applying the same rules to every customer

A first-time customer making an unusually large purchase is a different risk from a long-term customer on a familiar device and payment method. The decision should reflect that.

Focusing only on payment authentication

Fraud happens before and after the payment. Account takeover, fake account creation, promotion abuse, refund fraud and suspicious delivery behavior are not solved by payment authentication.

A more effective ecommerce payment security model

Think of payment security as layers, each answering one question.

Account layer: Is the account behaving normally?

Device layer: Is this a trusted device?

Network layer: Does the IP or network present risk?

Transaction layer: Is the purchase consistent with historical behavior?

Authentication layer: Can the customer successfully prove their identity?

Decision layer: Should the transaction be approved, challenged, reviewed, or declined?

Post-transaction layer: Does activity after payment indicate fraud?

That is more resilient than a single authentication event.

Where to start

SCA is a solid layer, and it was never meant to catch everything. A fraudster who holds the account or the device sails through authentication, which is why the strongest setups pair SCA and 3DS2 with device intelligence, behavioral analysis, transaction monitoring and real-time risk scoring.

The goal is not more checks. It is the right check on the right transaction, so risky payments stop and real customers do not notice.

Sensfrx scores each payment from device, network, behavior and transaction signals in real time, and your rules turn the score into allow, review or block before the chargeback lands. Plans start free.

Frequently asked questions (FAQs)