External Host Interface Integration Guide

9. Authorization-Related Messages

Authorization messages include authorization decisioning messages, authorization repeats, and authorization advice messages.

Authorization decisioning messages ask your system to make or return a real-time authorization decision. Authorization advice messages notify your systems of an authorization-related event that has already occurred or was generated outside the standard real-time authorization request flow.

Updated 1 minute ago

On this page

9.1 Authorization decisioning identifiers 9.2 Authorization decisioning flow 9.3 Process authorization decisioning messages 9.4 Important fields for authorization decisioning 9.5 Balance and authorization impact 9.6 Required response 9.7 Request example 9.8 Response examples 9.9 Authorization repeats 9.10 Authorization repeat matching criteria 9.11 Authorization advice messages 9.12 Authorization advice matching criteria 9.13 Authorization advice response and examples 9.14 Authorization advice implementation notes 9.15 Authorization duplicate or retry handling 9.16 Incremental authorizations Next steps

9.1 Authorization decisioning identifiers

Authorization messages are identified using the EHI fields included in the forwarded payload.

Field	Expected value	Description
`MTID`	0100	Identifies the message as an authorization request.
`Txn_Type`	A	Identifies the transaction as an authorization.
`Txn_Stat_Code`	A, when present	Indicates authorization transaction status context.
`Authorised_by_GPS`	N or Y	Indicates whether authorization was performed before the message reached the external host flow.
`SendingAttemptCount`	Varies	Indicates the sending attempt count and may help identify repeated delivery attempts.

For this integration, your system should treat authorization messages as decisional when a response is required by the EHI flow.

9.2 Authorization decisioning flow

Authorization decisioning flow

Platform

Payblr

System

Your Systems

1. Forward original EHI authorization payload

Authorization

Payblr forwards the original EHI authorization payload to your configured endpoint.

PayblrYour Systems

2. Validate Payblr request signature and timestamp

Your system validates Payblr's signature and request timestamp before processing.

Your SystemsprocessesYour Systems

3. Identify authorization using MTID and Txn_Type

Authorization

Your system identifies the authorization message, checks duplicate status, and identifies the cardholder using Token.

Your SystemsprocessesYour Systems

4. Evaluate business rules

Your system evaluates balance, fees, merchant data, and business rules to decide approve, decline, or partial approval.

Your SystemsprocessesYour Systems

5. Return authorization response

Authorization

Your system returns the authorization response to Payblr.

Your SystemsPayblr

6. Relay response through transaction flow

Payblr relays the response returned by your system through the transaction flow.

PayblrprocessesPayblr

sequenceLaneCenter(index, columnCount)

9.3 How your system should process authorization decisioning messages

When your system receives an authorization message, the message should be processed in the synchronous authorization path.

Validate Payblr’s integration headers, signature, timestamp, and raw payload before processing.
Identify the message as an authorization using MTID=0100 and Txn_Type=A.
Check whether the message was already received or processed using the applicable EHI identifiers.
Identify the card, cardholder, or account using Token and your internal mapping.
Calculate the total transaction impact using billing amount, transaction amount, fees, pads, and any applicable adjustments.
Evaluate available balance, account status, fraud rules, merchant rules, country rules, velocity rules, and other client-side business controls.
Determine whether the transaction should be approved, declined, or partially approved.
Return the required authorization response within the configured processing window.
Store the request, response, decision outcome, transaction identifiers, and x-correlation-id for audit, duplicate handling, and reconciliation.

9.4 Important fields for authorization decisioning

The following fields are commonly useful when evaluating an authorization request. Your system may use additional fields depending on your program rules and internal processing logic.

