3-D Secure DataCash MPI Service

This document is a technical introduction to the DataCash 3-D Secure Service with the DataCash Merchant Server Plug-in (MPI). Further detailed information to assist integration with this Service is available in the Developers Guide.

3-D Secure MPI Service

This Service enables the cardholder, you and the card Issuing Bank to authenticate each other prior to the authorisation of a transaction.

Instead of installing and integrating new software with your systems, you use an extension to the DataCash Payment Gateway designed specifically for this purpose. This software is called the DataCash MPI.

When this Service is incorporated into the authorisation process, there are four stages to the normal transaction cycle: card enrolment check, cardholder verification, authorisation and settlement.

Card Enrolment check

Once the payment details have been collected and sent to DataCash, they are immediately forwarded by the DataCash MPI to the Directory Server which determines whether the card is enrolled within the 3-D Secure system.

The results of this check are passed back to your systems via the MPI. If the card is enrolled, this message will include the payment authentication request (PAReq), which contains the details required to re-direct the card holder to the Access Control Server (ACS) for their Issuing bank. It also contains the information required to re-direct them back to your own site, once authentication has been completed.

Cardholder Verification

If the card is enrolled for 3-D Secure, your systems will use the PAReq to re-direct the card holder to the ACS page provided by their Issuing Bank. This page enables the card holder to authenticate themselves directly with their bank.

Once the authentication process is complete, the ACS re-directs the card holder back to your website. This re-direction process also passes back the payment authentication response (PARes) which is generated by the Issuer, and contains information about the result of the check.

For cards which are not registered for 3-D Secure, your system may automatically proceed directly to authorisation if required.

Authorisation

Once the verification process has been completed, the PARes is forwarded to the DPG by your system. It is then checked to ensure it genuinely came from the Issuer and that the cardholder successfully authenticated themselves. If the verification was successful, the transaction is sent to your Acquiring Bank for authorisation. Your bank forwards the request to the Issuing Bank, who return an authorisation code if they approve the transaction.

If the cardholder was unsuccessful in their verification attempt or the PARes is somehow invalid, the transaction will not be sent for authorisation.

The full transaction response - including the authorisation code if the transaction is successfully authorised - is then passed back to your system by the DPG.

Settlement

Successfully authorised transactions are settled next working day, in the same way as transactions which have not been checked using 3-D Secure.

Requirements

Before you can go live with this service, you will need the following:

  • a DataCash e-Commerce account
  • the account to be configured with the 3-D Secure service
  • the account to be configured to use the DataCash MPI
  • to be a registered 3-D Secure merchant with your Acquirer, for the specific card schemes

The 3-D Secure check is currently available for certain Acquiring Banks and card schemes. These are outlined in the table below:

Acquiring Bank Card Scheme
Barclays MasterCard, Visa
HBOS MasterCard, Visa
HSBC MasterCard, Visa
Lloyds TSB MasterCard, Visa
Royal Bank of Scotland Group (includes NatWest) MasterCard, Maestro International, Visa

Transaction Processing Models

There are two types of Transaction Processing Model which can be used to submit new card payments to DataCash using the 3-D Secure service:

One Stage 3-D Secure - the enrolment check is performed, the transaction is authorised and then automatically settled. The enrolment check is initiated using the auth transaction type.

Two Stage 3-D Secure - the enrolment check is performed, the transaction is authorised, but settlement is delayed until you are ready to proceed. The enrolment check is initiated using the pre transaction type, and settlement is initiated using a fulfill transaction.

Either model can be used for each transaction. There are no restrictions, extra service charges or additional account configuration.

Each time a transaction is submitted to the DataCash Payment Gateway, it contains the information that determines the model to be used for that transaction. This ensures you have the flexibility to mix and match models as required on an individual transaction basis.

In both models, the card enrolment check and authorisation request is returned to you in real time. The difference between each model lies in the settlement process.

Once a transaction has been submitted to DataCash, it can be refunded or cancelled if required. Refunds and cancellations are processed in exactly the same way as for Bank Card transactions.

One Stage 3-D Secure

