> ## Documentation Index
> Fetch the complete documentation index at: https://www.smartretry.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Transaction Types

> Understanding the payment transaction types supported by SmartRetry.

SmartRetry supports the full range of payment transaction types. Understanding which type to use - and how they relate to each other - ensures your integration behaves as expected and that SmartRetry applies the right recovery logic when a transaction fails.

## Quick reference

| Type           | API value        | Description                                           |
| -------------- | ---------------- | ----------------------------------------------------- |
| Sale           | `sale`           | Immediate charge against a payment method             |
| Pre-auth       | `preauth`        | Authorization hold without capturing funds            |
| Capture        | `capture`        | Settles a prior pre-auth                              |
| Refund         | `refund`         | Returns funds to the payer                            |
| Void           | `void`           | Cancels an authorized or pending transaction          |
| Recurring Init | `recurring_init` | Initializes a recurring series and stores credentials |
| Recurring      | `recurring`      | Subsequent charge in a recurring series               |
| Payout         | `payout`         | Transfers funds out to the payer                      |

## Transaction lifecycles

```
Sale
  └── APPROVED → (complete)

Pre-auth
  ├── APPROVED → Capture → (complete)
  └── APPROVED → Void   → (cancelled)

Recurring Init
  └── APPROVED → Recurring → Recurring → ... → (complete or cancelled)
```

## Transaction types in detail

<AccordionGroup>
  <Accordion title="Sale">
    A sale is a direct, immediate charge against the payer's payment method. Funds are authorized and captured in a single step.

    **Use for:** Standard one-time purchases where the final amount is known at the time of checkout.

    **SmartRetry behavior:** If a sale is declined, SmartRetry analyzes the decline code and applies the appropriate recovery strategy - adjusting routing, authentication, or card parameters before retrying.
  </Accordion>

  <Accordion title="Pre-auth">
    A pre-authorization places a hold on funds in the payer's account without capturing them. The hold reserves the amount but does not complete the transfer.

    **Use for:** Scenarios where the final charge amount may differ from the initial authorization - such as hotels, car rentals, or orders with variable fulfillment costs.

    **SmartRetry behavior:** SmartRetry can recover failed pre-auth attempts using the same optimization strategies applied to sales.

    <Note>
      Pre-auth holds expire after a period defined by the card network (typically 7–30 days). You must capture before the hold expires.
    </Note>
  </Accordion>

  <Accordion title="Capture">
    A capture settles a previously approved pre-authorization. It triggers the actual transfer of reserved funds from the payer's account to the merchant.

    **Use for:** Completing a pre-auth once the final transaction amount is confirmed.

    **Requirements:** The capture must reference the original pre-auth transaction ID. The capture amount cannot exceed the authorized amount.
  </Accordion>

  <Accordion title="Refund">
    A refund returns funds to the payer, reversing some or all of a previously completed transaction.

    **Use for:** Order cancellations, returns, or partial refunds after settlement.

    **Requirements:** The refund must reference the original completed transaction. Partial refunds are supported up to the original transaction amount.

    <Warning>
      Refunds apply to settled transactions. To cancel a transaction before settlement, use a **Void** instead.
    </Warning>
  </Accordion>

  <Accordion title="Void">
    A void cancels an authorized or pending transaction before it settles. Unlike a refund, no funds are moved - the authorization hold is simply released.

    **Use for:** Cancelling an order or pre-auth before the capture step, or reversing a sale that has not yet settled.

    **Requirements:** The void must reference the original transaction ID. Voiding is only possible while the transaction is in an authorized or pending state.
  </Accordion>

  <Accordion title="Recurring Init">
    A recurring init is the first transaction in a recurring payment series. It charges the payer and simultaneously stores their card credentials on file to enable future automated charges.

    **Use for:** Initializing subscriptions, installment plans, or any payment series where you need to store credentials for repeated use.

    **SmartRetry behavior:** SmartRetry applies specialized recurring transaction logic to maximize the approval rate of the initial charge and ensures credentials are stored correctly for subsequent charges.
  </Accordion>

  <Accordion title="Recurring">
    A recurring transaction is a subsequent charge in a series initialized by a `recurring_init`. It uses the stored credentials from the initial transaction.

    **Use for:** Subscription renewals, scheduled installments, and any automated charge following a successful recurring init.

    **SmartRetry behavior:** SmartRetry applies dedicated retry logic for recurring charges - adjusting timing, acquirer routing, and authentication behavior to minimize involuntary churn on renewals.

    <Tip>
      Recurring transactions have some of the highest recovery rates in SmartRetry, since the underlying card is often valid and the decline is temporary.
    </Tip>
  </Accordion>

  <Accordion title="Payout">
    A payout transfers funds from your account to the payer. This is the reverse of a standard charge.

    **Use for:** Marketplace seller payouts, refund-equivalent transfers, or reward disbursements where funds flow to the cardholder rather than from them.
  </Accordion>
</AccordionGroup>