Transactions

The transaction object and the allowed CRUD operations on the related resource endpoint

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.

Unblocking stuck transactions

If a transaction gets stuck (for any reason) on our platform but succeeds on the payment gateway, you can patch it (by using integration API credentials) 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.

This is an immutable API, meaning that create, update, and delete operations are not allowed on this endpoint, with the exception of the _forward trigger attribute mentioned above. You can only fetch a list of transactions or a specific single one.