This article covers the relationship between SCA and 3D Secure 2.0, the 3DS2 authentication flow, exemptions, merchant responsibilities, and practical implementation points for online card payments. It provides actionable guidance for card-not-present transactions under European regulatory standards.
For online card payments, merchants need a way to authenticate customers when payment regulations require stronger verification. PSD2 introduced Strong Customer Authentication for certain electronic payments, requiring two independent authentication factors. 3D Secure 2.0 addresses this requirement in the card-payment flow by exchanging transaction data between the merchant, payment provider and card issuer. Depending on the issuer’s assessment, the payment can proceed without a customer challenge or require additional verification.
What is 3D Secure 2.0 and how does it support SCA compliance?
3D Secure 2.0 is a technical protocol used to authenticate cardholders during online payments. It supports SCA compliance by allowing transaction and customer information to reach the card issuer, which can then assess the payment and decide whether additional authentication is required.
SCA is the regulatory requirement. 3D Secure is one technical method that can support that requirement for card payments. Under PSD2, SCA uses at least two independent elements from three categories: knowledge, possession and inherence. A password or PIN can represent knowledge; a phone or other authentication device can represent possession; a fingerprint or facial biometric can represent inherence.
3DS2 also supports a different checkout experience from the older 3D Secure model. A merchant can send detailed transaction information to the issuer before the customer is asked to verify the payment. The issuer can use that information to authenticate the payment without an active challenge. If more verification is required, the issuer can request a challenge.
Q&A: Is 3D Secure the same as SCA?
No. SCA is a regulatory requirement under PSD2, while 3D Secure is a payment authentication protocol that can support compliance with that requirement.
When does a card payment require SCA under PSD2?
SCA applies to certain remote electronic payments initiated by the payer. For ecommerce card payments within the relevant PSD2 scope, the merchant and payment service providers need to determine whether SCA applies or whether the transaction qualifies for an exemption or falls outside the requirement.
The RTS under PSD2 includes several exemptions. A low-value remote payment can qualify when the individual transaction does not exceed €30 and the cumulative value of previous remote payments made without SCA does not exceed €100. The rules also include a transaction risk analysis exemption, with threshold values of €100, €250 and €500 subject to the applicable fraud-rate conditions.
Other payment scenarios have their own treatment. Recurring transactions, merchant-initiated transactions and trusted beneficiaries need to be classified correctly and handled according to the relevant PSD2 rules and scheme requirements.
| Payment scenario | SCA treatment | 3DS2 implication |
| Customer-initiated ecommerce payment | SCA may apply unless an exemption or exclusion is available | Frictionless or challenge authentication may occur |
| Eligible low-value remote payment | Exemption may apply if the applicable limits are met | No customer challenge may be required |
| Recurring payment after the initial setup | Treatment depends on the transaction structure | Correct recurring-payment data must be passed |
| Merchant-initiated transaction | Can have different SCA treatment from a customer-initiated payment | Correct transaction classification is required |
| Eligible TRA transaction | Exemption may apply subject to the relevant conditions | The applicable PSP makes the exemption decision |
A merchant or payment service provider can request an exemption, but a request does not guarantee that the payment will proceed without SCA. The payment service provider responsible for the exemption and the issuer’s authentication decision both matter. For card payments, the payer’s PSP has the final decision on whether to accept or apply an exemption under the EBA’s interpretation of the RTS.
Q&A: Does every online card payment need a 3D Secure challenge?
No. A 3DS2 transaction can use a frictionless flow, and an eligible payment may qualify for an SCA exemption. A challenge is used when the authentication process requires active customer verification.
How does the 3D Secure 2.0 authentication flow work?
A 3DS2 payment starts when the customer submits an online card payment. The merchant or its payment provider sends transaction and payment data through the 3DS infrastructure. The request reaches the card issuer, which assesses the transaction and determines the appropriate authentication path.
The issuer can approve a frictionless flow when the available information is sufficient for its assessment. The customer does not have to complete an active authentication step during checkout.
The issuer can also request a challenge flow. The customer then completes an authentication step specified by the issuer, such as a one-time code or biometric verification.
3DS2 supports browser-based and app-based payment flows. EMVCo’s 3-D Secure specifications define the protocol and the data exchanged between the parties involved in authentication.
| Frictionless flow | Challenge flow | |
| Customer interaction | No active authentication step | Customer completes an authentication step |
| Issuer action | Authenticates the transaction from available data | Requests additional customer verification |
| Checkout | Payment proceeds without a visible challenge | Customer interacts with the authentication screen |
| Common use | Issuer has sufficient information for its assessment | Issuer requires additional verification |
The quality of the data sent with a 3DS2 request matters. Information about the transaction, payment method, device and customer can help the issuer assess the payment. The merchant should pass accurate data supported by its integration and payment provider.
A practical implementation should cover these points:
- Check whether SCA applies to the transaction.
- Identify whether an applicable exemption can be requested.
- Pass the required 3DS2 data accurately.
- Support both frictionless and challenge outcomes.
- Handle the authentication result correctly before authorisation.
The authentication result then feeds into the payment authorisation process. Merchants need to preserve the relevant authentication data required by their payment provider and card scheme.
How can merchants implement 3DS2 without unnecessary checkout friction?
A good 3DS2 implementation starts with the data sent to the issuer. Merchants should provide complete and accurate information about the transaction, customer and device, as this gives the issuer more context for its assessment. Poor or missing data can affect that assessment and may lead to a challenge where additional customer verification is required.
The payment flow also needs to distinguish between different types of transactions. A recurring payment or merchant-initiated transaction can have different SCA treatment from a standard customer-initiated purchase, so the relevant transaction indicators and reference information must be passed correctly. The same applies to exemptions: merchants can request an exemption when the applicable conditions are met, but the request does not guarantee that authentication will be skipped.
The customer experience depends on what happens after the issuer makes its decision. If a frictionless flow is approved, the payment can continue without an active authentication step; if a challenge is required, the checkout needs to present it correctly on desktop and mobile and return the authentication result to the payment flow. Payment teams should track authentication outcomes and authorisation results to identify failures in the integration and address them without adding unnecessary steps to successful payments.
How does Wallester handle 3D Secure and SCA compliance?
Wallester White-Label provides card-issuing infrastructure for businesses that want to launch their own payment card programmes. The platform supports 3D Secure authentication as part of the payment flow, helping card programmes apply an additional layer of cardholder verification to online transactions when required.
With Wallester’s REST API, programme managers can integrate 3D Secure into their own card issuing and payment workflows. This allows businesses to build authentication into the customer experience of their own card programme rather than relying on a separate card management setup.
Wallester White-Label also supports SCA requirements through authentication mechanisms used for applicable electronic payments. The exact authentication flow depends on the transaction and the requirements of the relevant payment environment.
For card issuers, this means 3D Secure and SCA can form part of the broader payment infrastructure alongside card issuing, transaction processing and programme controls.
