Strong Customer Authentication (SCA)

Learn what Strong Customer Authentication (SCA) is and how it works.

Overview

Strong Customer Authentication (SCA) is an Unzer feature that allows merchants to decouple cardholder authentication from payment authorization.

It uses the EMV 3DS 2.x authentication protocol to authenticate the cardholder without immediately authorizing or charging the card. The authentication result is stored and returned as a unique SCA reference (Payment ID), which can later be used to link exactly one authorization or charge when goods or services are ready to be fulfilled.

This approach is PSD2-compliant and is designed for delayed-fulfillment use cases such as:

• Pre-orders and backorders
• Delayed shipment or custom manufacturing
• Services fulfilled at a later date

By authenticating upfront and authorizing later, SCA reduces customer friction while maintaining regulatory compliance and operational flexibility.

Benefits for Merchants

Regulatory compliance

• Meets PSD2 SCA requirements without forcing immediate authorization

Reduced checkout friction

• Customers authenticate only once
• No need to re-authenticate later when goods ship

Higher conversion & flexibility

• Ideal for delayed fulfillment use cases
• Enables authorization only when goods or services are ready

Merchant Responsibilities

Merchants are responsible for:

• Registering the card before initiating SCA
• Initiating authentication using the SCA API
• Securely storing the returned paymentId (SCA reference)
• Using the same paymentId for exactly one subsequent authorization or charge
• Ensuring the authorization occurs within the allowed 90-day linkage window

Rules & Constraints

• Each SCA reference (paymentId) can be linked to only one authorization or charge
• Reuse of an SCA reference will result in a decline (single-use CAVV)
• Authorization must be completed within 90 days of successful authentication
• SCA authentication does not reserve funds

End-to-End Flow & API Reference

Step 1: Card Registration

Before initiating SCA, the card must be registered.

Endpoint

Endpoint

Copy

POST https://api.unzer.com/v1/types/card

Purpose

• Registers the card
• Returns a typeId
• The typeId is mandatory for initiating SCA

Step 2: Initiate SCA (Authentication-Only)

Endpoint

Endpoint

Copy

POST https://api.unzer.com/v1/payments/sca

Purpose

• Performs EMV 3DS authentication
• Does not create authorization or charge
• Persists 3DS artifacts (ECI, CAVV, protocol version, DS/ACS IDs, status, timestamp)
• Returns a unique SCA reference (paymentId)

Result

• Cardholder is authenticated
• Merchant stores the paymentId for later use

Step 3: (Optional) Retrieve SCA Details

Endpoint

Endpoint

Copy

GET https://api.unzer.com/v1/payments/{paymentId}/sca/{scaId}

Purpose

• Retrieves SCA status and metadata
• Does not expose raw 3DS authentication data

Step 4: Authorization Linked to Prior SCA

Performed when goods or services are ready.

Endpoint

Endpoint

Copy

POST https://api.unzer.com/v1/payments/{paymentId}/sca/authorize

Rules

• Uses stored SCA authentication data
• Consumes the SCA reference
• Only one authorization or charge is allowed per SCA

Step 5: Charge Linked to Prior SCA (Alternative)

Endpoint

Endpoint

Copy

POST https://api.unzer.com/v1/payments/{paymentId}/sca/charges

Purpose

• Performs authorization and capture in one step
• Uses stored SCA data
• No new SCA is triggered

Sequence Diagrams

Sequence Diagram: Card Registration & SCA (Authentication)

Sequence Diagram: Authorization Linked to SCA

FAQ

Can SCA be used for card-on-file payments?

Yes. SCA can be performed during the initial card-on-file setup transaction. Subsequent merchant-initiated transactions may not require SCA if properly flagged and compliant with scheme rules.

Can SCA be used for recurring transactions?

Yes. SCA can be used for recurring transactions, provided the initial transaction is properly authenticated.

Important Considerations

• The initial transaction must clearly indicate that it is setting up a recurring payment.
• Subsequent transactions must be flagged correctly as recurring / MIT.
• If the amount or agreement changes significantly, re-authentication may be required.
• Issuers retain the right to request SCA again in certain cases.

What happens if the authorization amount differs from the authenticated amount?

Changes in the amount may require a new SCA authentication and could result in a decline.

Merchants should authenticate the expected final amount whenever possible.

Can I partially capture after SCA + authorization?

Yes. If you perform an authorization linked to SCA, you may perform partial captures according to standard authorization rules.

However, the SCA reference itself can only be used once for authorization.

Can I split one SCA reference across multiple authorizations?

No. Each SCA reference (paymentId) is strictly single-use and can be linked to only one authorization or charge. Attempting reuse will result in a decline.

What happens if authorization fails after successful SCA?

If authorization is declined:

• The SCA reference is considered consumed.
• A new SCA authentication must be performed before retrying.

Authentication success does not guarantee authorization approval.

Can issuers still request SCA during authorization?

Yes. Although prior SCA has been performed, issuers always retain the right to require additional authentication under risk-based decisioning.

Can I cancel an SCA authentication?

No. Once authentication is completed, it cannot be canceled. If unused within the 90-day window, it expires automatically.