Preauthorisation

Preauthorisation (aka reservation)

Initial preauthorisation

Preauthorizations (also referred to as "Initial Reservations") are implemented using AcceptorAuthorisationRequest/Response containing:

Tag	Description
`Tx/TxTp`	Use value 'RESA'
`Tx/SvcAttr`	Use value 'IRES'
`Tx/SaleRefId`	Pre-authorisation ID. Dummy value will be sent in request message as it is required in nexo IS and MUG. The Gateway will ignore it and fill it in the response message with the Preauthorisation ID.
`Tx/RcptTxId`	Preauthorisation ID returned by the Gateway in response message. Will not be set in request message.

Balance inquiry

Balance Enquiry transactions can be optionally triggered before performing Update or Completion of an existing pre-authorization. Balance inquiries are implemented using AcceptorAuthorisationRequest/Response.

Request parameters:

Tag	Description
`Hdr/MsgFctn`	Use value 'AUTQ'
`Tx/TxTp`	Use value 'BALC'
`Tx/SaleRefId`	Preauthorisation ID returned by the Gateway in original preauthorisation response as RecipientTransactionIdentification (`Tx/RcptTxId`)
`Tx/TxCaptr`	False
`AddtlTxData`	Use value '/SuccessOnCompletedPreauth' if you expect the balance inquiry to be successful in case of a completed preauthorisation or linked refund for a completed preauthorisation

Response parameters:

Tag	Description
`TxRspn/Bal`	Current reserved amount. Will only be included in approved Balance Enquiry responses (when reservation is still valid).
`Tx/TxDtls/VldtyDt`	Preauthorisation expiry date included in approved Balance Enquiry responses
`Envt/Card/MskdPAN`	Masked card data used in original preauthorisation will be returned by the Gateway in approved Balance Enquiry responses.
`TxRspn/AuthstnRslt/ RspnToAuthstn/AddtlRspnInf`	Key value pairs containing additional information about the transaction. Format: key1=value1;key2=value2;....keyn=valuen Possible keys: 'DCCAccepted' with values 'true' or 'false' - indicates whether dynamic currency conversion was applied or not 'LastTxType' (available in May 2024) with the following values: 'IRES' - initial pre-authorization, 'URES' - preaauthorisation increment or decrement, 'PRES' - postauthorisation/payment after reservation, 'RFND' - refund

Update preauthorisation

Update Preauthoriaations (also referred to as "Update Reservations") are implemented using AcceptorAuthorisationRequest/Response.

🚧
Please note that some authorization systems don't support decrements, only cancellations of previous increments:

preauth +100 EUR

increment + 10 EUR

increment + 20 EUR

For above example allowed decrement amount could be 20, 30 or full void,

Request parameters:

Tag	Description
`Tx/TxTp`	Use value 'RESA'
`Tx/SvcAttr`	Use value 'URES'
`Tx/SaleRefId`	Preauthorisation ID returned by the Gateway in original preauthorisation response as RecipientTransactionIdentification (Tx/RcptTxId)
`Tx/TxCaptr`	False
`Tx/TxDtls/AmtQlfr`	Use value 'INCR' for preauthorisation increment Use value 'DECR' for preauthorisation decrement

Workflow:

Postauthorisation (aka preauthorisation completion)

Payment Completions are implemented using AcceptorCompletionAdvice/Response containing:

Tag	Description
`Tx/TxTp`	Use value 'RESA'
`Hdr/MsgFctn`	Use value 'FCMV/FCMK'
`Tx/SvcAttr`	Use value 'PRES'
`Tx/SaleRefId`	Preauthorisation ID returned by the Gateway in original preauthorisation response as RecipientTransactionIdentification (Tx/RcptTxId)
`Tx/TxCaptr`	True
`Tx/OrgnlTx` contatining:	`Tx/RcptTxId` = Preauthorisation ID returned by the Gateway in original preauthorisation response as RecipientTransactionIdentification (Tx/RcptTxId) `Tx/SaleRefId` = Preauthorisation ID returned by the Gateway in original preauthorisation response as Tx/RcptTxId `Tx/TxId` = Value sent in original preauthorisation request `Tx/TxTp` = RESA `Tx/SvcAttr` = IRES

Workflow:

Reservation cancellation

A reservation may be cancelled within its validity period. The reservation cancellation is not a reversal of an individual transaction in the preauthorisation set, it is rather a completely closure of the aggregated reservation, meaning that is does not allow any subsequent related processing for that particular reservation. Terminals should allow triggering a reservation by preauthorisation ID entry, without any additional card data input. The actual cancellation message will be preceded by a Balance Enquiry that will retrieve the reservation details in the same way as they are retrieved for incremental and completion processing. The details around the Balance Enquiry message are presented in section 6.3.2.

Reservation Cancellation is implemented using AcceptorCompletionAdvice/Response containing:

Tag	Description
`Tx/TxTp`	Use value 'RESA'
`Hdr/MsgFctn`	Use value 'RVRA/RVRR'
`Tx/SvcAttr`	Use value 'IRES'
`Tx/SaleRefId`	Pre-authorisation ID returned by the Gateway in original preauthorisation response as RecipientTransactionIdentification (`Tx/RcptTxId`)
`Tx/TxCaptr`	False
`Tx/OrgnlTx`	NOT PRESENT
`Tx/TxSucss`	True
`Tx/Rvsl`	True
`Tx/FailrRsn`	Use value 'CUCL'
`Tx/TxDtls/TtlAmt`	Total reserved amount. Value should be retrieved in the preceding Balance Enquiry message.

Completion cancellation

For all financial transactions it is recommended to offer a "Cancel Last" service on the POI. For preauthorisation completion, "Cancel Last" service should bbe combined with a balance inquiry step. This is useful because preauthorisation related transactions can be updated on different devices, so it is always good to perform an inquiry step to retrieve the current status of the reservation. It is needed to make sure that the preauthorisation has not been settled, as in this case the cancellation should not be allowed. Instead, the merchant could initiate a refund and another preauthorisation to hold the requested amount on the cardholder balance.

Possible responses from the Gateway to the inquiry:

Open
Closed (Captured) - Declined: 50719 (Authorization captured)
Settled - Declined: 50730 (Authorization settled)
Invalid
Expired

Workflow: