POST /v1/subscriptions/{subscriptionId}/prepay

認証

ベアラー トークンとして API キーを送信します。キーには billing.payment.manage 権限が付与されている必要があります。権限のないキーは 404 ではなく 403 で拒否されます。

このエンドポイントは組織IDを受け付けません。お使いのキーによって所属する組織がすでに特定されており、レスポンスはその組織にスコープされます。

試してみる

アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。

curl -X POST https://api.zinndigital.com/v1/subscriptions/{subscriptionId}/prepay \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "periods": <integer> }'

ログインしていますか？ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブAPIに対してリクエストが実行されるため、実際のレスポンスを確認することができます。 API コンソールでこのエンドポイントを開く

詳細

Mints an **unpaid** order for N whole billing periods. ⛔⛔ **No money is taken here.** The client then settles that order through `POST /v1/orders/{orderId}/pay`, which already knows how to pay from account balance, from a gateway, or from both. That separation is the point rather than an implementation detail: it is what lets a customer with **no chargeable mandate** use this at all — somebody paying in crypto, or in a market whose regulator forbids an off-session charge. They top up once and pay six months from their balance, with no card anywhere in the flow. Replaying the same request returns the **same** order rather than a second one, so a double-clicked button cannot bill twice. Asking for a *different* number of periods supersedes the earlier unpaid prepay order and mints a fresh one — a customer changing their mind is not a collision. An unpaid order against this subscription that is **not** a prepayment (a plan change, say) is refused with `ORDER_IN_FLIGHT` instead, and is never cancelled on the customer's behalf. Requires `billing.payment.manage`. `422` carries a `code` in its details: `TOO_FEW` / `TOO_MANY` (outside the allowed range), `NOT_PREPAYABLE` (ended, comped or free), `RAIL_NOT_SUPPORTED` (billed by PayPal on its own schedule), or `ORDER_IN_FLIGHT`.

パラメータ

リクエスト本文

返信

このエンドポイントが返すエラー

401 · 403 · 404 · 422 · 429