Bank Card Processing

Bank Card Processing

The Bank Card Service allows you to authorise a card payment in real time and settle the funds next day or later. Successful payments can be refunded without the need to store sensitive card details. The service can be seamlessly integrated into your systems, enabling your customers and Customer Service teams to experience fast and efficient processing and management of transactions.

 

There are two parts to the Bank Card Service: authorisation and settlement.

Obtaining an Authorisation Code


Once the payment details have been collected and sent to DataCash, they are immediately sent to your Acquiring Bank for authorisation. Your Bank forwards the request to the Card Issuing Bank. The Issuing bank check the card details against their own systems and return an authorisation code if they approve the transaction. The full transaction response including the authorisation code is then passed back to your system via your Bank and DataCash. The entire process typically takes less than two seconds. 

Once the authorisation code has been issued, the funds for that transaction are reserved for you - this means that even if the card subsequently becomes over it's limit, the funds are still available for you. Each authorisation code remains valid for typically between one and ten working days, after which the funds will become available to the card holder again if the transaction has not been settled. Further details on the timescales involved can be obtained from your Acquirer if required.

Settling the Transaction


To transfer the money between you and your customer, the authorised transaction needs to be settled by your Acquiring Bank. 

Each day, DataCash collate all the authorised transactions and submit them to your Acquiring Bank, who then settle the transactions. This process takes place every working day at midnight, which means that transactions are settled next working day. 

Your Acquirer will typically take three to five working days to settle the transaction. Please contact your Acquirer for more information regarding settlement times. 

Settlement does not take place on English Bank Holidays - a list of Bank Holidays is available from the Department of Trade and Industry.

Requirements


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

  • A DataCash account.

  • A merchant account or merchant ID (MID) with one of the Acquiring Banks that DataCash are integrated with.

A complete list of Acquiring Banks supported by DataCash is available here.

Transaction Processing Models


There are two types of Transaction Processing Models which can be used to submit new card payments to DataCash. One Stage processing - the transaction is authorised and then settled. If you are using this model, you will only need to contact the DataCash servers once. 

Two Stage processing - the transaction is authorised, but settlement is delayed until you are ready to proceed. If you are using this model, you will need to contact the DataCash servers twice - once for authorisation and again for settlement. 

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 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. This is available to both processing models without additional account configuration.

One Stage Processing


The One Stage model will send transaction details to your Acquiring Bank for settlement on the next working day. This process will charge or refund the card holder without requiring any additional action from yourselves. 

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 the one stage model are:

 

Transaction Type

Affect

Uses

auth

Debits the Card

Requests authorisation and settles transaction the next working day

refund

Credits the Card

Returns funds to the card holder. The transaction is settled next working day

Two Stage / Delayed Processing


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 second 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

Affect

Uses

pre

Debits the Card

Reserves funds on the card, but does not settle the transaction until a valid fulfillrequest is received.

erp

Credits the Card

Creates a refund request, but does not settle the transaction until a valid fulfillrequest is received.

fulfill

Completes the two stage process

Initiates settlement of a valid pre or erptransaction. The transaction is settled next working day

The card details are only required for the pre and erp transactions types, they are not required to fulfill the transaction.

Refunding without Card Information


DataCash provide a specific transaction type to allow successful transactions to be refunded without needing the full card details. This enables refunds tobe performed on existing transactions without the need to store the full card details.

 

Transaction Type

Affect

Uses

txn_refund

Credits the Card

Uses an existing transaction to returns funds to a card. The transaction is settled next working day

The original transaction can either be completely or partially refunded, and multiple refunds can be performed on one transaction until the full value of the transaction has been refunded.

Cancelling Payments


One stage transactions and completed two stage transactions can be prevented from debiting (or crediting) the card using the cancel transaction type. This will prevent an authorised transaction from being settled and can therefore only be used before the transaction has been settled. 

Situations in which this could be implemented include:

  • Customer cancellations - for systems allowing the customer to cancel an order after placement

  • Physical Shipment - if at shipment the goods are found to be damaged, the payment can be cancelled

Transaction Type

Affect

Uses

cancel

Prevents settlement of a transaction

Stops one stage and completed two stage transactions from being settled

Prevents an uncompleted two stagetransaction from accidental fulfillment

As a cancelled transaction will not be settled, the reserved funds will be returned to the customer after one to ten working days.

  

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.

