Best practices when processing EMV 3DSecure and 1.0.2 Sunset information.
Information to help ensure that transactions are processed through EMV 3DSecure and help prevent downgrades or failures.
KA-04074
36
07/11/2024 20:59 PM
2.0
Contents
Best Practices to avoid downgrades and failures when submitting transactions through EMV 3DSecure
3D Secure 1.0.2 Sunset Details
EMV 3DSecure Best practices
Billing/Shipping Information
Ensure that the card holder address information is being passed for EMV 3DSecure, as this information with the additional device data may be used as part of the Issuers risk analysis. Additionally common issues relating to the state field is detailed below:
State Field
- The BillTo_state field within the PayerAuthenication service requests need to follow the ISO 3166-2 format per the EMV® 3DS specification
- Due to known downstream format validation, it is recommended the BillTo_state value be provided in upper case capitalization, if the value contains alpha characters i.e. OH instead of oh.
- Based on the ISO Change history of country code for CN (China) on 2017-11-23 the specification was modified to move all subdivision codes for CN from numeric to alpha. The numeric values are still accepted by downstream providers and should still be considered valid on the authentication message.
Ensuring Device Data Collection (DDC) is processed.
Data collection needs to be completed before a merchant can initiate the Payer Authentication Enrollment request. There are several instances where this can occur:
- Device Channel not present
- Partial browser fields collected on DDC
- Merchant did not run DDC
What to do:
- Ensure you are running Device Data Collection.
- Proceed with Lookup Request after Ensuring the Device Data Collection completes.
- Make sure you are sending the correct Reference ID from the PA Setup to the PA Enrollment request
API | PA Setup - Reply Message | PA Enrollment - Request Field |
Simple Order API / SOAP API | payerAuthSetupReply_referenceID | payerAuthEnrollService_referenceID |
Rest API | consumerAuthenticationInformation.referenceId | consumerAuthenticationInformation.referenceId |
SCMP API | pa_setup_pa_reference_id | pa_reference_id |
What if I do not want to run the Data Device Collection URL?
Ensure that you are passing the required 11 Data Fields to ensure authentication is processed as an EMV 3DS transaction.
- Note that at this time the Method URL request is triggered from the DDC URL request and if this is not processed then the additional information collected by the issuer which would lead to possible increase in Step-up challenge request on the Payer Authentication enrollment request.
- If you need additional information, please reference our Data Device Collection page
Organzation ID not using a Cardinal Cruise integration for Payer Authentication
As EMV 3DSecure is not support by the previous Legacy integrations, ensure all integration are setup to use a Cardinal Cruise integration, for further information please review our Developer Guides.
Payer Authentication REST API Developer GuidePayer Authentication Simple Order API Developer Guide
For Secure Acceptance Merchant, once EMV 3DSecure has been set-up on the Organization ID and the credentials have been added to the EBC, Secure Acceptance will automatically start using a support method to allow EMV 3DSecure transactions.
Rules downgraded the transaction to 1.0
In some cases, custom rules had been requested by merchants to downgrade authentication based on certain scenario’s, these will no longer be applicable and should be removed prior to the sunset of 3DSecure 1.0
Resolution
Reach out to support through your regular channels to request these to be removed.
Common Errors During Authentication
Receiving an error "Transaction Lookup Not Successful, Check Transaction Id" at the Authentication window.
Resolution
Ensure you are using the correct Cardinal Cruise Credentials for the Organization ID you are processing. You can verify your Credentials from the Business Center for the correct environment.
The Sunset of 3DS 1.0 - October, 2022
Sunset Extensions
Network | Sunset Date | Countries w/Extensions |
Visa Secure | October 15, 2022 | India, Sri Lanka, Bangladesh, Nepal, Maldives, and Bhutan |
Mastercard | October 18,2022 | India and Bangladesh |
American Express SafeKey | October 14, 2022 | India |
Discover ProtectBuy | October 14, 2022 | |
JCB J/Secure | October 18, 2022 |
Visa will continue to support 3DS 1.0 transaction processing in India, Sri Lanka, Bangladesh, Nepal, Maldives, Bhutan, solely for domestic transactions until October 12, 2023.
American Express has extended support for India domestic transactions until 12th October 2023.
Mastercard has extended the sunset of 3DS 1.0 for India and Bangladesh through October 3, 2023.
- Any transactions sent to the 3DS 1.0 Directory Server after this date will result in an error.
- October 3, 2023 3DS 1.0 Directory Server will stop routing verify enrollment requests (VEReqs). The 3DS 1.0 Directory Server will respond with a transaction status of N for all verify enrollment responses (VERes).
- November 1, 2023 The Mastercard firewall will respond to VEReqs with a site not found error, as the 3DS 1.0 Directory Server URL will no longer be available
With 3DS 1.0 being extended in some countries, what response values could be returned for intra region versus cross-border transactions?
Intra region transactions are those transactions that are acquired and issued within the same country. If there is an extension, then those transactions must be acquired and issued within the country that has the extension.
- If an extension has been given, then intra region transactions can process through EMV 3DS and 3DS 1.0. Cross border transaction will only be allowed to process through EMV 3DS.
- In an event where cross border transactions are routed through 3DS 1.0, those transactions will result in an unauthenticated outcome (Enrolled status = N or U from the Response depending on the network).
- For regions where an extension has been given, intra region 3DS 1.0 transactions will be go through normal 3DS 1.0 processing.
What happens to 3DS 1.0 Replays post-sunset?
Cardinal will deactivate 3DS 1.0 Replay in alignment with the network sunset dates. The only exception to this is India intra-regional transactions, where the Replay functionality will still be supported until 3DS 1.0 is sunset in India. Post-sunset, non-EMV 3DS transactions will result in an unauthenticated outcome.
What will a Payer Auth Enrollment request receive post-sunset?
Cardinal will continue to process transactions for 3DS 1.0. If the transaction is acquired and issued within a country that has been sunset, then you will receive an unauthenticated (Enrolled = N or U within the Enrolment request on the network) outcome in the Lookup Response.
Additional Information
Was this article helpful?