A-14 Transaction Life cycle

Each transaction received by the Gateway follows a pre-determined life cycle from receipt to completion. The stages in the life cycle are determined by the type of transaction and its success or failure at different stages in its life.

A-14.1 Authorise, Capture and Settlement

The key stages in the transaction’s life cycle can be grouped into the Authorisation, Capture and Settlement stages as follows:

A-14.1.1 Authorisation 

An authorisation places a hold on the transaction amount in the Cardholder’s issuing bank. No money actually changes hands yet. For example, let’s say that you are going to ship a physical product from your website. First, you authorise the amount of the transaction; then you ship the product. You only capture the transaction after the product is shipped.

A-14.1.2 Capture 

A capture essentially marks a transaction as ready for settlement. As soon as the product is shipped, you can capture an amount up to the amount of the authorisation. Usually, the full amount is captured. An example of a situation in which the whole amount is not captured is where the Customer ordered multiple items and one of them is unavailable.

The Gateway will normally automatically capture all authorisations as soon as they are approved, freeing up you from having to do this.

However, it is usually more desirable to delay the capture either for a period of time or indefinitely. The captureDelay field can be used for this purpose and will allow you to state the number of days to delay any automatic capture or never to automatically capture. For more details on delayed capture, refer to appendix A-9.

A-14.1.3 Settlement 

Within 24 hours, the Gateway will instruct your Acquirer to settle the captured transaction. The Acquirer then transfers the funds between the Cardholder’s and your accounts.

A-14.2 Transaction States

At any time during the transaction’s life cycle, it is in one of a number of states as follows:

A-14.2.1 Received 

The transaction has been received by the Gateway and stored away. This is the first stage. The Gateway will examine the transaction and pass it on to the next stage, as appropriate.

A-14.2.2 Approved 

The transaction has been sent to the Acquirer for authorisation and the Acquirer has approved it and is holding the Cardholder’s funds. 

This is an intermediate state and follows the received state.

A-14.2.3 Verified 

The transaction has been sent to the Acquirer for verification and the Acquirer has confirmed that the account is valid. 

This is a terminal state and follows the received state. The transaction will never be settled and no funds will ever be transferred.

A-14.2.4 Declined 

The transaction has been sent to the Acquirer for authorisation and the Acquirer declined it. The Acquirer will not usually give any reason for a decline and will not have held any funds. 

The transaction has now completed its life cycle and no more processing will be done on it. 

This is a terminal state and follows the received state. The transaction will never be settled and no funds will ever be transferred. The transaction responseCode will be 5 (Declined). 

A-14.2.5 Referred 

The transaction has been sent to the Acquirer for authorisation and the Acquirer referred it for verbal approval. 

You can choose not to seek verbal approval and treat these transactions the same as a normal ‘declined’ authorisation. 

To seek verbal approval, you must phone the Acquirer and ask for an authorisation code. They will probably ask for more information about the transaction and might require you to gather other forms of identification from the Cardholder. If an authorisation code is provided, then a new transaction can be sent to the Gateway specifying the xref of this transaction and the received authorisationCode. This new request will not be sent for authorisation and will be in the ‘approved’ state ready for capture and settlement.

This is a terminal state and follows the received state. The transaction will never be settled and no funds will ever be transferred. The transaction responseCode will be 2 (Referred).

A-14.2.6 Reversed 

The transaction was sent to the Acquirer for authorisation and the Acquirer approved it. However, the transaction has been voided and the approval reversed. The Acquirer will have been asked to reverse any approval previously received, effectively cancelling the authorisation and returning any held funds back to the Cardholder.

The gateway will reverse an authorisation if it declines the transaction post authorisation due to any AVS/CV checking. The PREAUTH action will also automatically reverse an authorisation before return. 

This is a terminal state and follows the approved state. The transaction will never be settled and no funds will ever be transferred.

 If the transaction was reversed due to AVS/CV2 checking, then the transaction responseCode will be 5 (AVS/CV2 Declined).

A-14.2.7 Captured 

The transaction has been captured and the Acquirer will be asked to capture the approved held funds when the settling process next runs. The settling process usually runs each evening but the Acquirer may take up to 3 days to transfer the funds.

The capture state can either be entered automatically if the transaction requested an immediate or delayed capture; or it can be manually requested by sending a CAPTURE request. You are free to change the amount to be captured to a value less than that initially approved by issuing one or more CAPTURE commands. When captured, there is no way to un-capture a transaction. If not explicitly cancelled, it will be sent for settlement at the next opportunity.

 This is an intermediate state and follows the approved state.

A-14.2.8 Tendered 

The transaction has been sent to the Acquirer for settlement by the settling process and is awaiting confirmation that it has been accepted. 

At this point, the transaction can no longer be cancelled or re-captured.

This is an intermediate state and follows the captured state. 

A-14.2.9 Deferred 

The transaction could not be settled due to some temporary problem such as a communications loss. It will be attempted again the next time the settling process runs – usually first thing the next day. 

This is an intermediate state and follows the tendered state. It will normally be accompanied by a transaction response that indicates why the settlement process could not settle the transaction.

A-14.2.10 Accepted 

The transaction has been accepted for settlement by the Acquirer. The held funds will be transferred between the Merchant and Cardholder in due course.

The transaction has now completed its life cycle and no more processing will be done on it, unless it is subject to a rejection while the Acquirer is settling it.

This is a terminal state and follows the tendered state.

A-14.2.11 Rejected 

The transaction has been rejected for settlement by the Acquirer. The held funds will not be transferred between the Merchant and Cardholder. 

Only a few Acquirers inform the Gateway that they have rejected a transaction: they usually inform you directly. Therefore, a transaction may show as accepted even if was ultimately rejected or it may change from accepted to rejected if the Acquirer does inform the Gateway. 

The transaction has now completed its life cycle and no more processing will be done on it.

This is a terminal state and follows the tendered or accepted states. The transaction response will normally indicate the reason the transaction was rejected.

A-14.2.12 Canceled 

The transaction has been cancelled by the Merchant by sending a cancellation request to the Gateway either using the CANCEL action or via the Merchant Management System (MMS).

You can cancel any transaction that is not in a terminal state or in the ‘tendered’ state. When cancelled, any further processing that would have normally taken place will be halted. Cancelling a transaction may or may not release any funds held on the Cardholder’s card, depending on support from the Acquirer and card scheme. Note: the state is spelt American style, with a single ‘l’ as canceled. 

This is a terminal state and follows any non-terminal state that occurs before the transaction reaches the tendered state. 

A-14.2.13 Finished 

The transaction has finished and reached the end of its lifespan but did not reach one of the other terminal states. Usually this indicates that a problem has occurred with the transaction that prevents it continuing with its normal life cycle. 

This is a terminal state and can follow any other state. The transaction response will normally indicate the reason that the transaction failed.