Five different operations can be performed using the Authorisation command. The uses of each are outlined below.
Setting the PaymentType parameter to Auth will process a simple authorisation request to reserve funds on the cardholder’s card. It should be noted that a secondary request must then be made to Capture the transaction, either individually or as part of a batch. If this step is not taken within 7 consecutive days the transaction will not be submitted for clearing, and the authorisation will be automatically removed by the issuing bank.
Authorisation and Capture in a single API operation is supported when the PaymentType is set to Payment. There is no need to send a secondary request to capture the authorisation; it is automatically batched and submitted for processing at the end of the day.
Sending the PaymentType parameter as RecurringPayment indicates that the transaction is one in a series of regular payments. Where set, and a reference to an original authorisation, payment or verify is given in the ParentTransactionId parameter, it is not necessary to include card data in the request. The parent transaction is used to retrieve the stored card details. The card details may alternatively be sent in every request (except the CVV, which must not be stored).
If using RecurringPayment, the authorisation will be processed according to the default recurrence settings on the Merchant Number requested. You can override the default by passing a RecurrenceType.
Please note that Recurring Payments must be specifically configured on your Merchant Numbers. Please contact the Customer Services team if you are unsure about your account set-up.
Passing PaymentType as Verify offers the opportunity to confirm that the card exists, is valid for use, that address data (where provided) passes AVS checks and that the consumer can authenticate via 3DS, without decrementing the cardholder’s balance. This is also known as a zero-value authorisation.
Setting the PaymentType parameter to RecurringAuth indicates that the transaction is one in a series of regular payments and will process an authorisation request to reserve funds on the cardholder’s card. Where set, and a reference to an original authorisation, payment or verify is given in the ParentTransactionId parameter, it is not necessary to include card data in the request. The parent transaction is used to retrieve the stored card details. The card details may alternatively be sent in every request (except the CVV, which must not be stored).
It should be noted that a secondary request must then be made to Capture the transaction, either individually or as part of a batch. If this step is not taken within 7 consecutive days the transaction will not be submitted for clearing, and the authorisation will be automatically removed by the issuing bank.
You can call Authorisation with Is3DS set to True, in which case you must also provide the following data which will have been provided from 3D-Secure Authentication output from your own Merchant Plug In:
Token is a unique reference to a card number. An authorisation request may include a card number or the corresponding token. Setting the ReturnToken flag in authorisation request will return the token in the response.
Sending a Capture request following an Authorisation is necessary to received money from the cardholder, unless the PaymentType is Payment or Recurring Payment (these are automatically batched for processing).
The Capture action ensures that a previous Authorisation is included in the next processing batch and is submitted to the scheme for settlement. Unless captured, an authorisation will automatically expire after a number of days as determined by the issuing bank. All capture requests are for the full transaction amount; partial capture is not supported at present.
Used to request a Credit to the payment card associated with a previous authorisation or payment. Alternatively, for Visa branded cards, you can send the full Primary Account Number (PAN), or the tokenized value for the
If you wish to refund the money to a cardholder with reference to a previous authorisation/capture or payment, you should use the Refund command.
Note: Your Merchant Account must be set up to accept credit transactions (Visa OCT and Mastercard CFT). Please contact customer services if you are uncertain.
Credit transactions are only supported for the following MCC’s:
• 7995 - Gambling
• 6010 - Financial Institutions – Manual Cash Disbursements
• 6011 – Financial Institutions – Automated Cash Disbursements
• 6012 - Financial Institutions – Merchandise, Services, and Debt Repayment
• 6300 - Insurance Sales, Underwriting, and Premiums
• 6399 - Insurance, Not Elsewhere Classified
• 8999 – Professional Services (Not Elsewhere Classified)
• 5262 – Marketplaces
A refund request can be sent for a captured authorisation or payment originally secured via the Payments API. Partial refunds are supported, but the amount is capped to the value of the parent transaction. In circumstances where a greater amount must be returned to the cardholder, the Credit command should be used.
Verify 3-D Secure command is used to check whether a customer’s card is enrolled in 3DSecure. This can eliminate the need to send the card account information for 3DS Auth if the card is not enrolled in the service.
Used to request the voiding of an authorisation previously obtained using the Authorisation command. The request will be accepted only if the authorisation has NOT been captured. After an Authorisation has been captured, the Refund command should be used.
Used to return details of that card such as scheme (Visa, Mastercard or American Express), type (credit, debit, corporate etc.) and Issuer (where known). The request should include at least the first 6 digits but can be a full Primary Account Number (PAN)/card number, or any combination between 6 and full PAN.