Field category	Fields	Purpose
Message type	`MTID`, `Txn_Type`, `Txn_Stat_Code`	Identify the transaction as an authorization message.
Transaction identifiers	`TXn_ID`, `Txn_ID`, `traceid_lifecycle`, `Traceid_Message`, `Traceid_Original`, `Trans_link`	Support duplicate handling, lifecycle tracing, and transaction matching.
Card/token data	`Token`, ProductID, SubBIN	Identify the card, cardholder, product, or internal account mapping.
Amount and currency	Txn_Amt, `Txn_CCy`, Bill_Amt, Bill_Ccy, Settle_Amt, Settle_Ccy	Determine the transaction amount, billing impact, and settlement context.
Balance data	ActBal, Avl_Bal, BlkAmt	Provide balance-related context included in the EHI payload.
Fee and padding fields	Fee_Fixed, Fee_Rate, Dom_Fee_Fixed, Dom_Fee_Rate, Non_Dom_Fee_Fixed, Fx_Fee_Fixed, Fx_Fee_Rate, Other_Fee_Amt, FX_Pad, MCC_Pad	Help calculate total transaction impact when applicable.
Merchant data	MCC_Code, MCC_Desc, Merch_ID_DE42, Merch_Name_DE43, Merch_Country, Txn_Ctry	Support merchant, country, MCC, and fraud/business rule checks.
POS data	POS_Data_DE22, POS_Date_DE13, POS_Termnl_DE41, POS_Time_DE12, POS_Date_DE14	Provide point-of-sale and transaction entry context.
Authorization reference	`Auth_Code_DE38`, `Ret_Ref_No_DE37`, Proc_Code, `Resp_Code_DE39`, Status_Code	Support authorization processing, matching, and investigation.
Network/reference data	Network_Transaction_ID, SchemeTransactionIdentifier, Acquirer_Reference_Data_031	Support lifecycle tracking, matching, and reconciliation.
Authentication data	AuthenticationCurrency, AuthenticationAmountUpper, AuthenticationMerchantHash	Support 3DS/SCA validation when applicable.
Retry/delivery data	`SendingAttemptCount`	Helps identify repeated delivery attempts.

9.5 Balance and authorization impact

Your system are responsible for calculating the total authorization impact and deciding whether the transaction should be approved, declined, or partially approved.

Scenario	Expected handling by your system
Authorization approved	Reserve or block the approved amount and any applicable fees according to your ledger rules.
Authorization declined	Do not block funds. Store the decline reason and response.
Partial approval	Reserve or block only the approved amount, when partial approval is supported.
Duplicate authorization	Do not apply balance, block/reserve, or ledger impact again. Return the same logical response as the original processing.
Authorization later reversed	Release or adjust the related blocked amount when the reversal message is received.
Presentment later received	Match the presentment to the authorization and post or reconcile the transaction according to your ledger rules.

9.6 Required response for authorization decisioning messages

For authorization messages, your system must return an authorization response using the expected EHI response structure.

The required response fields for authorization messages include:

Acknowledgement – Required. Indicates that your system received and processed the message.
Responsestatus – Required. Indicates the authorization decision returned by your system.

Typical authorization response values include:

Approve – Return Acknowledgement = 1 and Responsestatus = 00.
Decline – Return Acknowledgement = 1 and Responsestatus = 05.
Partial approval – Return Acknowledgement = 1 and Responsestatus = 10 when partial approval is supported and applicable.

A controlled decline is preferred over a timeout or unhandled error when your systems cannot approve the transaction. This allows the transaction to be handled predictably instead of failing because of a missing or delayed response.

9.7 Request example

The following example shows a Visa authorization request in the original EHI JSON format.

Payblr forwards the EHI payload to your system without transforming the transaction payload. Your system should expect the original message structure, field names, field casing, populated values, and empty elements to be preserved.

This example is intended to show the size and structure of the payload your system may receive. Your implementation should not depend only on the fields shown as populated in this example. Additional fields may be present, and some fields may be empty when they are not applicable to the transaction.

