triPOS^®

Overview

triPOS is enhanced with the capability for an idempotency key (basis Request ID field). It serves as a unique identifier assigned to a transaction request. It helps ensure that if the same request is accidentally/intentionally sent more than once (for example, due to a network

This mechanism protects customers from being charged multiple times for the same purchase.

Transaction Retry Rules

• When a retry is performed for the same purchase transaction, reusing the same request ID is only permitted when the request parameters of the transaction are identical to the original request.
• While retrying, if there are any changes in the request parameters compared to the original request, the same request ID MUST NOT be used. Under such cases, Start a brand-new transaction with a new request ID.

A transaction request qualifies as a retry only if the subsequent request is an exact replica of the original request. Any modification to the request parameters causes the request to be treated as a new transaction, not a retry. Therefore, a unique request ID must be used, and the original request ID must not be reused.

Understanding Idempotent Response

When a retry is performed using the same request ID as the original transaction, the response includes a new field: IdempotentMatch=True

This means:

• The original request was already successful and processed by the host
• The response from retry is not from a new transaction
• It is the original response from the first time that request ID was used

Known Limitation: The above-mentioned behaviour also applies if a retry is inadvertently submitted with a reused request ID but different transaction parameters, the system will continue to return the original response, and the response transaction parameters may show inconsistent behaviour. Complying with the correct usage of request IDs as per the rules outlined in above section is the responsibility of the Merchant/POS.

Best Practices

If the POS does not receive a response or need to retry for some reason:

Step 1: Perform a Transaction Query

Step 2: Evaluate the result:

• If the transaction is found and completed → Do not retry
• If no transaction is found → Retry the transaction with the same parameters and Request ID (Refer section Transaction Retry Rules)

Note: Any other existing functionalities as applicable, remains unchanged and continues to operate as before.

For more information

If you have specific questions regarding the subject of this email, please contact the IP Solutioning Team or the DI Intake team.

---