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

> ## Agent Instructions
> When building application code, use `@naturalpay/sdk` for TypeScript or `naturalpay` for Python.
> When searching Natural documentation, use the docs MCP at `https://docs.natural.com/mcp`.
> Use the Natural CLI for terminal and CI automation.
> Start integration development and testing in the sandbox. Do not use production unless the user explicitly requests it.
> For sandbox requests that require `customerPartyId`, list customers first. Reuse only the intended fixture; otherwise create a customer.
> REST and SDK amounts use integer minor units. Payments MCP amounts use decimal strings with a required currency code.

# Overview

> Mail paper checks in USD to external parties

<Note>
  Direct is in early access and subject to change. To request Direct access, contact [hi@natural.com](mailto:hi@natural.com).
</Note>

A check (`chk_*`) mails a paper check in USD from a [Wallet](/guides/concepts/wallets) to an [External party](/guides/concepts/external-parties). Natural prints and mails the check. Unlike other Direct rails, a check has no external party account. The payee is the external party itself, addressed by its US mailing address.

| | |
| - | - |
| API | [Check endpoints](/api-reference/check/create-check-payment) · [Errors](/api-reference/errors/check) |
| Direction | Credit only (wallet → mailed check) |
| Currency | `USD` only |
| Settlement | Asynchronous. Funds are escrowed at issuance and settle when the check is deposited, up to 180 days later |
| Reversible | Cancel before submission, or request a stop payment on a mailed check before deposit; after settlement the bank can return a paid check (`RETURNED`) |
| Headers | `Idempotency-Key` required on create and cancel; `X-Instance-ID` for [agent](/guides/concepts/agents) calls |
| Alternatives | [ACH](/guides/concepts/ach), [Realtime](/guides/concepts/realtime), and [Wire](/guides/concepts/wire) |

## Create

```json theme={null}
{
  "data": {
    "attributes": {
      "amount": 25000,
      "externalPartyId": "epty_019cd1798d8d6873421613705e3c1415",
      "memo": "Invoice 1042",
      "deliveryMethod": "USPS_FIRST_CLASS"
    }
  }
}
```

* A check references an [External party](/guides/concepts/external-parties) through `externalPartyId`. There is no `externalPartyAccountId`, because a check needs no bank account.
* The external party needs a complete US mailing address. If the address is missing, create returns `400 check.recipient_address_incomplete`. If the address is not US, create returns `400 check.recipient_address_not_us`. Add the address with [`PATCH /external-parties/{externalPartyId}/address`](/api-reference/external-parties/correct-an-external-party-address), then retry the check with the same IDs.
* Create snapshots the payee name, address, and `addressVersion`. A later address correction does not move a check that is already mailed.
* `amount` is in cents and fixed. Every check carries positive pay, so the bank matches the printed amount and payee at presentment. A check is never issued blank.
* `memo` prints on the check memo line. The optional `message` prints on the mailing insert.
* `deliveryMethod` is `USPS_FIRST_CLASS` (default), `FEDEX_TWO_DAY`, or `FEDEX_OVERNIGHT`. FedEx methods carry a tracking URL; USPS first class does not.
* To send on behalf of a customer, pass `customerPartyId`. See [Move money for a customer](/guides/connect/move-money-for-customer).

The resource echoes the payee snapshot captured when the check was created: name, street lines, city, state, postal code, and the address version. The live address stays on the [external party](/api-reference/external-parties/get-external-party).

## Funds and balance

At issuance Natural escrows the check amount from the wallet. Your [available balance](/guides/concepts/wallets) drops by the amount, while your total balance still includes it. The two stay apart for the whole outstanding window, up to 180 days. This is longer than any other rail holds funds.

Settlement debits the wallet when the check is deposited. If the check expires without a deposit, the escrow releases back to available. A confirmed stop payment releases the escrow the same way. A post-settlement return restores the funds after the wallet was debited. A check spends settled funds only.

## Lifecycle

| Status | Meaning | Terminal | Sets |
| - | - | - | - |
| `CREATED` | Accepted and waiting to be issued | No | |
| `AWAITING_APPROVAL` | Held for [approval](/guides/concepts/approvals) after breaching a [limit](/guides/concepts/limits) | No | |
| `PROCESSING` | Issued, printed, mailed, or awaiting deposit | No | `submittedAt`, `issuedAt` |
| `COMPLETED` | Deposited and settled; the wallet is debited | Yes | `completedAt`, `terminalAt` |
| `RETURNED` | Returned by the paying bank after settlement; funds restored to the wallet | Yes | `returnedAt`, `terminalAt` |
| `CANCELING` | A stop payment was requested on a mailed check and is awaiting bank confirmation | No | `stopRequestedAt` |
| `CANCELED` | Canceled before submission, or a requested stop payment was confirmed | Yes | `canceledAt`, `terminalAt` |
| `EXPIRED` | Voided 180 days after issuance; escrow released | Yes | `expiredAt`, `terminalAt` |
| `REJECTED` | Column rejected the issuance; details in `failure` | Yes | `rejectedAt`, `terminalAt` |
| `APPROVAL_DENIED` | Approval was denied | Yes | `terminalAt` |
| `FAILED` | Failed before issuance; details in `failure` | Yes | `terminalAt` |