{
  "Acquirer_Country": "GBR",
  "FxProviderCardholderRate": 0.0,
  "POS_Date_DE13": "00000000",
  "Traceid_Message": "VIS1-20221219-002353117950020",
  "Visa_POS_Data_DE60": "020000000000",
  "Network_Transaction_ID": "0002353117950020",
  "DCC_Indicator": 0,
  "multi_part_txn": 0,
  "multi_part_txn_final": 0,
  "auth_type": "0",
  "auth_expdate_utc": "2022-12-27 07:28:36.045",
  "Merch_Name": "Travel Like A Pro",
  "Merch_Country": "HRV",
  "GPS_POS_Capability": "00001001000000000000000100010010001000000001130C0",
  "GPS_POS_Data": "9968000800000Nx000NNNNNU0NUUXXU",
  "Response_Source_Why": 0,
  "Message_Why": 0,
  "traceid_lifecycle": "VIS1-20221219-002353117950020",
  "Balance_Sequence": 114,
  "Balance_Sequence_Exthost": 0,
  "Acquirer_id_DE32": "0844622180",
  "ActBal": 10001.0000,
  "Auth_Code_DE38": "143088",
  "Avl_Bal": 10001.0000,
  "Bill_Amt": 1.0000,
  "Bill_Ccy": "826",
  "BlkAmt": 0.0000,
  "FX_Pad": 0.0000,
  "Fee_Fixed": 0.0000,
  "Fee_Rate": 0.0000,
  "MCC_Code": "4111",
  "MCC_Desc": "Commuter Transport, Ferries",
  "MCC_Pad": 0.0000,
  "Merch_ID_DE42": "4111",
  "Merch_Name_DE43": "Travel Like A Pro HR",
  "POS_Data_DE22": "0110",
  "Proc_Code": "200000",
  "Resp_Code_DE39": "00",
  "Ret_Ref_No_DE37": "235303502517",
  "Settle_Amt": 1.0000,
  "Settle_Ccy": "826",
  "Status_Code": "00",
  "Token": 107419774,
  "Trans_link": "221219002517622180",
  "Txn_Amt": 1.0000,
  "Txn_CCy": "826",
  "Txn_Ctry": "HRV",
  "Txn_Desc": "Travel Like A Pro HR",
  "Txn_GPS_Date": "2022-12-19 07:28:37.526",
  "TXn_ID": 6155805913,
  "Txn_Stat_Code": "A",
  "TXN_Time_DE07": "1219072835",
  "Txn_Type": "A",
  "Authorised_by_GPS": "N",
  "CU_Group": "DEF_PV",
  "InstCode": "TEST",
  "MTID": "0100",
  "ProductID": 99883,
  "SubBIN": 44622180,
  "TLogIDOrg": 0,
  "VL_Group": "MLMS_PV_GB",
  "Dom_Fee_Fixed": 0.0000,
  "Non_Dom_Fee_Fixed": 0.0000,
  "Fx_Fee_Fixed": 0.0000,
  "Other_Fee_Amt": 0.0000,
  "Fx_Fee_Rate": 0.0000,
  "Dom_Fee_Rate": 0.0000,
  "Non_Dom_Fee_Rate": 0.0000,
  "PIN": "0",
  "SendingAttemptCount": 0
}

9.8 Response examples

Approval response

{
  "Acknowledgement": "1",
  "Responsestatus": "00"
}

Decline response

{
  "Acknowledgement": "1",
  "Responsestatus": "05"
}

Partial approval response, when applicable

{
  "Acknowledgement": "1",
  "Responsestatus": "10"
}

9.9 Authorization repeats

Authorization repeat messages may be received when an authorization request is repeated through the EHI transaction flow.

As with all EHI messages, Payblr forwards this payload without transformation. Your system should process the message using the original EHI fields and return the required response for the message type.

Authorization repeats are important because your system must avoid duplicate balance, block/reserve, or ledger impact when the repeat relates to an authorization that was already processed.

Authorization repeat messages are identified using the original EHI fields included in the forwarded payload.

Field	Expected value	Description
`MTID`	0101	Identifies the message as an authorization repeat.
`Txn_Type`	A	Identifies the transaction as an authorization.
`Token`	Varies	Identifies the card token associated with the transaction.
`traceid_lifecycle`	Varies	Helps match the repeat message to the original authorization.
`Trans_link`	Varies	Helps match the repeat message to the original authorization.
`Ret_Ref_No_DE37`	Varies	Retrieval reference number used for matching.
`TXn_Time_DE07`	Varies	Transmission date and time used for matching.
`POS_Termnl_DE41`	Varies	POS terminal identifier used for matching.

