3D Secure Use Cases

Authentication with Payment

An authentication with payment is the most common scenario of using a 3DS 2.0 authentication and the corresponding SCA. In this case the customer places an e-commerce order and the authentication will be initiated in the same session as the actual payment transaction.

For such scenarios the payment authorization is always a cardholder initiated transaction (CIT).

Once the card transaction is triggered the customer will be sent into the authentication (frictionless or challenge flow) and afterwards the results of the authentication will directly be used for the payment transaction which could be an authorization or a debit.

The payment transaction could be a simple onetime purchase or could be the initial transaction using one of the credential-on-file use cases (oneclick, recurring unscheduled, recurring scheduled).

Authentication without Payment

An authentication without a payment can be used in case a merchant wants to store the card credentials of a customer for future payment transactions, but no payment transaction should be initiated at this time.

A typical use case could be the merchant account creation for a subscription model (recurrring). A merchant can already authenticate the cardholder at the time the card credentials are stored.

If such authentication is combined with a card-check (a zero amount authorization) the card check can be referenced as the initial transaction of a recurring model.

The first actual payment transaction can then be initiated as a merchant initiated transaction (MIT) without any further 3DS authentication required. Only the initial authorization from the card check has to be referenced, which could automatically be done by the Payengine if the merchant integrates the credential-on-file feature.

Authentication via Agent

In an agent model an agent is selling another merchant's products or services. Within a checkout a customer could just purchase products or services from one merchant but also from multiple at once. A typical example would be an online travel agency where the customer orders a flight combined with a rental car, both services from different providers.

In such model the agent (e.g. the travel agency) will trigger the authentication for the full purchase and forward the results to the various merchants that will then initiate the actual payment transactions referencing the authentication done by the agent.

Merchant with Nets/Concardis

In this case the merchant has a card acquiring agreement with Nets/Concardis and the payments will be processed via the Payengine but the authentication triggered by the Agent has been initiated trough a different acquirer/PSP.

In order to authorize or debit the payment according to the PSDII the Payengine needs the 3DS authentication results as an additional input and pass it to the issuer and schemes.

When you initiate an authorization or debit the following parameters have to be provided:

Agent with Nets/Concardis

In this case the the agent has an agreement with Concardis for pure 3DS authentication but the actual payment transactions by the merchant will be processed through a different acquirer/PSP, but not the Payengine.

This means the agent just initiates the 3DS authentication and forwards the results to the merchant(s).

In order to execute a 3DS authentication the agent can use one of the supported Payengine integration types. More details about the 3DS integration types can be found here.

The following parameters for a successful 3DS authentication will be returned and have to be forwarded by the agent:

Authentication for Recurring Payments

The initial transaction of recurring payments (scheduled or unscheduled) always requires a strong customer authentication (SCA). This means that a 3DS authentication has to be initiated where a challenge from the issuer to the cardholder will be mandatory.

No frictionless flow will be supported for the authentication of initial recurring transactions.