commerce

POST /v1/orders/{orderId}/pay

Pay an order that was placed but not charged.

Semua titik akhir commerce

Pengesahan

Hantar kunci API sebagai token pembawa. Titik akhir ini tidak menyatakan kebenaran tertentu dalam spesifikasi, jadi berikan kunci anda kebenaran minimum yang diperlukan dan semak respons tersebut daripada membuat andaian.

Titik akhir ini tidak memerlukan id organisasi. Kunci anda telah mengenal pasti organisasi kepunyaannya, dan respons dis skopkan kepadanya.

Cuba

Gantikan apa sahaja di dalam kurungan sudut dengan nilai anda sendiri, dan pemegang tempat kunci dengan kunci dari papan pemuka anda.

curl -X POST https://api.zinndigital.com/v1/orders/{orderId}/pay \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{  }'

Sudah log masuk? Konsol API dalam papan pemuka anda mengisi id organisasi sebenar dan kunci anda sendiri, serta menjalankan permintaan terhadap API langsung supaya anda boleh melihat respons sebenar. Buka penamat ini dalam konsol API

Butiran

Charges an order left `pending_payment` (or retries one that is `payment_failed`), wallet credit first and the remainder on the org's default mandate. This is where the guest funnel's `next: "payment"` step lands: checkout converts the cart when it places the order, so the cart endpoint cannot settle it afterwards and this is the only surface that can. **Idempotent without an `Idempotency-Key`**, unlike checkout. The order already exists and is itself the dedup scope, so a double-submit records the same capture rather than taking a second one. A pay attempt against an already-paid order returns that order unchanged rather than an error. A **declined card answers 200**, not 402: the attempt was processed exactly as asked and the order comes back `payment_failed` for the caller to read. Only the platform being unable to charge at all — no gateway configured, or one an operator has deliberately disabled — is a 503. **Choosing a gateway.** Send `gateway` to settle this order on a specific rail rather than the org's default mandate — the owner's *"settle overdue bills with any gateway they like"*. It must be one of `getOrderPaymentOptions`'s entries, which is why a reseller's client (who has exactly one) cannot be re-routed. Rails that finish in the browser — PayPal approval, a crypto invoice — answer `200` with the order still `pending_payment` and a `customer_action` carrying the URL to send the customer to; the order settles when the gateway's webhook confirms it.

Parameter

NamaJenisDiperlukanApakah ia
orderId (path)UuidYaThe order's id.

Badan permintaan

NamaJenisDiperlukanApakah ia
gatewaystringTidakThe rail to settle on (`stripe`, `paypal`, `nowpayments`). Omit to use the org's nominated payment method. `422` if it is not one of this order's `getOrderPaymentOptions`.

Respons

NamaJenisDiperlukanApakah ia
idUuidYaUUIDv7 identifier — sortable by creation time (docs/02 §8).
org_idUuidYaUUIDv7 identifier — sortable by creation time (docs/02 §8).
human_refstringYaHuman-friendly order reference.
statusOrderStatusYaAn order's lifecycle state (docs/31 §4.3).
currencyCurrencyCodeYaISO 4217 currency code (money is minor units + this code — CLAUDE.md §2.8).
subtotal_minorintegerYa
tax_minorintegerYa
discount_minorintegerYa
total_minorintegerYa
billing_countryobjectTidak
placed_atobjectTidak
created_atstringYa
updated_atstringTidak
linesOrderLine[]Ya
paymentsPayment[]Ya
customer_actionobjectTidakPresent only when the attempt needs the customer to finish it in a browser (PayPal approval, a crypto invoice, a 3-D Secure step). Short-lived and never stored — request it agai…

Ralat yang boleh dikembalikan oleh titik akhir ini

401 · 403 · 404 · 422 · 429 · 503