Skip to main content
Direct is in early access and subject to change. To request Direct access, contact hi@natural.com.
A check (chk_*) mails a paper check in USD from a Wallet to an External party. 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.

Create

  • A check references an External party 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, 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.
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.

Funds and balance

At issuance Natural escrows the check amount from the wallet. Your available balance 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

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. 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. 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.