**Cancel** — Cancel behaves differently before and after a check is submitted to the bank.

Before submission, while the check is `CREATED` or `AWAITING_APPROVAL`, cancel closes it locally. The check moves straight to `CANCELED` and the escrow releases immediately.

After submission, while the check is `PROCESSING` and not yet deposited, cancel requests a bank stop payment. The response returns the check at `CANCELING`, not `CANCELED` — the stop has been requested but the bank has not confirmed it yet. Do not treat this response as funds released. When the bank confirms the stop, the check moves to terminal `CANCELED` and the escrow releases. The stop is best-effort: if the check is deposited before the bank confirms the stop, the stop fails and the check proceeds to `COMPLETED` (or later `RETURNED`) instead of `CANCELED`.

Once a check is deposited or otherwise terminal, cancel returns `400 check.not_cancellable`. If the check is still being submitted when you cancel, cancel returns a retryable `409 check.cancel_in_progress`; retry shortly with the same idempotency key. If the stop payment cannot be confirmed, cancel returns `400 check.cancel_failed`.

**Expiry** — An uncashed check voids 180 days after issuance. `voidDate` carries that date. On expiry the status becomes `EXPIRED` and the escrow releases.

## Delivery

Delivery progress is not money state. It lives on a separate `delivery` block with a status, a tracking URL on FedEx methods, and timestamps. Delivery moves through `CREATED`, `RENDERED_PDF`, `MAILED`, `IN_TRANSIT`, `IN_LOCAL_AREA`, `PROCESSED_FOR_DELIVERY`, and `DELIVERED`. A misrouted item shows `REROUTED`, `RETURNED_TO_SENDER`, or `FAILED`.

Delivery never changes the money status. One delivery transition notifies you: `RETURNED_TO_SENDER` fires `check.returned_to_sender`, because undeliverable mail is a money risk you must track. The check stays `PROCESSING`, and you can still cancel it to request a stop payment.

## Returns

A check can be refused in two ways, and they mean opposite things.

A **presentment return** happens when the paying side does not pay a check that is presented. Positive pay found a mismatch, or the account is short. Money does not leave the wallet, the check stays `PROCESSING`, and the refusal facts land in `presentmentReturns`. The depositing bank can present the check again, and it can clear on re-presentment if the wallet is funded.

A **post-settlement return** happens when the paying bank returns a check that was already paid. The status moves from `COMPLETED` to `RETURNED` and the funds return to the wallet. This is the only exit from `COMPLETED`. Version 1 has no API to initiate a return; it is a support path.

A returned funding deposit can bounce a check. If a deposit funds the wallet, a check draws on it, and the deposit later returns, the account is short and the check can be refused at presentment. Version 1 does not stop or claw back the check automatically. Keep the wallet funded while checks are outstanding, or cancel the check to request a stop payment before it is deposited.

**Events** — Status changes emit `check.created`, `check.processing`, `check.completed`, `check.returned`, `check.canceled`, `check.expired`, `check.rejected`, and `check.failed`. Undeliverable mail emits `check.returned_to_sender`. Approval holds emit `approval.*` events instead. Events go to your webhooks, and to a connected customer's webhooks when they have granted Direct read access. Payloads are documented in the [event catalog](/api-reference/event-catalog).

**Sandbox** — Drive a test check to a terminal state without waiting on the mail. Each action fires the same money-movement fixtures the end-to-end harness drives, so sandbox reaches the same states as production.

| Action | Result |
| - | - |
| [Deposit](/api-reference/simulations/deposit-check) | Settles the check to `COMPLETED` |
| [Fail](/api-reference/simulations/fail-check) | Rejects the check before settlement |
| [Bounce](/api-reference/simulations/bounce-check) | A non-terminal presentment return; the check stays outstanding |
| [Void](/api-reference/simulations/void-check) | `CANCELED` through a second presentment return after a failed reclear |
| [Stop](/api-reference/simulations/stop-check) | `CANCELED` through a confirmed stop payment |
| [Deliver](/api-reference/simulations/deliver-check) | Advances mail delivery to delivered |
| [Return to sender](/api-reference/simulations/return-check-to-sender) | Ends delivery at returned-to-sender and fires `check.returned_to_sender` |

The payment-lane actions (deposit, fail, bounce, void, stop) move the money status. The delivery-lane actions (deliver, return to sender) move only the `delivery` block.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.