Authorization repeat flow

Platform

Payblr

System

Your Systems

1. Forward original EHI authorization repeat payload

Authorization repeat

Payblr forwards the original EHI authorization repeat payload to your configured endpoint.

PayblrYour Systems

2. Identify repeat using MTID=0101 and Txn_Type=A

Your system validates the request and identifies the message as an authorization repeat.

Your SystemsprocessesYour Systems

3. Search for original MTID=0100 authorization

Authorization repeat

Your system searches for the original 0100 / A authorization using EHI matching criteria.

Your SystemsprocessesYour Systems

4. Process repeat

If found, treat as same authorization. If not found, process as new authorization.

Your SystemsprocessesYour Systems

5. Return authorization response

Authorization repeat

Your system returns the original response when matched, or a new authorization response when not found.

Your SystemsPayblr

6. Relay response through transaction flow

Payblr relays the response returned by your system through the transaction flow.

PayblrprocessesPayblr

sequenceLaneCenter(index, columnCount)

When your system receive an authorization repeat, they should:

Validate Payblr’s integration headers, signature, timestamp, and raw payload before processing.
Identify the message as an authorization repeat using MTID=0101 and Txn_Type=A.
Search for the original authorization request using the EHI matching criteria.
If the original 0100 / A authorization is found, treat the repeat as the same authorization.
If the original authorization is found, do not block, reserve, post, or adjust funds again.
Return the same authorization response returned for the original 0100 / A authorization.
If the original authorization is not found, process the repeat as a new authorization request.
Store the repeat message, matching result, response returned, and x-correlation-id for audit and reconciliation.

9.10 Authorization repeat matching criteria

Your system should match the 0101 / A authorization repeat to the original 0100 / A authorization request using the original EHI fields.

Incoming message	Match to	Matching criteria
`0101 / A authorization repeat`	`Original 0100 / A authorization request`	`OTHER.MTID = "0100"`
`0101 / A authorization repeat`	`Original 0100 / A authorization request`	`OTHER.traceid_lifecycle = THIS.traceid_lifecycle`
`0101 / A authorization repeat`	`Original 0100 / A authorization request`	`OTHER.Trans_link = THIS.Trans_link`
`0101 / A authorization repeat`	`Original 0100 / A authorization request`	`OTHER.Ret_Ref_No_DE37 = THIS.Ret_Ref_No_DE37`
`0101 / A authorization repeat`	`Original 0100 / A authorization request`	`OTHER.Txn_Time_DE07 = THIS.Txn_Time_DE07`
`0101 / A authorization repeat`	`Original 0100 / A authorization request`	`OTHER.POS_Termnl_DE41 = THIS.POS_Termnl_DE41`
`0101 / A authorization repeat`	`Original 0100 / A authorization request`	`OTHER.Token = THIS.Token`

Processing outcome

Matching result	Required handling
`Original 0100 / A authorization found`	Treat the `0101 / A` repeat as the same authorization. Return the original `0100 / A` response. Do not apply duplicate balance, block/reserve, or ledger impact.
`Original 0100 / A authorization not found`	Treat the `0101 / A` repeat as a new authorization request. Evaluate balance and business rules, then return the required authorization response.

Response behavior

Authorization repeats use authorization-style responses.

Decision	Acknowledgement	Responsestatus
Approve	`1`	`00`
Decline	`1`	`05`
Partial approval, when applicable	`1`	`10`

If the original authorization is found, your system should return the same logical response that was returned for the original authorization.

Implementation note

Authorization repeats should not automatically be treated as duplicate messages only because they are repeated.

Your system should first try to match the 0101 / A repeat to the original 0100 / A authorization. If the original authorization is found, the repeat represents the same authorization. If the original authorization is not found, your system should process the repeat as a new authorization request.

The more matching criteria your system can confirm, the more reliable the match

9.11 Authorization advice messages

Authorization advice messages are authorization-related messages that notify your system of an authorization event that has already occurred or was generated outside the standard real-time authorization request flow.

