# Transactions

Transactions are created during an order lifecycle and determine its payment status changes:

* [Authorizations](/core-api-reference/authorizations.md) — when a payment source is authorized. On successful authorization, the order's payment status becomes `authorized`.
* [Captures](/core-api-reference/captures.md) — when an authorization is captured. On successful capture, the order's payment status becomes `paid`.
* [Voids](/core-api-reference/voids.md) — when an authorization is voided. On successful void, the order's payment status becomes `voided`.
* [Refunds](/core-api-reference/refunds.md) — 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](/core-api-reference/payment_gateways.md).

## 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](/core/api-credentials.md#integration) 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.

{% hint style="warning" %}
When patching authorizations, the order is also placed at the end of the forwarding process, to avoid any possible modifications.
{% endhint %}

## Cancelling transactions

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 [integration](/core/api-credentials.md#integration) 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.

{% hint style="warning" %}
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](/core-api-reference/adyen_gateways.md)). To avoid any possible order changes upon receiving a succeeded authorization or (if [auto-capture](/how-tos/placing-orders/auto-capture.md) is enabled) capture, we recommend to place the order as first thing (i.e. before authorization) in your payment workflow.
{% endhint %}

{% hint style="info" %}
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 single transaction object. For the full set of available CRUD actions to the specific transaction type endpoints.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.commercelayer.io/core-api-reference/transactions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.