Configure an offline payment method
Turns a tender on or off and sets the directions a shopper is shown for it. THIS IS A LIVE CHECKOUT CHANGE. The cart reads the same row on the next request, so an enabled tender appears at checkout immediately with whatever instructions this call stored. There is no draft and no publish step. A FULL REPLACE, which is why it is PUT and not PATCH: the statement underneath writes both columns every time, so an omitted instructions CLEARS the stored text rather than leaving it alone. 200 on both the first write and every later one. The status never tells you whether the tender had been configured before, because create and update are the same upsert on a row you already know the address of.
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.
Headers
A unique key per logical write. Replaying a request with the same key returns the first response byte for byte instead of applying the write twice.
Path Parameters
Body
A FULL REPLACE, not a merge, which is why this is PUT and not PATCH. The statement underneath writes both columns every time, so an omitted instructions is a CLEARED field and not an unchanged one. Read the tender first and send back the document you received. THE METHOD IS THE PATH SEGMENT and one of cod, cheque, bank_transfer or trade_credit. Anything else is a 400 naming the four, not a 404: a value outside that set is a typo in a closed enum rather than a resource that might exist later. Sending method in the body is refused, because two spellings of one key is how a write lands on the wrong tender. THE STOREFRONT CHANGES IMMEDIATELY. Checkout reads this row on the next request, so there is no draft, no preview and no publish step, and this family emits no webhook topic: a client reconciling has to poll. IT CANNOT SET CREDIT TERMS. credit_limit is refused by name here and no route on this API accepts it under any grant; extending credit to a named buyer is a decision a merchant makes in their dashboard. LAST WRITE WINS. There is no If-Match and no version, so replaying an old body after a newer write reverts the row.
REQUIRED, and the whole decision this route exists to make. Defaulting it either way would turn a typo into a live checkout change: false silently removes a tender a client only meant to re-word, true puts one on offer nobody asked for. False is also the reversible form of removing a tender, and it is what this family publishes instead of a DELETE.
The payment directions the shopper is shown at checkout: where to wire the money, who to make the cheque out to. Send null or omit the key to clear them. Longer than the limit is REFUSED rather than truncated, because a silently shortened bank account number is discovered by a shopper rather than by the client that sent it. It is merchant-authored PUBLIC text, not a credential: every shopper reaching checkout already sees it.
4000Response
Success