Unlike an authorization decisioning message, an authorization advice message is generally not asking your system to make a new approve or decline decision. Instead, your system should process the advice for transaction history, balance or block updates, ledger handling, and reconciliation.

Your system should process the advice using the original EHI fields and match it to the original authorization when possible.

Field	Expected value	Description
`MTID`	0120	Identifies the message as an authorization advice.
`Txn_Type`	J	Identifies the transaction as an authorization advice.
`Token`	Varies	Identifies the card token associated with the transaction.
`TXn_ID / Txn_ID`	Varies	Identifies the EHI transaction message.
`traceid_lifecycle`	Varies, when present	Helps match the advice to the original authorization.
`Auth_Code_DE38`	Varies, when present	May help match the advice to the original authorization.
`Trans_link`	Varies, when present	May help match the advice to the original authorization.
`Resp_Code_DE39`	Varies	Indicates the authorization response result when populated.
`Response_Source`	Varies, when present	Indicates the source of the authorization response.
`Response_Source_Why`	Varies, when present	Indicates the reason for the authorization response.
`Message_Source`	Varies, when present	Indicates the source that generated the advice message.
`Message_Why`	Varies, when present	Indicates why the advice message was generated.

Authorization advice messages are identified using the EHI fields included in the forwarded payload.

Authorization advice flow

Platform

Payblr

System

Your Systems

1. Forward original EHI authorization advice payload

Authorization advice

Payblr forwards the original EHI authorization advice payload to your configured endpoint.

PayblrYour Systems

2. Identify advice using MTID=0120 and Txn_Type=J

Your system validates the request and identifies the message as an authorization advice.

Your SystemsprocessesYour Systems

3. Match to original authorization and process advice

Authorization advice

Your system matches the advice to the original authorization, reviews Resp_Code_DE39, and updates records accordingly.

Your SystemsprocessesYour Systems

4. Return acknowledgement response

Authorization advice

Your system returns an acknowledgement response to Payblr.

Your SystemsPayblr

5. Relay acknowledgement through transaction flow

Payblr relays the acknowledgement through the transaction flow.

PayblrprocessesPayblr

sequenceLaneCenter(index, columnCount)

When your system receive an authorization advice message, they should:

Validate Payblr’s integration headers, signature, timestamp, and raw payload before processing.
Identify the message as an authorization advice using MTID=0120 and Txn_Type=J.
Check whether the advice message was already received or processed using the applicable EHI identifiers.
Attempt to match the advice to the original 0100 / A authorization request using the EHI matching criteria.
Review Resp_Code_DE39 to determine whether the advised authorization was approved or declined, when this field is populated.
If the advice indicates approval, update or replace the existing block for the transaction using the amount in the advice, when applicable.
If the advice indicates decline, remove the block for the transaction, when applicable.
If the processing code indicates a credit, apply your internal credit-handling rules. Your system may choose not to change blocks for credit scenarios.
If no matching original authorization is found, store the advice as unmatched and process it according to your reconciliation or exception-handling rules.
Store the advice message, matching result, response returned, and x-correlation-id for audit, duplicate handling, and reconciliation.

9.12 Authorization advice matching criteria

Your system should match the 0120 / J authorization advice to the original 0100 / A authorization request using the original EHI fields.

Payblr does not modify, normalize, or create separate matching fields. Your system should apply the matching criteria using the original field names and values received in the EHI payload.

Matching result or advice condition	Required handling
Original 0100 / A authorization found	Match the advice to the original authorization and update block, balance, ledger, or reconciliation records based on the advice details.
Original 0100 / A authorization not found	Store the advice as unmatched and process it according to your reconciliation or exception-handling rules.
Advice indicates approval	Replace or update the existing block for the transaction using the amount in the advice, when applicable.
Advice indicates decline	Remove the related block for the transaction, when applicable.
Advice relates to a credit	Apply your internal credit-handling rules. Your system may choose not to change blocks for credit scenarios.
Advice already processed	Do not apply balance, block, reserve, or ledger impact again. Return the same logical acknowledgement.

