Pre-authorisation
Preauthorization (aka reservation)
Initial preauthorization
Pre-authorizations (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-authorization ID. Dummy value will be sent in request message as it is required in nexo IS and MUG. IPG will ignore it and fill it in response message with the Pre-authorization ID. |
Tx/RcptTxId | Pre-authorization ID returned by IPG 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 | Pre-authorization ID returned by IPG in original pre-authorization 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 pre-authorization or linked refund for completed pre-authorization |
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 | Pre-authorization expiry date included in approved Balance Enquiry responses |
Envt/Card/MskdPAN | Masked card data used in original pre-authorization will be returned by IPG 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' - pre-authorization increment or decrement, 'PRES' - post-authorization/payment after reservation, 'RFND' - refund |
Update preauthorization
Update Pre-authorizations (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 | Pre-authorization ID returned by IPG in original pre-authorization response as RecipientTransactionIdentification (Tx/RcptTxId) |
Tx/TxCaptr | False |
Tx/TxDtls/AmtQlfr | Use value 'INCR' for preauthorization increment Use value 'DECR' for preauthorization decrement |
Workflow:
Post-authorization (aka pre-authorization 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 | Pre-authorization ID returned by IPG in original pre-authorization response as RecipientTransactionIdentification (Tx/RcptTxId) |
Tx/TxCaptr | True |
Tx/OrgnlTx contatining: | Tx/RcptTxId = Pre-authorization ID returned by IPG in original pre-authorization response as RecipientTransactionIdentification (Tx/RcptTxId)Tx/SaleRefId = Pre-authorization ID returned by IPG in original pre-authorization response as Tx/RcptTxIdTx/TxId = Value sent in original pre-authorization requestTx/TxTp = RESATx/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 pre-authorization 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 pre-authorization 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-authorization ID returned by IPG in original pre-authorization 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
All financial transactions can be cancelled using the "Cancel Last" service on the POI. For pre-authorization completion, "Cancel Last" has been enhanced with a balance inquiry step. This is needed because pre-authorization 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 pre-authorization has not been settled, as in this case the cancellation should not be allowed. Instead, the merchant could initiate a refund and another pre-authorization to hold the requested amount on the cardholder balance.
Responses from CAP to the inquiry:
- Open
- Closed (Captured) - Declined: 50719 (Authorization captured)
- Settled - Declined: 50730 (Authorization settled)
- Invalid
- Expired
Workflow:
Updated 5 months ago
