The table below shows the possible HTTP responses that can be returned from the API and the appropriate action to take in each case
| HTTP Code | Description | Action |
|---|---|---|
| 200: OK | Successfully started with Transaction Checks and already finished with immediate decision | |
| 202: Accepted | Successfully started with Transaction Checks but immediate decision is not available yet | Do not retry and wait for processing to complete. A callback will be sent once processing is complete |
| 401: Unauthorised | API key not provided | Ensure API key is included in request to the API |
| 403: Forbidden | There is an issue with TLS/SSL or our IP firewall blocks | Ensure IP Adress is Correct |
| 404: Not Found | The requested resource is not available | Ensure correct resource is being requested |
| 413: Payload Too Large | The request size exceeds the default limit of 1 MB. This limit is currently set only on the TEST environment and does not apply to production. | Ensure transactions are smaller than the size limit. Do not retry. |
| 425: Too Early | PATCH came to early after POST or Customer Update for same customer arrived too early after previous | Wait for 500 ms and retry requests for AML check and 1 sec for customer checks |
| 429: Too Many Requests | The gateway received more than the configured transactions per second | Retry later and ensure transactions per second stay below the limit. |
| 504: Gateway Timeout | API request has timed out | Wait for 500 ms and retry requests using PATCH. If it fails consecutively retry using PATCH by exponentially increasing the time between retries until the request is successful. |
If the issue persists after attempting the above actions, please contact your support team.
Reprocessing Requests
When resubmitting Transaction Checks requests, a PATCH request should be sent to ensure a duplicate transaction is not processed.
Ensure that there is a min delay of 500 ms between an inital POST and the consecutively PATCH.
Use a PATCH request to resubmit a failed transaction just in case the failed transaction did in fact land in the gateway system.
Please be aware: The system will look for existing cases using a combination of tenantTransacionId and caseId or tenantTransactionId only if caseId is not present. It means for example if a new/different tenantTransactionId in PATCH request it will result in a new case.
-
IF the transaction is in the gateway system, the PATCH request will update the transaction and trigger a new response with the results
-
IF the transaction is not in the gateway system, the PATCH request will be treated the same as a POST request, creating a new case
When resubmitting Customer Checks requests, a POST request should be sent to ensure a duplicate transaction is not processed.
Important
The previous version of the Transaction Checks API, AML Checks, has been deprecated. This change has no impact on existing integrations which will continue to be supported.