Retrieve order offline tender
How ONE order was tendered offline: cash on delivery, cheque, bank transfer or trade credit, with the date payment is due. It is the fact neither the order nor the payment resource carries, and without it an order taken on 30-day trade credit and one taken on a bounced cheque read identically as an unsettled payment. A 404 MEANS THE ORDER WAS NOT TAKEN OFFLINE, which is an answer rather than a failure. An order paid through Stripe, Razorpay or Dodo has no offline-tender record at all, so this is how you tell a processor payment from an offline one. The same 404 covers an order id from another store and one that does not exist, so it is not a probe for which order ids a merchant has. due_at IS NULL FOR MOST TENDERS. Cash on delivery has no due date, and a merchant recording a cheque may not set one. Null means there is no agreed date, NOT that payment is overdue: fall back to created_at, which is when the tender was recorded, for an ageing calculation. NO created_by. The merchant user who recorded the tender is staff identity and this API publishes none: it would tell you which of a merchant’s employees took a cheque at the counter, which is their internal staffing and not your order’s payment terms. READ ONLY, and settlement is not on this API in any form. Marking an offline payment collected transitions the order to paid, commits its inventory reservations, releases held trade credit and sends the confirmation email. That is a human deciding a cheque cleared; an api key asserting it would ship goods that were never paid for, and the call looks identical either way.
Authorizations
A secret API key. Publishable keys cannot reach this API. A key may carry an expiry, and an expired key is refused exactly like an unknown one, with a 401 that names no reason; check the key's expires_at in the dashboard rather than inferring it from a response. When a merchant rolls a key's secret they choose a grace window of up to 3 days, and for its duration BOTH the new secret and the one it replaced authenticate, so an integration moves over on its own deploy schedule instead of at the instant the button is pressed. Move before the window closes: after it, the old secret is refused. Nothing else about this contract moves with a roll. The key keeps its id and its scopes, so the only thing an integration updates is the credential itself.
Path Parameters
Response
Success
