Session deadlines and final confirmation
Understand a v2 session deadline, timely transfers and server finality.
This guide covers v2 payment sessions, not the legacy invoice lifecycle. Use the expiresAt returned for the session and the current attempt instructions. The deadline is fixed: selecting another route, reopening checkout or retrying a request does not extend it. Do not infer a universal 30-minute window from an example.
Before the displayed deadline
Send one transfer on the displayed network, in the correct token, to the saved address for exactly the displayed amount. It must have eligible chain inclusion before the deadline; clicking Send before the timer ends is not proof. Allow time for the wallet to broadcast and for the network to include the transfer. There is no guaranteed confirmation duration or promise that a transfer exactly at the deadline is eligible.
Do not round, split or reuse old instructions. A different amount or token can be unmatched or belong to another eligible payment. A route change never makes an old transfer into the newly selected route's payment.
When the countdown ends
Stop sending funds. Checkout hides payable instructions, but the timer alone does not establish that no payment occurred. A timely included transfer may still be awaiting confirmation or processing. EXPIRED is not automatically a final unpaid outcome.
Read GET /v2/payment-sessions/:id from your backend with the session's project/mode secret. Check the authoritative session status together with monitoringComplete and isFinal: these describe chain monitoring and outstanding confirmation/settlement work. Do not replace them with a browser timer or a redirect parameter. Pending work can finish after the payment window.
Only verified payment_session.paid plus an authenticated PAID session, matched to saved order, project, mode, currency and pricing, authorizes once-only fulfillment. Use the complete confirmation procedure. A session's winning attempt can differ from the route currently displayed; its child invoice is not another order payment.
Late, additional or unresolved transfers
Late observations can appear as LATE_PAYMENT; further matching receipts can appear as ADDITIONAL_PAYMENT. They require review and do not authorize another fulfillment. Monitoring after settlement is not a guarantee that every future transfer will be discovered or listed. An unattributed reviewCandidates entry is not payment proof and may belong elsewhere.
If the customer already sent funds, do not automatically create a replacement request or ask for a second or difference transfer. Collect the session/order reference, network and transaction hash, compare them with the saved attempt, and follow payment problems. Support can investigate status; it does not guarantee acceptance of wrong or late transfers. Any refund is arranged with the merchant.