3DS FAQs

Frequently asked questions around EMV 3DS.

Access Control Server

What is an ACS?

Access Control Server. This server is responsible for managing card issuer processes in the 3DS protocol. The ACS provides insight into what features of the 3DS program a card supports (such as device fingerprinting), the 3DS versions supported, providing rails for device fingerprinting and challenge handling, and finally interfacing with a card issuer's information about a cardholder to influence authentication decisioning.

Some card issuers manage their own ACS, others contract with an ACS operator.

How can I contact an ACS operator to let them know of an issue with their systems?

There are two ways a merchant can identify an ACS operator: the SupportedVersions response threeDSecureResponse.threeDSMethodURL and the Authentications response threeDSecureResponse.acsReferenceNumber.

The threeDSMethodURL often has indicators that can identify the responsible party. For example, the domain https://secure5.arcot.com contains the term "arcot" which can be used in a web search such as "3DS arcot ACS". The results point to a 3DS ACS product by Broadcom.

The acsReferenceNumber provides a more structured identification route via an EMV hosted lookup. An example value, 3DS_LOA_ACS_CATE_020200_00212 can be searched and an informational EMVCo Letter of Approval can be viewed.

Finally, we're partnered with Mastercard and they have hosted a Mastercard Identity Check vendor list. Keywords obtained from the methods above can be searched to identify an operator and find their contact email. If attempts to contact an ACS are unsuccessful through the above means, we may be able to identify alternative contacts for that ACS.

See this post for more information on identifying an ACS.

I'm having trouble with challenges in the Production environment.

Please create a ticket with our Support team so that we can research the issue. We will do our best to identify a resolution, though there are many parties at play in the 3DS program - organized under the EMV 3DS program specification - and making contact with the parties responsible for a certain piece of the process can be challenging.

Challenge presentation to the presumed cardholder, the presumed cardholder's interaction with a challenge, and challenge completion notifications are not areas that our systems have visibility into within the 3DS program. The parties that are best equipped to troubleshoot these issues are the merchant, the card issuer's ACS operator, and the presumed cardholder themselves.

An ACS operator can be identified, though establishing contact with the operator is not guaranteed as emails often wind up in other organization's spam folders, are rejected by corporate policies, or just go unanswered.

The most immediate solution for resolving issues related to a challenge is to identify an alternative payment method that the affected cardholder can utilize.

In the Production environment, challenge results returns an errorDetail of threeDSServerTransID challenge in progress and polling the challenge results later returns a transStatus of N and transStatusReason of 14.

This situation occurs when the 3DS challenge flow is interrupted, such as by the browser being closed prior to the challenge being completed by the cardholder in question. If the challenge has been in progress for 10 minutes, the ACS ends processing and returns a transStatus of N and transStatusReason of 14.

As a merchant, the recommendation is to stop processing of the action. When the attempted action is a payment authentication, don't proceed with the authorization. For a non-payment authentication, don't complete the attempted action.

Chargebacks

A transaction was successfully authenticated with liability shift to the issuer. Why did I get a chargeback?

3DS authenticated transactions are protected from unauthorized use chargeback claims. A successfully authenticated transaction that gets a chargeback for reasons that don't fall under the 'unauthorized use' category do not qualify for liability shift.

While rare, properly authenticated transactions can be subject to unauthorized use reason code chargebacks. Normally, an unauthorized use transaction chargeback that was successfully 3DS authenticated would automatically be rejected, but that is only if the 3DS authentication results were properly passed in the payment authorization to the PSP who in turn properly passed them on for processing. There are many parties at play within the 3DS program and it's possible one of them is at fault for not passing the proper information along to the next party in line.

Chargebacks falling into this unusual situation can still be disputed, though it's crucial to demonstrate during the dispute that the 3DS authentication was successful and liability shift occurred.

Testing

Can I add PSP-specific test cards for end-to-end testing of 3DS with my PSP?

In general, no. Each of the test scenarios is associated with a static card number specific to that test scenario. At present, there is no capability for the addition of PSP-specific 3DS test cards to these testing scenarios.

Some PSPs, such as Adyen, offer the flexibility of adding custom test cards to facilitate end-to-end testing between providers. When the PSP provides this flexibility, the recommendation is to utilize it by adding the respective test case's card number and authentication results which will then enable end-to-end testing.

When a PSP does not allow the addition of customer test cards, please see How can I do end-to-end testing of 3DS between providers' sandboxes?

How can I do end-to-end testing of 3DS between providers' sandboxes?

Data-sharing between providers' sandboxes to replicate the EMV 3DS infrastructure for end-to-end testing is not widely supported, if at all.

Payment gateways generally handle testing 3DS-authenticated transaction flows one of two ways when the authentication results are generated by an external provider:

1. The gateway uses specific test cards to align with specific scenarios.
2. The gateway accepts filler 3DS authentication data in the authorization.

The first option is the least flexible and requires either the 3DS provider or the Payment Gateway to accept the others' test cards. See Can I add PSP-specific test cards for end-to-end testing of 3DS with my PSP? When it's not feasible for either the 3DS provider or the Payment Gateway to accept the others' test cards, unfortunately - there is not a clean way to perform end-to-end testing between the 3DS provider and the Payment Gateway.

The second option allows the simulated 3DS authentication data generated by these test scenarios to be accepted by the payment gateway, provided that the payment gateway's sandbox does not attempt validation of the authentication values.

When there is no support for either of the two options above, there are two routes that can be implemented with tradeoffs.

• End-to-end test the 3DS authentication by using the respective test card for the desired scenario and then transmitting the authentication values within the payment authorization knowing that the Payment Gateway either won't accept the test card, the authentication values or both. The end-to-end tests should assert the rejection behavior demonstrated by the Payment Gateway's API. While not a traditional success assertion, the desired behavior of ensuring the authentication results made it to the Payment Gateway via the payment authorization is being validated.
• Within the respective sandbox environments, separate the testing of 3DS from the testing of the payment authorization. Using this approach, each component can be tested thoroughly with proper assertions, though the trade-off is that there are no assertions around the integration of the components.

The best way to perform end-to-end testing of 3DS with your Payment Gateway is in production, where the EMV 3DS infrastructure is in place between all involved parties.

How can I do end-to-end testing of 3DS between providers in Production?

Our recommendation is to use Netcetera's ACS simulator. Once provided access to the Production environment, Netcetera's test scenarios (found in Merchant Test Result Matrix from the previous link) can be utilized with the payment gateway of your choice, also in Live or Production mode.

To get started with Netcetera for the purposes of 3DS testing, follow the guidance in the How to Register section contained within the first link of this section. The MerchantId and AcquirerBin used in the registration must be obtained from the payment gateway with which you'll be testing 3DS.