> ## Documentation Index > Fetch the complete documentation index at: https://docs.atum.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Changelog > See what changed in Atum payments: statuses, APIs, the x402 facilitator, Veri-Fill, and supported networks and assets. Subscribe by RSS; newest entries first. This page lists the changes that affect how you integrate with Atum, newest first. Assume updates apply to both testnet and mainnet unless otherwise indicated. Subscribe to the [RSS feed](https://docs.atum.xyz/changelog/rss.xml) to hear about changes as they are published. **2026-10-30** ## `completed` arrives later on Ethereum **Affects:** payers who wait for a payment to reach `completed`. Payments on Ethereum and its rollups (Arbitrum, Optimism, Celo and Base) now show as `completed` only once the payout is final, which takes tens of minutes. Your recipient already has the money once the status is `finalizing`. * **The status moves from `finalizing` to `completed` only once the payout is in a finalized block** on Ethereum, Arbitrum, Optimism, Celo and Base. On Ethereum this used to take about 2 minutes. See [Time to finality by chain](https://docs.atum.xyz/get-started/concepts/finality.md#time-to-finality) for each chain. * **On Polygon, the status reaches `completed` sooner**, once the block is in a finalized milestone. ### What to do Your recipient has the funds once the status is `finalizing`. You can treat a `finalizing` payment as paid if you accept the small risk that the payout is reversed. If you wait for `completed`, base your timeout on the chain's [time to finality](https://docs.atum.xyz/get-started/concepts/finality.md#time-to-finality) and leave room for slow periods. Do not retry or refund a payment whose status is still `finalizing`; it is not stuck. See [Payment status](https://docs.atum.xyz/get-started/after-submission.md#payment-status). **2026-10-30** ## Removed field, 5-minute default deadline **Affects:** payers integrating with the [Payments API](https://docs.atum.xyz/api-reference/payment-gateway/introduction.md), [SDK](https://docs.atum.xyz/get-started/start-building/build-with-the-sdk.md) or [CLI](https://docs.atum.xyz/get-started/start-building/using-the-cli.md). Payments no longer return `fulfillment_confirmation`. If you don't set a deadline, SDK and CLI 5.0.0 give a payment 5 minutes to be delivered before it is refunded, down from 1 hour, and the CLI stops waiting once the payout is on chain. * **`fulfillment_confirmation` is removed.** Payments no longer return it; read the payout transaction from `transactions.fulfillment`. * **SDK and CLI 5.0.0 default to a 5-minute delivery deadline**, down from 1 hour. A payment that is not delivered is refunded sooner. A deadline you set yourself is unchanged, and earlier versions keep the 1-hour default. * **`send-payment` exits with code `5` for a `finalizing` payment**, where it used to exit `2`, and `--wait` stops at `finalizing`. Pass `--wait-for completed` to wait as before. Waits in the SDK and CLI also stop at `refund_available`. * **Expired payout authorizations read `refunding`.** If you deliver the payout yourself and the settlement operator's transfer authorization expires unused, the payment now reads `refunding` instead of `failed` with `SETTLEMENT_FAILED`. This change has been live since 2026-10-23. ### What to do Remove any reads of `fulfillment_confirmation`. If a script reads `send-payment` exit codes, handle `5`. If you send [large payments](https://docs.atum.xyz/get-started/concepts/deadlines.md#large-payments) with the default deadline, set a longer one. See [Deadlines](https://docs.atum.xyz/get-started/concepts/deadlines.md#delivery-deadline) and [Refunds](https://docs.atum.xyz/get-started/support/refunds.md). **2026-10-30** ## Auto accept **Affects:** payers who set a `max_source_amount` on their payments. You can now take the first acceptable quote instead of waiting for the quote window to close. * **Auto accept.** Add the query parameter `auto_accept=true` to `POST /v1/payments`, or use `--auto-accept` in CLI 5.0.0, to take the first valid quote at or under your `max_source_amount`. It is faster, but gives up competitive pricing. * **New decline reason `MAX_SOURCE_AMOUNT_TOO_LOW`.** Settlement operators decline when your `max_source_amount` is below their price. See [Auto accept](https://docs.atum.xyz/get-started/concepts/deadlines.md#auto-accept) and [Decline reasons](https://docs.atum.xyz/decline-reasons.md#max-source-amount-too-low). **2026-10-30** ## Clearer funding and asset errors **Affects:** payers whose code handles errors from `POST /v1/payments`, the SDK or the CLI. Payments the paying account can't fund are now refused when you submit them, with an error code that says why. * **Funding errors are returned on submit.** If the paying account holds too little of the source token, or has not approved Permit2 for enough of it, `POST /v1/payments` answers HTTP 422 with [`INSUFFICIENT_FUNDS`](https://docs.atum.xyz/errors#insufficient-funds) or [`MISSING_TOKEN_APPROVAL`](https://docs.atum.xyz/errors#missing-token-approval). Before, the payment was accepted and then failed with `SETTLEMENT_FAILED`. No funds are moved. ### What to do Don't treat a 422 from `POST /v1/payments` as an outage to retry. If your code maps `SETTLEMENT_FAILED` to a message for the payer, add the new codes. After `INSUFFICIENT_FUNDS` or `MISSING_TOKEN_APPROVAL`, fix the balance or approval and retry with a new `request_id`. See [Errors](https://docs.atum.xyz/errors.md). **2026-10-30** ## Operators paid after finality **Affects:** settlement operators. On Ethereum and its rollups, the [settlement vault](https://docs.atum.xyz/get-started/concepts/settlement-vault.md) now pays you once your payout is final, tens of minutes after it is mined. `/v1/finality-config` no longer returns `finality_model`. * **Vault payments arrive later on Ethereum, Arbitrum, Optimism, Celo and Base.** The settlement vault pays you only once your payout is in a finalized block. On Polygon, vault payments now arrive sooner, once the block is in a finalized milestone. See [Time to finality by chain](https://docs.atum.xyz/get-started/concepts/finality.md#time-to-finality). * **`finality_model` is removed from `/v1/finality-config`.** Use `finality` and `time_to_final_ms`, or `commitment` on Solana. * **New decline reason `MAX_SOURCE_AMOUNT_TOO_LOW`.** Send it when the payer's `max_source_amount` is below your price. ### What to do If your own code reads `finality_model`, remove it. See [Destination finality](https://docs.atum.xyz/settle-payments/destination-finality.md) and [Price holds and declines](https://docs.atum.xyz/settle-payments/price-holds-and-declines.md). **2026-10-30** ## Retry signatures on 503 **Affects:** settlement operators that request release or refund signatures from Veri-Fill. If [Veri-Fill](https://docs.atum.xyz/api-reference/veri-fill/introduction.md), Atum's verification service that signs releases and refunds for the [settlement vault](https://docs.atum.xyz/get-started/concepts/settlement-vault.md), cannot sign for a deposit right now, it asks you to retry. * **Retry when a signature can't be made yet.** `POST /v1/refund` and Solana releases answer HTTP 503. If the response has a `Retry-After` header, wait that long first. If not, send the same request again. ### What to do Treat a 503 from these endpoints as retryable. Wait for the `Retry-After` header when there is one, then send the same request again. See [Veri-Fill](https://docs.atum.xyz/api-reference/veri-fill/introduction.md). **2026-10-19** ## New refund statuses **Affects:** payers whose code branches on payment status. When a settlement operator gives up on a payment, it now reads `refunding` or `refund_available` while the money comes back to you, instead of `failed`. * **Undelivered payments read `refunding` or `refund_available`.** When a settlement operator gives up on a payment, its status is now `refunding` or `refund_available`. Before, it read `failed`. * **`refund_available` means you can submit the refund yourself.** Atum has signed the refund, and anyone can submit it; the vault only pays the original payer. * **New refund fields.** The payment status response carries `refund_reason`, and `refund_signature` when the status is `refund_available`. ### What to do If your code branches on every payment status, add a branch for `refunding`, `refund_available` and `refunded`. While a payment is `refunding` or `refund_available`, do not pay again for the same purchase. See [Refunds](https://docs.atum.xyz/get-started/support/refunds.md) and [Payment status](https://docs.atum.xyz/get-started/after-submission.md#payment-status). **2026-10-19** ## Refund signature changes **Affects:** settlement operators that request refund signatures from `POST /v1/refund`. Asking [Veri-Fill](https://docs.atum.xyz/api-reference/veri-fill/introduction.md), Atum's verification service, for a refund signature now picks up where the last request left off. * **Long checks continue on retry.** If checking a refund takes longer than one request, `/v1/refund` asks you to try again later, and the next request continues from where the last one stopped, on every chain except Tron. * **Canceled payout authorizations can be refunded early.** When the payer submits the payout with your transfer authorization and you cancel it, put the cancel's transaction hash and log index in `authorization_canceled` to get the refund signature without waiting for the delivery deadline. ### What to do When `/v1/refund` asks you to try again later, retry the same request. Except on Tron, each attempt continues the check. See [Veri-Fill](https://docs.atum.xyz/api-reference/veri-fill/introduction.md) and [When a refund can start](https://docs.atum.xyz/get-started/support/refunds.md#when-a-refund-can-start). **2026-10-19** ## Retried x402 settle returns the payment **Affects:** integrators who retry `/settle` on the [x402 facilitator](https://docs.atum.xyz/api-reference/x402/introduction.md). Retrying `/settle` returns the payment you already made instead of an error. * **Retrying `/settle` returns the original payment.** A retried `/settle` is no longer refused once the quote window has closed. It returns the payment you already submitted, so you do not start a second payment by mistake. `/verify` still checks the quote window. ### What to do Build payment requirements with the x402 SDK instead of setting contract addresses by hand. If you retry `/settle` after a timeout, keep using the same request. See [Verify](https://docs.atum.xyz/api-reference/x402/verify.md), [Settle](https://docs.atum.xyz/api-reference/x402/settle.md) and [Accept payments with the x402 SDK](https://docs.atum.xyz/payment-protocols/x402/accept-payments/develop-with-the-sdk.md). **2026-10-19** ## OUSD now supported **Affects:** payers and settlement operators on Ethereum and Base. You can now send and receive OUSD (OpenUSD) on Ethereum and Base mainnet. OUSD is also listed on Tempo; those corridors need access from Atum. OUSD is not supported on Solana. See [Supported assets](https://docs.atum.xyz/get-started/reference/supported-assets.md#ousd). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.