Protecting your online business from fraud
Internet Authentication is an industry-wide service designed to help protect your business against online fraud and reduce the likelihood of receiving fraud-related chargebacks.
This page is designed to introduce you to the benefits of Internet Authentication, explain how you can incorporate it into your business, and highlight how the authentication and authorisation procedures work for you and your customers.
How Internet Authentication can benefit your business
Internet Authentication is an industry-wide initiative that allows Visa, MasterCard and Maestro issuers to ask cardholders buying from websites to enter a password to verify that they're the genuine cardholder. This automatically verifies their identity and authenticates the card, so you can accept their payment with confidence.
Internet Authentication can help protect you against online fraud and reduce the likelihood of receiving fraud-related chargebacks. It's a service designed to protect your business from fraudulent payments and allow you to trade online more safely.
Such is the strength of this service that once you've registered and started running Internet Authentication, Visa and MasterCard state that you should not suffer losses for fraudulent Visa or MasterCard transactions, or chargebacks arising when a cardholder denies authorising a payment.
Save time and money – and be safe online
Internet Authentication could save you a lot of money by reducing chargebacks – as well as reducing the time it takes to carry out laborious back office manual checks before accepting Visa, MasterCard or Maestro payments.
How payment, authorisation and settlement work
Internet Authentication is an automated process that’s designed to be simple and straightforward for you and your customers. Everything you’ll need to know about the payment, authorisation and settlement is explained in the sections below.
Once you’ve implemented Internet Authentication on your website, the process is fully integrated into your usual payment system.
1. A customer browsing on the internet decides to buy from you with a Visa, MasterCard or Maestro card.
2. Your payment pages (for instance, ePDQ) communicate with the Visa/MasterCard Directory, which then contacts the card issuer.
3. The card issuer confirms whether the cardholder has registered for Internet Authentication.
4. If the card issuer supports Internet Authentication, a 'pop-up' or 'in-line' web window appears on the cardholder’s screen. If not, the transaction proceeds to authorisation at step 7.
5. The card issuer asks for the cardholder’s Internet Authentication password, and accepts or rejects it.
6. If the password is correct, the payment process continues (if incorrect, the transaction may be stopped).
7. Your payment software (for instance, ePDQ) authorises the payment details and passes them to Barclaycard or other acquirer for settlement.
Click on the links below to download more information:
Read Visa merchant best practice guide
More information about authentication and authorisation
Secure online transaction processing with Internet Authentication combines the benefits of both authentication and authorisation.
Authentication is the process of checking that the cardholder is genuine. A card issuer may prove this by requesting that their cardholder types in a password that correctly matches the details registered.
Authorisation is the process of making sure the cardholder has the funds to pay for the transaction and their card has not been blocked for any reason. Once the card issuer has authenticated the customer, the payment processor (e.g. ePDQ) then authorises the transaction in the normal way.
The authentication process
Authentication takes place during the card payment process, after the cardholder has provided their card details, billing and delivery address. It happens before the transaction is sent to the card issuing bank for authorisation.
From a cardholder’s perspective, shopping is conducted as usual. When the final [BUY] button is clicked, a page from the card issuing bank is presented that asks the cardholder for a password. The password supplied must match the password provided by the cardholder during the enrolment process. Once the correct password is entered, the transaction continues as before and the cardholder is presented with a ‘transaction completed page’. (Typically, this will be a page that confirms that the purchase has been made and provides the cardholder with an order/tracking number from your website).
Authentication process components
Authentication uses the 3D-Secure Protocol to process authentication requests between cardholder, card issuer, your website and our hosted service. The diagram below shows how these components communicate with each other:
The Hosted Authentication Service will perform the following functions:
Interface with the Card Schemes Directory Servers on your behalf for verifying card enrolment
Verify signature of the PARes (Payer Authentication Response) you receive from the issuer
You will be using the SDK to integrate with your application. The SDK enables your application to be authentication aware. The SDK communicates with the BMS Hosted Authentication Service for all functions including verifying card enrolment, creating PAReq (Payer Authentication REQuest) message and verifying PARes signature.
Authentication components and descriptions
In this section you’ll find technical information relating to the components that make up the authentication process.
Software Developer's Kit (SDK)
The Software Developer’s Kit is hosted on your web servers and communicates directly with our Hosted Merchant Service.
Hosted Merchant Service
This receives authentication requests from your SDK and communicates with the relevant scheme directory to perform authentication. We will maintain audit records on this service and ensure compliance with scheme rules.
This is maintained by the card schemes (Visa and MasterCard) and provides details of the relevant issuer Access Control Server (ACS) for a given card number. The Directory Server can also determine if an issuer is participating in authentication, and it may also determine whether an "attempts" response can be returned.
Access Control Server
The Access Control Server is run by (or on behalf of) the card issuer. It performs two basic functions. It communicates to your SDK to confirm whether a card number can be authenticated, and then controls the authentication process with the cardholder. When a cardholder is authenticated, the ACS sends a digitally signed message to your SDK and will return an Issuer Authentication Value (IAV).
Account Holder File
This is the database of all enrolled cardholders maintained by the card issuer. It contains all the details used to authenticate a cardholder.
This is the server that runs the cardholder enrolment service. It is outside of the actual payment process and can be used to enrol cardholders at any time.
Authentication History Server
The Authentication History Server provides a transaction audit of all authentication request and subsequent results. Receipts of authentication requests are maintained which record details of the card, purchase amount, merchant and timestamp of authentication. AHS data is not made widely available and is only used by the card schemes in the event of arbitration.
Our authentication services: designed to work for you
Barclaycard authentication services are designed to work seamlessly with our online payment system to benefit you and your customers:
ePDQ essential or ePDQ extra with hosted payment page – this solution is provided with built-in Internet Authentication and requires minimal configuration.
ePDQ extra plus with API – our hosted internet authentication solution. However, it requires some technical expertise to integrate this service, so you may wish to consider switching to ePDQ essential or ePDQ extra with hosted payment page (as above) for all authorisation and Internet Authentication services.
Our ePDQ essential or ePDQ extra with hosted payment page comes ready-configured to flag Visa, MasterCard and Maestro transactions clearly, to show if Internet Authentication has been used, and indicate whether the transaction will qualify for liability shift if it turns out to be fraudulent. However, if you choose ePDQ extra plus with API, you are responsible for configuration.