Transaction Safety & Failure Handling

The current version of Connect API does not support idempotency keys. As a result, retrying a POST request to create a transaction may create a duplicate transaction if the original request actually succeeded but the response was not received. Therefore, when an API call to create a transaction fails or times out (where you receive a 5xx response), you should assume the outcome is unknown until it has been explicitly confirmed.

Instead of automatically retrying the request—which may result in a double disbursement—you should first determine whether the transaction was created by calling the Get list of payments endpoint and searching for a transaction created within the relevant time window. If a matching transaction is found, treat it as successfully created and continue processing from that state rather than creating a new transaction. If no matching transaction is found, you can confidently conclude that no transaction was created and safely reinitiate the request.

As a general rule of thumb, if you receive any 5xx errors from our endpoints, we recommend reaching out to us before retrying. Our team can investigate and confirm whether the transaction was created and advise on the appropriate next steps.

Please note that while we plan to add idempotency soon, we do have several safeguards for transaction creation available today. First, all payments must have the initial quote explicitly accepted before they move on from the "draft" status. Second, there is an optional setting that you can use, called requireApproval, to mandate that there be an additional explicit approval for a transaction (after initial quote has been accepted) based on whatever logic you choose to have in your system.