Hosted Payment Page
Overview
If you are integrating into our Hosted Payment Page (HPP) we will handle a lot of the steps required to authenticate your customers as detailed in ourEMV® 3-D Secure (v2) guides.
This developer documentation focuses on integrating 3-D Secure as well as ensure there is no effect on your PCI compliance responsibilities – keeping you in-scope for SAQ A.
By completing this integration guide, you will cater for all scenarios and be SCA ready.
Request
As you will see in the HPP Documentation we've marked which additional parameters are required for EMV® 3-D Secure (v2).
To save you needing to go take a closer look, here is a summary:
Make sure you have set the is_tds
parameter as 2 to let us know you want to use 3-D Secure.
It is best practice to send on additional customer data the issuing bank will need to authenticate the cardholder. This consists of:
- The cardholder's billing address (billing_street, billing_city, billing_zipcode and billing_country_code_iso2).
- The cardholders' contact details (billing_email).
- A link to the "Contact Us" page on your website (merchant_contact_url).
In case it is EMV® 3-D Secure (v2), we need to know some additional settings / preferences you have for the authentication (tds_source, tds_type and tds_preference).
Once we have all of this information, we can handle any scenario that pops up.
Template
As you will see in the API documentation for EMV® 3-D Secure (v2) there are a few extra steps required to complete authentication including:
- Checking the version of 3-D Secure supported by the card issuer.
- Gathering the Device ID via the method_url.
- Gathering the user's browser data.
We've added all these actions to our acquired.js file in the default HPP template (which you can get from the Hub) to ensure everything works as it should.
Authentication
In the event that there is a ‘challenge’, we will display the issuer's ACS page to the user in order to complete the authentication - nothing you need to do here.
Response
Once authentication is complete, we'll respond back to you in your chosen method but there are some additional response codes / fields you should be aware of:
Parameter | Format | Length | Description |
---|---|---|---|
code | int |
1-3 | If the Authentication is successful, we'll return one of our standard authorisation response codes. However, if it fails you'll see one of the following values: 540 SCA: Failed 541 SCA: Not Successful 542 SCA: Issuer Rejected 565 SCA: Required |
eci | int |
1 | Just like the existing version of 3-D Secure the ECI (e-Commerence Indicator) has been used to indicate the outcome of the authentication. Possible values for Visa and American Express are: 5 (Success), 6 (Attempted), 7 (Failed). Possible values for MasterCard are: 2 (Success), 1 (Attempted), 0 (Failed). |
reason | int |
1-2 | Provides more information on the outcome of the authentication. Possible values are: 01 = Authentication Failed 02 = Unknown Device 03 = Unsupported Device 04 = Exceed Authentication Frequency Limit 05 = Expired Card 06 = Invalid Card Number 07 = Invalid Transaction 08 = No Card Record 09 = Security Failure 10 = Stolen Card 11 = Suspected Fraud 12 = Transaction Not Permitted to Cardholder 13 = Cardholder Not Enrolled in Service 14 = Transaction Timed Out at ACS 15 = Low Confidence 16 = Medium Confidence 17 = High Confidence 18 = Very High Confidence 19 = Exceeds ACS Max Challenges 20 = Not Payment Transction Not Supported |