Performing an Initial Card Transaction


For the Bank Card service, the following information needs to be collected from the card holder for every transaction:

  • the card number

  • the expiry date of the card

  • the start date - if present on the card

  • the issue number - if present on the card

To allow you to ensure each item of information required for each card is provided, DataCash provide the CardInfo files. Each time a payment is entered on to your system, these files can be used to ensure all the required fields have been completed before the transaction is submitted to DataCash. These files also contain other information which can be utilised if required. Further information about the CardInfo files is available in the Developers Area

In addition to the card information collected from the customer, these details about the transaction are also required:

  • the value and currency of the transaction

  • a unique reference number generated by your system - to allow the transactions to be distinguished from each other

  • the transaction type - to allow DataCash to use the correct processing model. One ofpreautherp or refund

Completing the Two Stage Process


To settle a transaction processed using the Two Stage process, a fulfill is needed. This informs DataCash that you wish to proceed with the transaction. Once this has been done, the card will be charged. Only successful pre anderp transactions can be fulfilled. 

To fulfill a transaction, information from the result of the original pre / erptransaction is required, in addition to the transaction type:

  • the datacash reference

  • the authorisation code

  • the transaction type - fulfill

Transactions are normally fulfilled for the full value of the original transaction. If you wish to perform a partial fulfill, this can be done by specifying theamount in the fulfill request. Each transaction can be fulfilled once.

Refunding without Card Information


The txn_refund transaction type uses a successful transaction to perform a refund, instead of requiring the card details. The reference number returned to you by DataCash when submitting the original transaction is used to locate the card details. 

Any successful auth or completed pre-fulfill transaction can be refunded in this fashion, provided they have not been cancelled. 

To txn_refund a transaction, information from the result of the original transaction is required, in addition to the transaction type:

  • the datacash reference

  • the transaction type - txn_refund

Transactions are normally refunded for the full value of the original transaction. If you wish to refund a lower value, this can be done by specifying the amount in the txn_refund request. Each transaction can be refunded several times, provided the total refunded does not exceed the value of the original.

Cancelling Transactions


To cancel a transaction prior to settlement, information from the result of the original transaction is required, in addition to the transaction type:

  • the datacash reference

  • the transaction type - cancel

Response Codes


There are three basic Bank Responses for transactions:

  • Accepted

  • Declined

  • Referred

In addition there are various error codes that can be produced by this service. Examples of each response type available in the Developers Guide.

Accepted Transactions


Once a transaction is accepted, your system can complete the normal ordering process. If you are using the Two Stage model, please remember that the second stage must be completed to debit / credit the card.

Declined Transactions


Occasionally, you may find a transaction is declined. There are several general reasons why a card may be declined. These include:

  • The card has been cancelled

  • The card is approaching or is past its limit and does not have enough funds to cover the full value

  • The Issuing bank have noticed unusual patterns of spend on the card

If a transaction is declined, DataCash return the full bank response to you. You may wish to encourage the user to try another card, or to re-try at a later date.

Referred Transactions


referral response is part way between an accepted and a declined response. The Issuing Bank does not wish to automatically issue an authorisation code, but is providing you with the opportunity to receive a manual authorisation instead of simply issuing a decline response. To proceed with the payment, you should phone the authorisation centre of your Acquiring Bank - not the cardholders bank - with the card details. 

For an auth, the transaction can then be continued by sending an authorize_referral_request transaction, specifying the authorisation code provided by the authorisation centre. For a pre, the transaction can be completed by including the authcode in the fulfill transaction, or by an authorize_referral_request which is followed at a later date by a fulfill. Alternatively, the transaction could be entirely resubmitted to DataCash with the authorisation code. 

Additional services, such as AVSCV2 or ReD may also prevent the transaction being authorised. If this is the case, you will not be able to issue fulfill or authorize_referral_requesttransactions to continue processing. 

Like the declines DataCash return the full bank response to you. 

The main reasons for a referral are:

  • the Issuer is performing a spot check

  • the card is approaching its limit

If you are designing a fully automated system, you may wish to simply treat these transactions in the same way as a decline. This requires no extra action on your part.

Error Messages


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

Reporting


The transactions are detailed in the Bank Card section of the DataCash Reporting system. There are three main pages:

  • Summary - gives a summary of the transactions

  • List - shows specific details of the transactions

  • Details - shows full details of each transaction

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