Duplicate Transaction Checking
Quick Find
Go straight to the section you need.
1.0 Gateway Integration →
2.0 New Transactions →
3.0 Management Requests →
4.0 AVS/CV2 Checking →
5.0 3-D Secure Authentication →
11 Receipts and Notifications →
17 Advanced Data →
17.7 Device Information Fields
19 Gateway Wallet →
26 Digital Wallet Transactions →
Appendix
A-1 Response Codes
A-1.1 Authorisation Response Codes
A-2 AVS / CV2 Check Response Codes
A-3 Secure Authentication Data
A-4 3-D Secure Enrolment/Authentication Only
A-9 Duplicate Transaction Checking
A-10 Capture Delay
A-13 Sample Signature Calculation
A-14 Transaction Life cycle
A-14.1 Authorise, Capture and Settlement
A-15.2 Mail Order/Telephone Order (MOTO)
A-15.3 Continuous Authority (CA)
A-16 Payment Tokenisation
A-16.1 PREAUTH, SALE, REFUND, VERIFY requests
A-16.3 CANCEL or CAPTURE requests
A-16.5 SALE or REFUND Referred Authorisation requests
A-18 PSD2 SCA Compliance
A-18.1 Obtaining Strong Customer Authentication
A-18.3 Exemptions to Strong Customer Authentication
A-19 Hosted Payment Page Options
A-20 Integration Libraries
A-20.1 Gateway Integration Library
A-20.2 Hosted Payment Page Library
A-20.3 Hosted Payment Fields Library
A-21 Example HTTP Requests
A-22 Example Integration Code
A-23 Example Library Code
A-23.1 Gateway Integration Library
A-9 Duplicate Transaction Checking
Duplicate transaction checking prevents transaction requests from accidentally processing more than once. This can happen if a Customer refreshes your checkout page or clicks a button that issues a new transaction request. While duplicate checking can help prevent repeat transactions from going through, we recommend talking with your developers to see whether changes can be made to your form to reduce the likelihood of this occurring (eg disabling the Submit button after it has been clicked).
To help prevent duplicate transactions, each transaction can specify a time window during which previous transactions will be checked to see whether they could be possible duplicates.
This time window is specified using the duplicateDelay field. The value for this field can range from 0 to 9999 seconds (approx. 2 ¾ hours).
If the transaction request does not include the duplicateDelay field or specifies a value of zero, then a default delay of 300 seconds (5 minutes) is used.
The following fields are used in transaction comparison and must be the same for a transaction to be regarded as a duplicate:
-
- merchantID
- action
- type
- amount
- transactionUnique
- currencyCode
- xref (if provided in lieu of card details)
- cardNumber (may be specified indirectly via cross reference)
If a transaction is regarded as being a duplicate, then a responseCode of 65554 (REQUEST DUPLICATE) will be returned.