Transaction types

Transactions can be categorised by several different criteria, and any one transaction has a value for each of them: how the customer asked for it, who initiated it, and how it moves funds.

Based on commerce type

The commerce type describes how the customer asked for the transaction:

Based on transaction initiation

Every transaction also has an initiator:

An MIT is only possible against a card the cardholder has agreed you may re-use, so the rules for it are set out in Saving cards for reuse.

Based on movement of funds

The rest of this page describes the transaction types themselves, which differ in how they move funds:

Payment

Payments will authorise and capture the funds for settlement in one step. This is a primary transaction.

Pre-authorisation

This transaction type involves two steps to process a payment; This is useful when you want authority for a payment, but not to transfer the funds right away. Pre-authorisation will reduce Cardholder’s available funds, but not their balance. Depending on card type and scheme, you have up to 7 days to either capture or reverse the pre-authorisation. This is a primary transaction.

Pre-authorisation Capture

After submitting an authorisation, funds can be requested for settlement using the Capture request. By default, only the full amount of the original authorisation can be captured. If you have a case where you would need to capture a lower amount let us know and the configuration for that can be applied at boarding or a later date. The capture request will need to include the reference for the original authorisation. This is a secondary transaction.

Captured authorisations can be Refunded as required using the Refund request.

Pre-authorisation Reversal

Where an authorisation has been submitted and the funds do not need to be settled, a Cancel request can be submitted to release the authorisation from the customer’s card. The cancel request will need to include the reference for the original authorisation. This is a secondary transaction.

Refund

Refunds allow you to return funds to the customer’s original payment method. Use the Refund request to return the full original sales amount or a smaller amount. The request requires the reference for the original payment.

Account Verification

Similar to a payment but with no amount, an Account Verification confirms that the card details are valid and could be used for an authorisation. Usually used to either start a subscription without an initial payment, or to check stored card details are still valid before performing a new payment with them. Does not check the Cardholder’s balance at all. This is a primary transaction.

Payout

The Payout request allows credits to be made to a customer’s payment method without referencing an original transaction. This is typically used by gaming merchants who need to give their customers their winnings. Visa and Mastercard have their own terminology. Visa Original Credit (OCT) covers gaming payouts but also money transfers. Mastercard Payment of Winnings (PoW) is for gaming payouts. This is a primary transaction.

Repeat

Repeats allow payments to be taken on a recurring or instalment basis. The submission of a recurring or instalment payment is simplified by using the Repeat request. The very first payment or authorisation request needs to be flagged as a repeatable transaction and the repeats themselves will need to reference the original.

Recurring and instalment payment types must be initiated and managed by the merchant along with any scheduling logic associated with these types of transaction. You can send a request every time you want to do a repeat payment, or set up a schedule using the Scheduler.

As this transaction type stores the customer card for further use, see more details about your obligations in Saving cards for reuse. When you submit initial and subsequent recurring or instalment payments this way, we automatically classify the transaction under the Stored Credentials Framework, and store and re-present the scheme reference associated with the card storage if one is returned to us.

Every transaction that initiates a recurring or instalment series must state exactly what the continuous authority agreement with the cardholder is, in the continuousAuthorityAgreement section of the request. If those details are not provided, 3D Secure 2 is not available for the transaction. The way repeats themselves are submitted is unaffected.

Recurring

Repeats allow payments to be taken on a recurring basis, such as a subscription for goods or services. The submission of a recurring payment is simplified by using the Repeat request. The first request can be a payment, pre-authorization or account verification that is flagged as a recurring transaction and the repeats themselves will need to reference the original transaction. The initial recurring transaction is a primary transaction, subsequent recurring transactions are secondary transactions.

The continuous authority agreement for a recurring series is described by the expiry and minFrequency fields.

Any subsequent recurring payment you send can instead be processed as an instalment payment by specifying the instalment flag on that Repeat request.

Instalments

Repeats allow payments to be taken on an instalment basis, such as paying off a loan. The submission of an instalment payment is simplified by using the Repeat request. The first request can be a payment, pre-authorization or account verification that is flagged as an instalment transaction and the repeats themselves will need to reference the original transaction. The initial instalment transaction is a primary transaction, subsequent instalment transactions are secondary transactions.

The continuous authority agreement for an instalment series is described by the expiry, minFrequency and numberOfInstalments fields.

Any subsequent instalment payment you send can instead be processed as a recurring payment by specifying the recurring flag on that Repeat request.