Skip to main content
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 to hear about changes as they are published.
​
Payment lifecycleBreakingPayers

​
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 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 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.
​
Payment lifecycleAPIBreakingPayers

​
Removed field, 5-minute default deadline

Affects: payers integrating with the Payments API, SDK or CLI.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 with the default deadline, set a longer one. See Deadlines and Refunds.
​
APIPayers

​
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 and Decline reasons.
​
APIBreakingPayers

​
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 or 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.
​
Payment lifecycleAPIVeri-FillBreakingSettlement operators

​
Operators paid after finality

Affects: settlement operators.On Ethereum and its rollups, the settlement vault 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.
  • 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 and Price holds and declines.
​
APIVeri-FillSettlement operators

​
Retry signatures on 503

Affects: settlement operators that request release or refund signatures from Veri-Fill.If Veri-Fill, Atum’s verification service that signs releases and refunds for the settlement vault, 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.
​
Payment lifecycleAPIBreakingPayers

​
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 and Payment status.
​
Payment lifecycleAPIVeri-FillSettlement operators

​
Refund signature changes

Affects: settlement operators that request refund signatures from POST /v1/refund.Asking Veri-Fill, 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 and When a refund can start.
​
APIx402Payers

​
Retried x402 settle returns the payment

Affects: integrators who retry /settle on the x402 facilitator.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, Settle and Accept payments with the x402 SDK.
​
Networks and assetsPayersSettlement operators

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