The matching logic can be understood as:

OTHER.Token = THIS.Token
AND (
  OTHER.traceid_lifecycle = THIS.traceid_lifecycle, if THIS.traceid_lifecycle exists
  OR OTHER.Auth_Code_DE38 = THIS.Auth_Code_DE38, if THIS.Auth_Code_DE38 exists
  OR OTHER.Trans_link = THIS.Trans_link, if THIS.Trans_link exists
)

The original authorization request may not always exist. If a matching 0100 / A authorization is not found, your system should still store the advice and process it according to your reconciliation or exception-handling rules.

Processing outcome

Matching result or advice condition	Required handling
Original 0100 / A authorization found	Match the advice to the original authorization and update block, balance, ledger, or reconciliation records based on the advice details.
Original 0100 / A authorization not found	Store the advice as unmatched and process it according to your reconciliation or exception-handling rules.
Advice indicates approval	Replace or update the existing block for the transaction using the amount in the advice, when applicable.
Advice indicates decline	Remove the related block for the transaction, when applicable.
Advice relates to a credit	Apply your internal credit-handling rules. Your system may choose not to change blocks for credit scenarios.
Advice already processed	Do not apply balance, block, reserve, or ledger impact again. Return the same logical acknowledgement.

9.13 Authorization advice response and examples

Authorization advice messages should generally be acknowledged after your system receives and process the message.

Acknowledgement: Required. Indicates that the system received and processed the advice message.
Responsestatus: Optional. May be included when required by the EHI response contract or your program configuration.

For authorization advice messages, your system generally returns an acknowledgement response rather than a new approve or decline decision.

Authorization advice request example

{
  "FxProviderCardholderRate": 0.0,
  "POS_Date_DE13": "00000000",
  "Visa_ResponseInfo_DE44": "020000000000",
  "Visa_STIP_Reason_Code": "9020",
  "Network_Transaction_ID": "0002353127640022",
  "DCC_Indicator": 0,
  "multi_part_txn": 0,
  "multi_part_txn_final": 0,
  "auth_type": "0",
  "auth_expdate_utc": "2022-12-27 07:44:44.137",
  "Matching_Txn_ID": 0,
  "Reason_ID": 0,
  "Merch_Name": "Passenger Railway - SCAEx",
  "Merch_Country": "CYP",
  "Merch_Tax_id": "0",
  "GPS_POS_Capability": "00001001000000000000000100010010001000000001130C0",
  "GPS_POS_Data": "9968000800000Nx000",
  "Response_Source": "VISA-STIP",
  "Response_Source_Why": 5,
  "Message_Source": "VISA-STIP",
  "Message_Why": 5,
  "traceid_lifecycle": "VIS1-20221219-002353127640022",
  "PaymentToken_id": 0,
  "PaymentToken_creatorStatus": " ",
  "PaymentToken_lang": "  ",
  "PaymentToken_activationMethod": 0,
  "Acquirer_id_DE32": "0844622180",
  "ActBal": 10001.00,
  "Avl_Bal": 10001.00,
  "Bill_Amt": 1.00,
  "Bill_Ccy": "826",
  "BlkAmt": 0.00,
  "FX_Pad": 0.00,
  "Fee_Fixed": 0.00,
  "Fee_Rate": 0.00,
  "MCC_Code": "4112",
  "MCC_Pad": 0.00,
  "Merch_ID_DE42": "4112           ",
  "Merch_Name_DE43": "Passenger Railway - SCAEx CY",
  "POS_Data_DE22": "0110",
  "Proc_Code": "000000",
  "Resp_Code_DE39": "00",
  "Ret_Ref_No_DE37": "235303502519",
  "Settle_Amt": 0.00,
  "Status_Code": "00",
  "Token": 107419774,
  "Trans_link": "221219002519622180",
  "Txn_Amt": 1.0000,
  "Txn_CCy": "826",
  "Txn_Ctry": "CYP",
  "Txn_Desc": "Passenger Railway - SCAEx CY",
  "Txn_GPS_Date": "2022-12-19 07:44:44.203",
  "TXn_ID": 6155805963,
  "Txn_Stat_Code": "A",
  "TXN_Time_DE07": "1219074444",
  "Txn_Type": "J",
  "Authorised_by_GPS": "N",
  "InstCode": "TEST",
  "MTID": "0120",
  "ProductID": 99883,
  "SubBIN": 44622180,
  "TLogIDOrg": 0,
  "Dom_Fee_Fixed": 0.0000,
  "Non_Dom_Fee_Fixed": 0.0000,
  "Fx_Fee_Fixed": 0.0000,
  "Other_Fee_Amt": 0.0000,
  "Fx_Fee_Rate": 0.0000,
  "Dom_Fee_Rate": 0.0000,
  "Non_Dom_Fee_Rate": 0.0000,
  "SendingAttemptCount": 0
}

