> For the complete documentation index, see [llms.txt](https://developers.frontstream.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.frontstream.com/argofire/transaction-lifecycle-and-status-codes.md).

# Transaction Lifecycle & Status Codes

<figure><img src="/files/OPkpKWNGisTRODxR9jdP" alt=""><figcaption></figcaption></figure>

***

#### Supported Transaction Types

The API supports the following transaction types:

| Transaction Type        | Description                                                                                                                  |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Sale**                | A combined authorization and capture of funds in a single step.                                                              |
| **Pre-Authorization**   | Authorization only, holds funds without capture.                                                                             |
| **Force Authorization** | Capture with an authorization code. Used in exceptional cases.                                                               |
| **Return**              | Refund or credit applied to a settled transaction.                                                                           |
| **Repeat Sale**         | A repeat sale transaction that uses a previously stored token to charge the customer again without re-entering payment data. |

*Note:* Recurring payment processing is handled via a separate recurring payments API and is not part of these transaction types.

***

#### Transaction Status Values

The **transactionStatus** field in API responses can hold the following documented values:

| Status       | Description                                                   |
| ------------ | ------------------------------------------------------------- |
| **Approved** | Transaction successfully authorized or captured.              |
| **Declined** | Transaction declined by card issuer or processor.             |
| **Error**    | Processing error due to invalid data or system failure.       |
| **Void**     | Authorization canceled before capture/settlement.             |
| **Refunded** | Amount refunded to the cardholder from a settled transaction. |
| **Pending**  | Transaction awaiting further processing or settlement.        |

***

#### HTTP Response Status Codes

The API uses standard HTTP status codes. The documented ones include:

| Code | Meaning                                                   |
| ---- | --------------------------------------------------------- |
| 200  | Request processed successfully.                           |
| 201  | Resource created successfully (e.g., transaction logged). |
| 400  | Bad request due to invalid or missing parameters.         |
| 401  | Unauthorized: invalid or missing API credentials.         |
| 403  | Forbidden: insufficient permissions.                      |
| 404  | Resource not found.                                       |
| 409  | Conflict, such as duplicate transactions.                 |
| 500  | Internal server error.                                    |

***

#### Key Response Fields

The following fields are included in the API transaction responses relevant to lifecycle and status:

* **transactionId:** Unique identifier for the transaction.
* **transactionType:** One of the documented transaction types above (Sale, Pre-Authorization, etc.).
* **transactionStatus:** Status value from the documented set (Approved, Declined, etc.).
* **responseCode:** Numeric processor or gateway result code.
* **responseText:** Human-readable description of the transaction outcome.
* **authCode:** Issuer authorization code, when applicable.
* **timestamp:** Date and time of the transaction or last status update.

***

#### Best Practices

* Rely primarily on **transactionStatus** and **responseCode** to drive your business logic.
* Log declined and error transactions for troubleshooting and customer support.
* Implement retries only for transient server or network failures, not for declined or error responses caused by invalid payment data or issuer decisions.
* Use **responseText** for user-facing messaging or logging.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://developers.frontstream.com/argofire/transaction-lifecycle-and-status-codes.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.