Transactions
The transaction object and the allowed CRUD operations on the related resource endpoint
Last updated
The transaction object and the allowed CRUD operations on the related resource endpoint
Last updated
Transactions are created during an order lifecycle and determine its payment status changes:
Authorizations — when a payment source is authorized. On successful authorization, the order's payment status becomes authorized.
Captures — when an authorization is captured. On successful capture, the order's payment status becomes paid.
Voids — when an authorization is voided. On successful void, the order's payment status becomes voided.
Refunds — when a capture is refunded, either totally or partially. On successful refund, the order's payment status becomes refunded or partially_refunded.
Fetching a transaction returns all the information and messages provided by the payment gateway.
If a transaction gets stuck (for any reason) on our platform but succeeds on the payment gateway, you can patch it (by using API credentials on the specific transaction type endpoint) with the _forward trigger attribute set to true. In this case, some checks are performed:
The transaction's relative balance must be positive.
The transaction's succeeded attribute must be false.
The associated order's payment status must be eligible to be forwarded successfully (e.g. from authorized to paid).
If all of these guards pass, the transaction is marked as succeeded and the order's payment status is updated accordingly. Otherwise, no action will be performed without returning any error.
When patching authorizations, the order is also placed at the end of the forwarding process, to avoid any possible modifications.
If an authorization or capture succeeded, but the associate order is still pending, it can happen that the order is updated and its total amount differs from the authorized or captured one. In this case, you must reset the related transaction by patching it (you need to use API credentials on the specific transaction type endpoint) with the _cancel trigger attribute set to true. At the end of the process, the order payment status will still be unpaid so that the payment can be completed with a different payment source.
This is an immutable API, meaning that create, update, and delete operations are not allowed on this endpoint. You can only fetch a list of transactions or a specific single one.
The above scenario can occur for example when the 3DS is enabled for those payment gateways where that security measure is performed as a separate step (e.g. Adyen). To avoid any possible order changes upon receiving a succeeded authorization or (if is enabled) capture, we recommend to place the order as first thing (i.e. before authorization) in your payment workflow.