If you have chosen to authenticate cardholders by connecting to our Hosted Authentication service you must be aware of your
responsibilities, as the success of authentication processing relies on your ability to integrate and communicate effectively with us.
We will provide you with the means to communicate with the Hosted Authentication service.
3.1 Your Responsibilities You must:
• Sign up for authentication with your chosen payment solution and must specify that you are using the Hosted Authentication solution from Barclaycard Payment Acceptance
• Correctly integrate the Hosted Authentication service according with instructions provided
• Ensure that the authentication responses returned by the Hosted Authentication service are correctly passed to your payment solution for submission in the authorisation message
• Ensure your chosen payment solution (if not ePDQ) is approved by us to process Internet Authentication transactions
• Ensure that the IAV (CAVV for Visa, AAV for SecureCode™) is correctly passed in the authorisation message
• Ensure any additional auxiliary data is passed in the authorisation message
• Ensure any additional data is passed in the clearing message
• Manage the process around the cardholder pop up or in-line window (i.e. size, time outs)
• Manage the process for error scenarios on the pop up or in-line window (i.e. cardholder cancels)
• Secure the Authentication Merchant Information used to register you with the card schemes at all times
• Consider optionally maintaining audit records of authentication transactions.
3.2 Our Responsibilities We will:
• Register you with each participating card scheme supported by us and signed up by you
• Provide you with the appropriate Authentication Merchant Information as registered with the card schemes
• Provide you with the relevant Hosted Authentication service integration guide
• Maintain a full audit trail and provide transaction evidence to the card issuer in the event of a chargeback where we believe authentication was correctly performed and where liability shift is available (this does not include RFI – see section 7.5), based on authentication data sent by you
• Accept authorisation and clearing messages from your chosen payment solution containing authentication data
• Provide software upgrades where required (i.e. to support a new card scheme) and upgrade documentation.
3.3 Transaction Records
We will maintain authentication transaction records on your behalf and will use these to provide evidence that the transaction was
authenticated in the event of a chargeback. It will be your responsibility to ensure that the correct IAV (CAVV, AAV) and ECI value is attached to both the authorisation and settlement transaction.
As you control the submission of authentication requests through the Hosted Authentication service you are responsible for ensuring correct integration. Whilst we will defend a chargeback based on the
information held on our systems, our records will be based on
information received from you. If the card issuer continues to dispute the validity of the authentication we may ask you to provide additional audit evidence as shown in the table on the next page. If you are unable to supply this, the transaction may be charged back to you.
Full Authentication (Visa) Full UCAF (MasterCard and Maestro)
Attempted Authentication (Visa) Merchant UCAF (MasterCard
and Maestro)
ECI value = 5 CAVV
Supplied in human readable format PAReq/PARes XID
ECI value = 6 Attempts CAVV Supplied in human readable format
ECI value = 2 AAV
Supplied in human readable format PAReq/PARes
ECI value = 1 AAV (if supplied) VEReq/VERes OR PAReq/PARes
We may ask you to provide transaction information to support a card issuer Retrieval Request (RFI – see section 7.5). If you do not provide the requested information you may risk losing the liability shift afforded by Internet Authentication.
3.4 Card Issuer Pop Up or In-line Window
It is strongly recommended that you use an in-line window to prevent problems commonly associated with pop up suppression (also referred to as pop up killers) and avoid situations where customers inadvertently close the pop up window. Whether you use pop up or in-line, it is your responsibility to present the browser pop up or in-line window to the cardholder. The card issuer will populate the content and will perform the authentication. You must control the size, time out and error handling conditions associated with the window.
The recommended size of the pop up or in-line window will be provided in the integration documentation. If you choose to support an in-line window you must do so in accordance with the guidelines provided.
It is recommended that the time out for the pop up or in-line window is set to a reasonable time to allow cardholders sufficient time to
authenticate themselves. It is your responsibility to set this in line with your website and risk policy. You must ensure you display an adequate error message to the cardholder should you enforce your time out.
There may be occasions where the cardholder closes, cancels or cannot view the pop up or in-line window. You must ensure your website is capable of handling the error responses associated with this and must display clear error messages to the cardholders. It is recommended that you should maintain a balance of informative and non-specific
information so as not to assist potential fraud.
3.5 Your Authentication Merchant Information
We will allocate you specific data to participate in the service, and will register this with each scheme. This will allow you to process
Authentication transactions through each scheme.
You will need to code these details into your integration with the Hosted Authentication service and pass them on each authentication request.
You must ensure that you correctly integrate the information we provide which may be different for each scheme.
Failure to pass the correct details could result in a failure of authentication request.
Once integrated, you should not amend this information unless advised by us. If you lose this information or feel it has been compromised in any way you should contact us immediately. We will issue you with new details and re-register you with the relevant card scheme(s). This process may take up to 10 working days.
3.6 Message Values
Cardholder authentication generates new message values to indicate the level of security employed, plus the result of the authentication.
The Hosted Authentication service will return responses and message values that must be correctly mapped to your chosen payment solution.
The key value is the Issuer Authentication Value (IAV). For Visa, this will be the CAVV and for MasterCard, this will be the AAV. The IAV will always be provided by the card issuer and should not be altered. Your payment solution will also need to ensure the correct eCommerce indicator (ECI) is attached to the authorisation and clearing message.
The table below provides a definition of the ECI values used by each card scheme:
Visa:
MasterCard and Maestro:
The integration guide we will supply will provide details on how you should correctly map authentication values into your chosen payment solution.
5 Authentication is successful.
6 Authentication is attempted but cardholder was not registered.
7 Authentication is unsuccessful or not attempted (standard eCommerce transaction).
2 Authentication is successful. Full UCAF.
1 Authentication is attempted but cardholder was not registered. Merchant UCAF.
0 Authentication is unsuccessful or not attempted (standard eCommerce transaction).
3.7 BIN Cache
The BIN Cache is a repository of BIN ranges held locally (on the Hosted Authentication service server) that are participating in the authentication scheme. You can check the BIN Cache before contacting the relevant scheme Directory to check whether a cardholder is participating.
This could reduce the number of messages you are required to generate. We will update the BIN Cache every 24 hours.
3.8 Use of the Verified by Visa and MasterCard Logos
Following successful registration and integration of the authentication software you must download and display the Verified by Visa and MasterCard SecureCode™ logos on your website payment page. These logos will demonstrate to your customers that you are participating in each of the schemes.
The logos will be available from a specific URL (web address) which will be made available to you upon successful application. Instructions will be provided to enable you to download and display the logo.
Section 4 – Barclaycard SmartPay Hosted Payment Page Users
You must read this section if you are using the Barclaycard SmartPay Hosted Payment Page with integrated cardholder authentication.
The Barclaycard SmartPay Hosted Service is a fully hosted payment and authentication service. If you use the Barclaycard SmartPay Hosted Payment Page you will not have to integrate any additional software for cardholder authentication. Once you have successfully applied for the service we will activate the Barclaycard SmartPay Hosted Payment Page to perform authentication on all relevant transactions.
Although the Barclaycard SmartPay Hosted Payment Page requires no specific authentication integration, you must ensure that you have correctly installed the Barclaycard SmartPay Hosted Payment Page in line with the instructions provided to you. Failure to do this may result in incorrect transaction processing.
4.1 Your Responsibilities
We control the authentication process within the Barclaycard SmartPay Hosted Payment Page and will ensure you have minimal disruption to your current transaction processing. You must:
• Correctly integrate the Barclaycard SmartPay Hosted Payment Page in line with instructions provided at sign up
• Read and understand how the Barclaycard SmartPay Hosted
• Request Activation of the Barclaycard SmartPay Hosted Payment Page
• Advise us immediately if you cease using the Barclaycard SmartPay Hosted Payment Page.
4.2 Our Responsibilities We will:
• Register you with each participating card scheme supported by us
• Provide you with the Barclaycard SmartPay integration guide
• Configure Barclaycard SmartPay to allow your transaction process to authenticate transactions
• Control the processing of authentication transactions
• Adhere to relevant card scheme policies
• Process transactions accordingly for “failure” scenarios in line with your configuration requirements for Barclaycard SmartPay
• Maintain a full audit trail and provide transaction evidence to the card issuer in the event of a chargeback where we believe authentication was correctly performed and where liability shift is available (this does not include Retrieval Requests (RFI) – see section 7.5)
4.3 Transaction Records
We will maintain authentication transaction records on your behalf and will use these to provide evidence that the transaction was authenticated in the event of a chargeback. It will be our responsibility o ensure that the correct IAV (CAVV, AAV) ECI, and XID (for Visa) value is attached to both the authorisation and/or settlement transaction.
This information will not be made available to you.
We may ask you to provide transaction information to support a card issuer Retrieval Request (RFI – see section 7.5). If you do not provide the requested information you may risk losing the liability shift afforded by Internet Authentication.
4.4 Card Issuer In-line Window
If a cardholder is registered with their issuer, they will see a browser in-line window, which will allow them to enter their password for authentication. We maintain control of the in-line window. This ensures a consistent service to your customers and allows us to monitor the window in case of time out or corrupt data.
4.5 Your Authentication Merchant Information
We will allocate you specific data to participate in the service, and will register this with each scheme. This will allow you to process
authentication transactions through each scheme. There is no integration required by you.
4.6 Message Values
Cardholder Authentication generates new message values to indicate the level of security employed, plus the result of the authentication.
We will ensure the Barclaycard SmartPay Hosted Payment Page processes all new message values correctly. There may be occasions where authentication is not possible (e.g. in-line window does not appear or a time out).
In the event that a participating cardholder cannot authenticate themselves, a Visa transaction must be declined. If this occurs, depending on the issuer, Barclaycard SmartPay will decline the transaction.
Please note: MasterCard and Maestro transactions are permitted to continue. See section 7 for more information.
4.7 BIN Cache
The BIN Cache is a repository of BIN ranges held with the schemes Directory service and contains the details of the participating issuer in the authentication scheme. Each authentication request will first check the BIN Cache to see if the issuer is participating. If the issuer is not listed in the BIN Cache then you are able to claim an ‘attempted authentication’. If the issuer is listed, Barclaycard SmartPay will continue to try and obtain authentication.
4.8 Use of the Verified by Visa and SecureCode™ Logos
You are able to display the Verified by Visa and SecureCode™ logos on the Barclaycard SmartPay Hosted Payment page. This will provide your customers with the assurance that you are participating in the
scheme(s) and have been fully registered to participate. If at any stage you request not to use the Authentication service, you will need to remove both logos from your payment page and skin template. Both card schemes require the logos to be displayed as evidence of participation in the service.
Section 5 – Barclaycard SmartPay API Service Users
You must read this section if you are using the Barclaycard SmartPay API Service with integrated cardholder authentication.
If you use the Barclaycard SmartPay API Service you will not have to integrate any additional software for cardholder authentication.
However, you must ensure that:
1. Your processing account has been configured by Barclaycard SmartPay to support Internet Authentication
2. Your software supports redirecting the shopper to the card issuer and submitting a second API call to complete the payment.
Once you have successfully applied for the service we will activate he Barclaycard SmartPay API Service to perform authentication on all relevant transactions.
Although the Barclaycard SmartPay API Service requires no specific authentication integration, you must ensure that you have correctly installed the Barclaycard SmartPay API in line with the instructions provided to you. Failure to do this may result in incorrect transaction processing.
5.1 Your Responsibilities
We control the authentication process within the Barclaycard SmartPay API and will ensure you have minimal disruption to your current
transaction processing. You must:
• Correctly integrate the Barclaycard SmartPay API Service in line with instructions provided at sign up
• Read and understand how the Barclaycard SmartPay API Service handles authenticated transactions – this information is provided in the integration guides
• Request Activation of the Barclaycard SmartPay API Service
• Advise us immediately if you cease using the Barclaycard SmartPay API Service.
5.2 Our Responsibilities We will:
• Register you with each participating card scheme supported by us
• Provide you with the Barclaycard SmartPay integration guide
• Configure Barclaycard SmartPay to allow your transaction process to authenticate transactions
• Control the processing of authentication transactions
• Adhere to relevant card scheme policies
• Process transactions accordingly for “failure” scenarios in line with your configuration requirements for Barclaycard SmartPay
• Maintain a full audit trail and provide transaction evidence to the card issuer in the event of a chargeback where we believe authentication was correctly performed and where liability shift is available (this does not include Retrieval Requests (RFI) – see section 7.5)
• Ensure the correct authentication values are attached to both the authorisation and clearing message where appropriate.
5.3 Transaction Records
We will maintain authentication transaction records on your behalf and will use these to provide evidence that the transaction was
authenticated in the event of a chargeback. It will be our responsibility to ensure that the correct IAV (CAVV, AAV) ECI, and XID (for Visa) value is attached to both the authorisation and/or settlement transaction.
This information will not be made available to you.
We may ask you to provide transaction information to support a card issuer Retrieval Request (RFI – see section 7.5). If you do not provide the requested information you may risk losing the liability shift afforded by Internet Authentication.
5.4 Card Issuer In-line Window
If a cardholder is registered with their issuer, they will see a browser in-line window, which will allow them to enter their password for authentication. We maintain control of the in-line window. This ensures a consistent service to your customers and allows us to monitor the window in case of time out or corrupt data.
5.5 Your Authentication Merchant Information
We will allocate you specific data to participate in the service, and will register this with each scheme. This will allow you to process
authentication transactions through each scheme.
5.6 Message Values
Cardholder Authentication generates new message values to indicate the level of security employed, plus the result of the authentication.
We will ensure the Barclaycard SmartPay API Service processes all new message values correctly. There may be occasions where authentication is not possible (e.g. in-line window does not appear or a time-out).
In the event that a participating cardholder cannot authenticate themselves, a Visa transaction must be declined. If this occurs, depending on the issuer, Barclaycard SmartPay will decline the transaction.
Please note: MasterCard and Maestro transactions are permitted to continue. See section 7 for more information.
5.7 BIN Cache
The BIN Cache is a repository of BIN ranges held with the schemes Directory service and contains the details of the participating issuer in the authentication scheme. Each authentication request will first check the BIN Cache to see if the issuer is participating. If the issuer is not listed in the BIN Cache then you are able to claim an ‘attempted authentication’. If the issuer is listed, Barclaycard SmartPay will continue to try and return a URL supplied by the issuer for you to display to the shopper.
5.8 Use of the Verified by Visa and SecureCode™ Logos
You are able to display the Verified by Visa and SecureCode™ logos on the Barclaycard SmartPay Payment page. This will provide your customers with the assurance that you are participating in the
scheme(s) and have been fully registered to participate. If at any stage you request not to use the Authentication service, we will remove both logos from Barclaycard SmartPay. Both card schemes require the logos to be displayed as evidence of participation in the service.