Strong Customer Authentication

From January 1st 2021, all payments where both the Issuer and the Merchant are in the European Economic Area, will need to authenticate the cardholder. The only exception is Secured by Nets, which deadline is March 31st 2020.

The SCA requires a cardholder to be authenticated with at least two of the following factors:

Factor	Example
Something the customer knows	Pin, password, etc.
Something the customer is	Fingerprint, face recognition, voice recording, etc.
Something the customer has	Credit card, phone, etc.

3DSecure v1

Redirect Page

Once the issuer is identified, the customer is redirected to the ACS in order to authenticate. At testgateway.altapaysecure.com, the customer is redirected to an AltaPay Fake ACS.

3DSecure v2

iFrame

Once the issuer is identified, an iFrame is rendered in the payment form, that loads the authentication from the ACS. At testgateway.altapaysecure.com, the customer is presented with the following iFrame with an AltaPay Fake ACS behind the scenes.

Method flow

The 3DS Method can be optionally used by issuers to gather browser fingerprints using JavaScript.
If the method url exists, the time to redirect the user to the authentication will be slightly longer. This does not affect the integration.

Frictionless flow

3DS authenticates user without any challenge

Challenge / Decoupled

3DS requires user to authenticate.
For challenge flow user will authenticate in the browser through the iframe. In the case of decoupled flow authentication happens outside the browser window.
The integration will be the same for both cases.

agreement[unscheduled_type]=charge

agreement[unscheduled_type]=<other than charge>

No authentication is required, and as such no redirect response is returned.

Exemptions

In the same way that there was a terminal configuration for defining how 3DSecure v1 is being used, there will be another terminal configuration setting for defining how 3DSecure v2 will be used:

3dsecure_exemption	Description	Liability Shift
disabled	No exemptions will be applied, all 3DSecure v2 eligible cards will use the protocol.	Issuer when 3DSecure v2 is performed or the issuer has decided that is not required.
fallback	Whenever 3DSecure v1 is available, it will be used instead. The parameter 3DSecure Mode will be used to define the strategy for 3DSecure v1. There might be some fees associated with the exemption, please get in contact with Support to get more information.	Issuer when covered by 3DSecure v1. Merchant otherwise.
enabled	We will flag the transaction as being exempted towards the acquirer if: The amount is EUR 30 or less. The transaction is considered low-risk. There is a chance that the transaction will be soft-declined, and as such you might get a RedirectResponse for the user to be authenticated. There might be some fees associated with the exemption, please get in contact with Support to get more information.	Merchant when exemption flag is used. Issuer/Acquirer otherwise (see disabled).

3dsecure_exemption

Description

Liability Shift

disabled

No exemptions will be applied, all 3DSecure v2 eligible cards will use the protocol.

Issuer when 3DSecure v2 is performed or the issuer has decided that is not required.

fallback

Whenever 3DSecure v1 is available, it will be used instead.

The parameter 3DSecure Mode will be used to define the strategy for 3DSecure v1.

There might be some fees associated with the exemption, please get in contact with Support to get more information.

Issuer when covered by 3DSecure v1.

Merchant otherwise.

enabled

We will flag the transaction as being exempted towards the acquirer if:

The amount is EUR 30 or less.
The transaction is considered low-risk.

There is a chance that the transaction will be soft-declined, and as such you might get a RedirectResponse for the user to be authenticated.

There might be some fees associated with the exemption, please get in contact with Support to get more information.

Merchant when exemption flag is used.

Issuer/Acquirer otherwise (see disabled).

Exempted flow without soft declined:

Exempted flow with soft declined and fall back to 3DS v2:

Exempted flow with soft declined and fall back to 3DS v1:

Out of Scope

Any transactions in which either the Issuer or the Merchant is not operating in Europe.

MOTO

Mail Order or Telephone Order transactions do not require SCA, but they won’t benefit from the Liability shift on the Issuer, neither can be used for Credential on File.

Subscriptions that were setup with MOTO will be declined moving on.

FAQ

How is my integration being impacted by SCA and 3DSecure v2?

iFrame instead of Redirect

Once you redirect the customer to AltaPay’s payment page (/requestForm), everything is being taken care of by AltaPay’s Gateway.

Bear in mind that in the old flow the user was being redirected to the ACS, whereas now an iFrame will be displayed in the payment form.

You need to make sure that the CSS / HTML layout defined in your callback_form is compatible with it.

There will be new cases that you can use in order to trigger the flow; see Credit card payments

Please get in contact with our support team if you are using DynamicJavascriptUrl; see /createPaymentRequest.

CIT and Authentication

In the cases where the payment being issued is agreement[unscheduled_type]=charge, meaning is a customer initiated transaction, an authentication might be required, and as such you need to be ready to support the Redirect Response.