Processing pre-authorisations

A pre-authorisation is used to seek authorisation for a transaction and reserve the funds on the customer’s account, in cases where the final amount to be debited from the customer is not known at time of authorisation. By default, the funds reserved by pre-authorisations are typically settled within 24 hours, but if required, they can be deferred for up to 31 days. If the transaction is not settled within this time-frame, we will automatically cancel the transaction and the funds will be released back into the customer’s bank account.

  Settlement can be deferred by up to 31 days following authorisation.

  Prior to settlement, the final settlement amount can be updated to a lower value.

  Prior to settlement, the transaction can be cancelled.

 

Pre-authorisations are most useful when employed in the following scenarios:

  • The final amount to be debited from the customer is not yet known:
    • You can update the final settle amount to be a lower value than the amount originally authorised.
    • For those assigned with supported merchant category codes, Visa supports the processing of incremental authorisations in order to increase the final settle amount to a higher value than was originally authorised.
  • The settlement time is not yet known:
    • The funds can be settled for up to 31 days after authorisation.
    • For those assigned with supported merchant category codes, Mastercard supports the processing of split shipments, to settle parts of the authorised funds as and when goods/services have been delivered, over a period of 31 days.
  • Cancelling an order:
    • You can cancel pre-authorisations without incurring penalties or additional charges from Mastercard or Visa.

 

Requirements

  You can only process pre-authorisations with Mastercard and Visa-branded cards.

  Mastercard Europe have mandated that Mastercard and Maestro transactions processed with certain European acquiring banks must be flagged as either pre-authorisation or final authorisation. Such transactions are subject to acquirer-specific conditions.

Failure to adhere to these conditions may incur a fine from Mastercard.
For full terms and conditions, please contact your acquiring bank.

 

Processing pre-authorisations

  Default behaviour

By default, authorisations are processed as final authorisations in cases where a distinction is required by the participating acquirer. You can change this default behaviour to submit pre-authorisations, by contacting our Support Team. Alternatively, you can override the default behaviour on a transaction-by-transaction basis by following the instructions below.

If you are not sure whether your site has been configured to process pre-authorisations or final authorisations, click here to learn how to check using MyST.

Payment Pages

Request example

  • If you need to override the site reference’s default auth method to process a pre-authorisation, include the authmethod in your POST to Payment Pages as shown in the example below.
  • The settleduedate can optionally be included to specify a preferred settlement date (format: YYYY-MM-DD) for the transaction. Pre-authorisations can be deferred for up to 31 days.
<input type="hidden" name="authmethod" value="PRE">
<input type="hidden" name="settleduedate" value="2022-01-28">

Site security considerations:

  • If including the authmethod in your POST, the value of the field authmethod needs to be included in the correct position within the string used to generate your request site security hash. Failure to do so will result in the customer being shown an “Invalid details” error message. Click here for further information on site security, and the default order of fields in the string.
  • By default, settleduedate is not included in the site security hash, but we recommend changing your site security configuration to require this field, to prevent unauthorised third parties from modifying the settlement date during the payment session. Please contact our Support Team for assistance.
API

Request example

  • If you need to override the site reference’s default auth method, you will need to ensure the payload submitted within your JWT contains authmethod with value "PRE", as shown in the example below.

    • The authmethod field can only be submitted in THREEDQUERY and AUTH requests.
    • If a value for the authmethod field is submitted to the acquirer during authorisation, it will always be returned within the response.
  • The settleduedate can optionally be included to specify a preferred settlement date (format: YYYY-MM-DD) for the transaction. Pre-authorisations can be deferred for up to 31 days.
JS Library payload Mobile SDK payload
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"requesttypedescriptions":["THREEDQUERY","AUTH"],
"authmethod":"PRE",
"settleduedate":"2022-01-28"
},
"iat":1559033849,
"iss":"jwt.user"
}

 

Updating deferred transactions

You can update deferred pre-authorisations prior to settlement. Supported updates include:

  • Updating the final settle amount to be a lower value than originally authorised by the issuing bank.

  • Updating the settle due date, providing the date is within 31 days from the time the transaction was authorised.

      Updating the settle due date to today's date will instruct Trust Payments to settle the transaction in the next batch sent to your acquiring bank (this typically occurs within 24 hours).
  • Cancelling the transaction by updating the settle status to 3.

To process an update, you can either use MyST or submit a TRANSACTIONUPDATE request using our Webservices API.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request