Minimal acknowledgement response

{
  "Acknowledgement": "1"
}

9.14 Authorization advice implementation notes

Authorization advice messages should not be treated as new 0100 / A authorization requests.
Your system should attempt to match the advice to the original 0100 / A authorization when possible.
Your system should use Resp_Code_DE39 to determine whether the advised transaction was approved or declined when that field is populated.
If the advice indicates approval, your system should update or replace the existing block when applicable.
If the advice indicates decline, your system should remove the related block when applicable.
If the advice relates to a credit, your system may choose not to change blocks.
If the matching authorization does not exist, your system should store the advice and route it to reconciliation or exception handling according to your internal process.
Your system should avoid duplicate block, balance, block/reserve, or ledger impact if the same advice is received more than once.
Your system should store key identifiers such as Token, TXn_ID, traceid_lifecycle, Trans_link, Auth_Code_DE38, Ret_Ref_No_DE37, and x-correlation-id.

9.15 Authorization duplicate or retry handling

If your system receives the same authorization message more than once, they should not automatically treat it as a new transaction.

Duplicates or retries may happen due to timeouts, network interruptions, or repeated delivery attempts. Your system should use the original EHI identifiers to determine whether the message was already processed.

Common identifiers for duplicate or retry handling include:

Field	Use
`TXn_ID / Txn_ID`	Primary identifier for detecting whether the same transaction message was already processed.
`traceid_lifecycle`	Helps identify related lifecycle messages.
`Traceid_Message`	Helps identify the specific message instance.
`Trans_link`	Supports transaction linking and matching.
`Ret_Ref_No_DE37`	Retrieval reference number.
`Auth_Code_DE38`	Authorization code.
`SendingAttemptCount`	May indicate repeated delivery attempts.

If the authorization has already been processed, your system should:

Requirement	Description
Avoid duplicate impact	Do not block, reserve, post, or adjust funds again.
Return consistent response	Return the same logical response as the original authorization.
Log the duplicate	Store the duplicate attempt with the original transaction reference and `x-correlation-id`.

9.16 Incremental authorizations

An incremental authorization requests an additional amount for a previously authorized purchase. This commonly occurs with hotels and car rentals, where the final purchase amount is not known initially. Multiple approved authorizations may be settled through one presentment.

Payblr forwards each EHI JSON message without transforming the payload. Your system must evaluate each new incremental authorization and maintain its relationship to the original transaction.

Your system should:

Check for duplicate delivery before applying any financial impact.
Link the incremental authorization to the original transaction using the available lifecycle identifiers. Related incremental authorizations share Token, Txn_CCy, and traceid_lifecycle.
Evaluate the additional amount against available funds and your authorization rules.
If approved, reserve the additional approved amount while retaining the existing hold.
If declined, leave previously approved holds unchanged.
Store each authorization and its decision separately within the related transaction lifecycle.

A shared traceid_lifecycle does not mean that two messages are duplicates. An incremental authorization represents an additional request and must not be discarded solely because its lifecycle identifier already exists.

Example: An initial authorization of USD 100 followed by an approved incremental authorization of USD 30 results in a total hold of USD 130. The merchant may subsequently submit one presentment for USD 130.

Next steps

Continue to Authorization Reversal Messages.