The One Stage 3-D Secure model will send successful transaction details to your Acquiring Bank for settlement on the next working day.

Situations in which this could be implemented include:

  • Instant access services - such as software downloads
  • Ticketing systems - such as airline and train reservation services
  • Physical goods that will be shipped same day

The transaction types that can be used with this model are:

Transaction Type Effect
auth Requests a card enrolment check
threedsecure_authorisation_request Returns the PARes and initiates the authorisation process on the existing auth. If successful, the transaction is settled next working day

Two Stage 3-D Secure

The delayed settlement model enables you to settle the transaction at your convenience. The transaction is authorised, but is not automatically settled. Settlement takes place once the final stage has been initiated by your systems.

Situations in which this could be implemented include:

  • Ordered Items are not currently available
  • Additional in-house processes need to be completed prior to settlement

The transaction types that can be used with the two stage model are:

Transaction Type Effect
pre Requests a card enrolment check
threedsecure_authorisation_request Returns the PARes and initiates the authorisation process on the existing pre, but does not settle the transaction until a valid fulfill request is received
fulfill Initiates settlement of the transaction. The transaction is settled next working day

Referred Authorisation

DataCash provide a specific transaction type to enable referred 3-D Secure transactions to be processed. This transaction type retains any liability shift confered by the check and means the card details do not need to be re-entered.

Transaction Type Effect
threedsecure_authorize_referral_request Enables an authorisation code obtained directly from the bank to be supplied for a transaction

Performing Transactions

Each transaction type requires specific information to be provided. In addition to those listed, each requires a client and password - these are security details which identify your account.

The transaction types fulfill, cancel, refund, erp and txn_refund are all performed as outlined in the Bank Card Service - no extra information is required for these transaction types.

Card Enrolment Request

When you wish to check whether a card is enrolled for 3-D Secure, an auth or pre transaction with the normal transaction and card information should be submitted, in the exactly the same way as for the Bank Card Service.

In addition to this, extra information about the transaction is required:

  • verification status set to yes - to verify the transaction
  • the device category - whether the site is being accessed via a web browser, or a mobile phone browser
  • the date & time
  • your website URL - this will be displayed to the cardholder when they are redirected to complete the verification process
  • a simple description of the product or service being purchased
  • details of the headers accepted by the browser
  • the web browser platform & version

Authorisation Request

In order to proceed to authorisation, a threedsecure_authorisation_request transaction is needed. This needs two pieces of information:

  • the datacash reference from the original transaction
  • the transaction type - threedsecure_authorisation_request

And for cards which are enrolled, the PARes must also be submitted with this transaction.

If the card was not enrolled or is in a scheme for which the 3-D Secure check is not available, a PARes will not be generated and cannot be supplied.

In a very small number of cases, the ACS may not be able to perform the verification process. These transactions would normally be automatically rejected. If you wish to accept this outcome to a transaction, this can be indicated in the card authorisation request.

Referred Authorisation

To process a threedsecure_authorize_referral_request, three pieces of information are required:

  • the transaction type - threedsecure_authorize_referral_request
  • the datacash reference from the original transaction
  • the authorisation code received from your Acquirer

By-Passing 3-D Secure

If you wish to by-pass the 3-D Secure check for a particular transaction, this may be done by setting:

  • verification status set to no

along with a normal auth or pre transaction.

Response Codes

Each stage of a 3-D Secure transaction has its own response types, which are described below.

A complete list of Response Codes for this service is available. The Support Centre also contains extensive examples for most error codes. Illustrations are given to demonstrate how they would appear in both Reporting and an XML Response. Suggestions are also given to help you prevent them from occurring.

Enrolment Checks

There are two basic responses for the enrolment check:

  • enrolled
  • not enrolled

Examples of each response type are available in the Developers Guide.

Authorisation Requests

An authorisation request may generate the three basic bank responses described in the Bank Card Service:

  • Authorised
  • Referred
  • Declined

Errors may also be generated at this stage.

Reporting

When a transaction has been checked using the 3-D Secure service, the details of the check will be available for each transaction on the Bank Card Details page

The Support Centre contains full hints and tips to help you get the most out of Reporting.