Implementing Strong Customer Authentication (SCA) in Payment Flows

SCA Is Not Just a Checkbox

Strong Customer Authentication is the PSD2 requirement that customer-initiated electronic payments must use two-factor authentication. In theory, this is straightforward. In practice, SCA introduces asynchronous flows, soft declines, exemption logic, and UX challenges that require careful implementation.

Getting SCA wrong means either unnecessary friction (declining legitimate customers) or non-compliance (skipping required authentication). Neither is acceptable.

How SCA Works in Practice

The Two-Factor Requirement

Every SCA challenge must use two of three categories:

• Knowledge: PIN, password, security question
• Possession: Mobile phone (SMS/push), hardware token, smart card
• Inherence: Fingerprint, facial recognition, voice pattern

The payment industry has largely converged on possession (banking app push notification) plus inherence (biometric) for the best balance of security and usability.

3D Secure 2 as the SCA Mechanism

For card payments, 3D Secure 2 (3DS2) is the protocol that enables SCA. Unlike its predecessor (3DS1, the dreaded popup window), 3DS2 supports:

• Embedded authentication challenges in your checkout flow
• Frictionless authentication when the issuer determines risk is low
• Mobile SDK integration for native app experiences
• Rich data sharing between merchant and issuer for better risk decisions

Implementation Architecture

Server-Side Flow (Most Common)

1. Collect payment details on your checkout page
2. Create payment with your PSP, providing the required SCA data
3. PSP initiates 3DS2 with the card issuer
4. Issuer evaluates risk and either:
   • Approves frictionlessly (no customer action needed)
   • Requests a challenge (customer must authenticate)
5. If challenged: Customer completes authentication (biometric, OTP, banking app)
6. PSP confirms the payment status via webhook
7. You fulfill the order

Client-Side (Embedded) Flow

Some PSPs support embedding the authentication challenge directly in your checkout page using JavaScript SDKs. This avoids redirecting the customer to an external page:

// Example: embedded 3DS2 challenge
const checkout = PSP.createCheckout({
    sessionId: 'cs_xxx',
    onAuthenticated: (result) => {
        // Submit result to your server
        fetch('/api/payments/confirm', {
            method: 'POST',
            body: JSON.stringify({ authResult: result }),
        });
    },
    onError: (error) => {
        showPaymentError(error.message);
    },
});

The embedded flow provides better UX but requires more frontend work.

SCA Exemptions

Not every payment requires SCA. The regulation defines exemptions that reduce friction for lower-risk transactions:

Low-Value Exemption

Transactions under 30 EUR can be exempted, subject to cumulative limits:

• Maximum 5 consecutive exempt transactions, OR
• Maximum 100 EUR cumulative exempt amount

After either limit is reached, SCA is required regardless of the transaction amount.

Transaction Risk Analysis (TRA)

If the acquirer or issuer maintains fraud rates below defined thresholds, they can exempt transactions based on risk analysis:

Fraud Rate	Exemption Threshold
Below 0.13%	Up to 100 EUR
Below 0.06%	Up to 250 EUR
Below 0.01%	Up to 500 EUR

Your PSP typically manages TRA exemptions. You signal your preference, and the PSP decides whether to request it.

Recurring Payments

After the first authenticated payment, subsequent recurring charges of the same amount to the same payee can be exempted. This covers subscription renewals but not variable-amount charges.

Trusted Beneficiaries

Customers can whitelist trusted merchants with their bank. Payments to whitelisted merchants skip SCA. You cannot control this directly, but awareness helps when debugging why some customers never see SCA challenges.

Merchant-Initiated Transactions (MIT)

Transactions initiated by the merchant without customer involvement (e.g., delayed charges, no-show fees) do not require SCA. However, the initial mandate or agreement must be authenticated.

Handling Soft Declines

When an issuer requires SCA but the transaction was submitted without it, the result is a soft decline. Your system must handle this gracefully:

public function handlePaymentResult(PaymentResult $result): void
{
    if ($result->isSoftDecline()) {
        // Redirect customer to SCA challenge
        return redirect($result->getAuthenticationUrl());
    }

    if ($result->isHardDecline()) {
        // Payment definitively rejected
        return $this->showDeclineMessage($result);
    }

    if ($result->isPending()) {
        // Awaiting async confirmation
        return $this->showPendingMessage();
    }
}

Track soft decline rates. A high soft decline rate indicates you are not requesting SCA or exemptions correctly. Most PSPs provide this metric in their dashboard.

UX Considerations

SCA adds friction to checkout. Minimize its impact:

• Set expectations. Tell customers they may need to verify their identity with their bank. Unexpected redirects cause abandonment.
• Optimize for frictionless flow. Provide as much data as possible in the payment request (billing address, email, device fingerprint). More data helps issuers approve frictionless authentication.
• Handle timeouts. SCA challenges expire. If the customer does not complete authentication within the timeout window (typically 5-15 minutes), display a clear message with an option to retry.
• Mobile optimization. Ensure your checkout flow works when the banking app opens over your app. Deep linking and app switching must be seamless.

Testing SCA

Test all authentication outcomes:

• Frictionless approval (no challenge presented)
• Challenge presented and completed successfully
• Challenge presented and failed
• Challenge timeout/abandonment
• Soft decline and retry flow
• Each exemption type (if you request them)

Most PSP sandbox environments provide test card numbers that trigger specific SCA outcomes.

SCA is a mandatory part of European payment processing. Implement it as a first-class concern in your payment flow, not an afterthought. Use exemptions to reduce friction where appropriate, handle soft declines gracefully, and test every authentication path thoroughly.