> ## Documentation Index > Fetch the complete documentation index at: https://docs.gr4vy.com/llms.txt > Use this file to discover all available pages before exploring further. # Transaction statuses > A list of all statuses for transactions. A transaction's `status` value can be one of the following depending on the state within the system and the status within the used payment service. | `status` | Description | | :- | :- | | `processing` | The transaction record has been created in the system and is now being processed with payment services. | | `buyer_approval_pending` | The transaction was created but needs approval from the buyer either by redirecting them to a hosted page or their bank for 3DS. | | `authorization_succeeded` | The transaction has been successfully authorized but not yet captured. | | `authorization_failed` | The transaction could not be authorized with any payment service due to technical issues or limitations of the payment service. | | `authorization_declined` | The transaction was declined by the payment service. | | `capture_pending` | The transaction has successfully been submitted for capture with a payment service and is now pending with them. | | `capture_succeeded` | The transaction has been successfully authorized and captured. | | `authorization_void_pending` | The transaction authorized transaction is in the process of being voided. | | `authorization_voided` | The transaction was successfully authorized but has since been voided before it was captured. | ## State diagram The following state diagram serves as an overview of all the different `status` values and how they relate to each other. ### Separate authorization and capture Transactions where the original `intent` is `authorize`. ```mermaid theme={"system"} flowchart LR start(( )) --> processing processing --> buyer_approval_pending processing --> authorization_succeeded processing --> authorization_failed buyer_approval_pending --> authorization_declined processing --> authorization_declined buyer_approval_pending --> authorization_failed buyer_approval_pending --> processing authorization_succeeded --> capture_pending authorization_succeeded --> authorization_void_pending capture_pending --> capture_succeeded capture_pending --> authorization_succeeded capture_pending --> authorization_declined authorization_void_pending --> authorization_voided authorization_void_pending --> authorization_succeeded ``` ### Direct capture Transactions where the original `intent` is `capture`. ```mermaid theme={"system"} flowchart LR start(( )) --> processing processing --> capture_succeeded processing --> authorization_failed buyer_approval_pending --> authorization_declined processing --> buyer_approval_pending buyer_approval_pending --> processing processing --> authorization_declined ``` In some cases, a transaction with `intent` set to `capture` is internally split into a separate authorization and capture. When this happens, the transaction may pass through `authorization_succeeded` and `capture_pending` before reaching a terminal state such as `capture_succeeded`, or before being voided or declined. See [split authorization and capture](/guides/features/webhooks/technical-considerations#split-authorization-and-capture) for more details. ## Timeouts When Gr4vy forwards a payment request to a connector, network conditions can occasionally cause the request to time out before a response is received. In these cases, the outcome of the request is unknown — the connector may or may not have processed it. Rather than failing immediately or requiring you to re-submit, Gr4vy automatically retries these requests in the background when the connection supports idempotent requests. This guarantees the connector can return the result of the original request without creating a duplicate charge. Not every connection supports idempotent requests. When it doesn't, Gr4vy can't safely retry, and the request fails instead. See [Timeouts without a retry](#timeouts-without-a-retry). ### Transaction timeouts When a `POST /transactions` request to a connector times out, Gr4vy queues a background task to retry that transaction. The transaction moves to `processing` status while Gr4vy resolves the outcome. No action is required on your side — in particular, **do not re-submit the transaction** while it is in `processing`. Retries stop after a maximum of **24 hours** from the original request, at which point the transaction is resolved to a final status. #### Possible outcomes | Outcome | Transaction status | Webhook event | | - | - | - | | Authorization succeeded | `authorization_succeeded` | `transaction.authorized` | | Authorization failed | `authorization_failed` | `transaction.failed` | | Unresolved after 24 hours | `authorization_failed` | `transaction.failed` | In all cases a webhook event is sent when the outcome is known. Gr4vy recommends relying on webhooks rather than polling the transaction status. ### Capture timeouts When a capture request to a connector times out, and the connection supports idempotent requests, Gr4vy queues a background task to retry the capture. The capture moves to `pending` status while Gr4vy resolves the outcome. Retries stop after a maximum of **24 hours** from the original request, at which point the transaction is resolved to a final status. For a capture you request, Gr4vy only retries a capture that times out. A capture that's declined or fails for another reason isn't retried. To try again, call the [capture endpoint](/reference/transactions/capture-transaction) again. When Gr4vy splits a transaction with `intent` set to `capture` into a separate authorization and capture, and the capture fails without being declined, Gr4vy can make another capture attempt in the background. The transaction's events can then show a failed capture followed by a successful one. A declined capture isn't retried. #### Possible outcomes | Outcome | Capture status | Webhook event | | - | - | - | | Capture succeeded | `succeeded` | `capture.succeeded` | | Capture failed | `failed` | `capture.failed` | | Capture declined | `declined` | `capture.declined` | A webhook event is sent as soon as the outcome is known. ### Refund timeouts When a refund request to a connector times out, Gr4vy queues a background task to retry the refund. The refund moves to `pending` status while Gr4vy resolves the outcome. Retries stop after a maximum of **24 hours** from the original request, at which point the transaction is resolved to a final status. #### Possible outcomes | Outcome | Refund status | Webhook event | | - | - | - | | Refund succeeded | `succeeded` | `refund.succeeded` | | Refund failed | `failed` | `refund.failed` | | Refund declined | `declined` | `refund.declined` | A webhook event is sent as soon as the outcome is known. ### Timeouts without a retry When a connection doesn't support idempotent requests, a transaction whose request to the payment service times out ends as `authorization_failed` with `error_code` set to `timeout`. Gr4vy doesn't fail over to another connection in the Flow rule for a timed-out attempt. The payment service may still have processed the payment. Gr4vy doesn't apply results that arrive from the payment service after the transaction failed, and [syncing the transaction](/reference/transactions/sync-transaction) doesn't change its final status. Before you charge the buyer again, check the payment at the payment service, for example, in its dashboard. If the payment went through, reverse it there. ### Recommendations * **Listen for webhooks.** The webhook event is the authoritative signal that a timeout has been resolved. Prefer it over polling. * **Do not re-submit.** A resource with a `processing` or `pending` status is still being resolved. Re-submitting may risk duplicate charges. * **Allow up to 24 hours.** The resolution window for create timeouts is bounded at 24 hours. For captures the window depends on the connector. * **Contact support if nothing arrives.** If 24 hours have passed and you have not received a webhook, contact Gr4vy support with the transaction ID. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.