commerce
GET /v1/orders/{orderId}/payment-options
The payment gateways this order may be settled on.
Authentication
Send an API key as a bearer token. This endpoint does not state a specific permission in the specification, so give your key the least it needs and check the response rather than assuming.
This endpoint takes no organisation id. Your key already identifies the organisation it belongs to, and the response is scoped to it.
Try it
Replace anything in angle brackets with your own values, and the key placeholder with a key from your dashboard.
curl -X GET https://api.zinndigital.com/v1/orders/{orderId}/payment-options \
-H "Authorization: Bearer zdk_live_…"Signed in? The API console in your dashboard fills in your real organisation id and your own key, and runs the request against the live API so you can see the actual response. Open this endpoint in the API console
Details
What the pay screen offers the customer, so an overdue bill can be settled through whichever enabled gateway they pick rather than only the one the subscription was created with. The answer is **per order, not per platform**. A reseller's client always receives exactly one entry — their reseller's connected gateway — whatever the platform has enabled, because that is the only merchant account their money may land in. `payOrder` refuses any `gateway` that is not in this list. Answers for a settled order too, with the same list: the question "what could pay this?" is meaningful for a receipt, and refusing would make the screen depend on a race with the webhook that settled it.
Parameters
| Name | Type | Required | What it is |
|---|---|---|---|
orderId (path) | Uuid | Yes | The order's id. |
Response
| Name | Type | Required | What it is |
|---|---|---|---|
gateways | string[] | Yes | Provider codes (`stripe`, `paypal`, `nowpayments`). Never empty — `stripe` is always present, because an unreadable provider registry must not be reported as "nothing is enabled". |
Errors this endpoint can return
401 · 403 · 404 · 429