Incremental authorisations for Payment Pages

  Last updated: 

 

An incremental authorisation is used to increase the total amount to be paid by the customer, if it is not known at time of authorisation. It is an additional request submitted using MyST, which can be used to seek authorisation for additional funds, once the full amount is known. The total amount to be paid by the customer is the value from the original AUTH, in addition to amounts associated with the incremental authorisations.

 

Requirements

  You can only process incremental authorisations with Visa-branded cards.

  Incremental authorisations are supported for merchants with a Trust Payments acquiring account and supported MCC codes

Your account must be assigned one of the following Merchant Category Codes (MCC) to be eligible to use incremental authorisations:

3351-3999, 4111, 4112, 4121, 4131, 4411, 5812, 5813, 7011, 7033, 7394, 7512, 7513, 7519, 7996, 7999

If you are using a different acquiring bank, you will need to contact our Support Team to check this feature is supported before proceeding.

  A previously-authorised payment is required

Incremental authorisations require a parent pre-authorisation that meets the following criteria:

  • Parent AUTH MUST have accounttypedescription= “ECOM” or “MOTO”.
  • Parent AUTH MUST have authmethod = “PRE”.
  • Parent AUTH MUST have settlestatus = 0 (pending automatic settlement) or 1 (pending manual settlement).

 

Processing incremental authorisations

To process an incremental authorisation, you will need to sign in to MyST and perform a “Re-auth” on the original transaction, with the Auth method set to “INCREMENTAL”, using the drop-down provided.

Incremental authorisations must adhere to the following additional requirements:

  • New incremental authorisations must be processed using the same card as the parent AUTH.
  • New incremental authorisations must be processed using the same currency as the parent AUTH.
  • New incremental authorisations must be processed using the same acquirer as the parent AUTH.
  • New incremental authorisations cannot be processed using a parent AUTH that has been settled or cancelled.

CO16-EN.png

  Alternatively, incremental authorisations can be processed by submitting additional AUTH requests using our Webservices API.

 

Settlement and updates

Relationship with the parent transaction

The initial payment and associated child incremental authorisations are linked together on our system. Using MyST, you can view any incremental authorisations associated with a transaction by clicking the “Related transactions” tab displayed when viewing a transaction’s details.

CO17-EN.png

 

Updating the parent transaction

Because of the connection shared between the initial payment and child incremental authorisations, the following behaviour is to be expected:

  • If the settleduedate and/or settlestatus on the initial payment is updated, all child incremental authorisations are updated automatically to match.
  • If the initial payment is settled, all child incremental authorisations are also settled automatically.
  • If the initial payment is cancelled, all child incremental authorisations are also cancelled automatically.
  • If the initial payment is suspended, all child incremental authorisations are also suspended automatically.

Updates can be performed using MyST or by submitting a request using our Webservices API.

 

Updating incremental authorisations

The only permitted updates for incremental authorisations are:

  • Update the settlestatus to “3”, to cancel the incremental authorisation.
  • Update the settleamount to be a lower value than was authorised for the incremental authorisation.
  • Update the value of the orderreference.

Updates can be performed using MyST or by submitting a request using our Webservices API.

  Rules that are processed on incremental authorisations can only perform the updates listed above.

 

Security considerations

  Incremental authorisations bypass any fraud, duplicate and Security Policy checks that can be run on regular payments. If such checks cause the parent AUTH to be suspended or cancelled, this will also suspend / cancel any child incremental authorisations.

 

Refunds

To refund the order in full, the initial payment AND all child incremental authorisations must be refunded separately.

  As with standard payments, you can only refund incremental authorisations when they have been settled (settlestatus = 100). If an incremental authorisation has not been settled, you can update the settlestatus to defer or cancel settlement.

Refunds can be performed using MyST or by submitting a request using our Webservices API.

 

Additional notes

  • Billing and delivery details can differ between incremental authorisations and their parent AUTH.
  • Incremental authorisations do not support DCC.
Was this article helpful?
0 out of 0 found this helpful