Skip to main content

前提条件

開始する前に、以下が必要です。
  • Dodo Paymentsのマーチャントアカウント
  • ダッシュボードの Developer → API Keys にあるAPI key。DODO_PAYMENTS_API_KEY に保存します
  • Developer → Webhooks にあるwebhook secret。DODO_PAYMENTS_WEBHOOK_KEY に保存します
  • Products で作成したサブスクリプションプロダクトが少なくとも1つ
詳しくは、Integration Guide Prerequisitesを参照してください。

API連携

Checkout Sessions

サブスクリプションプロダクトを使用してcheckout sessionを構築し、サブスクリプションを作成します。顧客が支払い方法を承認し、チェックアウトを完了するとサブスクリプションが有効になります。
同じ checkout session 内で、subscription product と one-time product を組み合わせることができます。これにより、セットアップ料金、SaaS とハードウェアのバンドル、その他同様のユースケースに対応できます。例については Checkout Sessions を参照してください。1 回の checkout で 2 つ以上の subscription product を販売することもできます。顧客は 1 回支払い、product ごとに独立した subscription を 1 つずつ取得します。それぞれに独自の billing cycle があります。このようなカートには one-time product を含めることはできません。Multi-Subscription Cart を参照してください。

API Response

レスポンスには checkout_url が含まれます。
顧客をこの URL にリダイレクトします。顧客は payment method を承認し、subscription が有効になります。

Webhooks

Webhooks は subscription event が発生したときにサーバーへ通知します。ダッシュボードの Developer → Webhooks で endpoint を設定してください。 webhook endpoint の設定方法については、Webhooks を参照してください。

Subscription Event Types

subscription lifecycle を管理するため、以下の event を追跡します。
  1. subscription.active — Subscription が有効化された
  2. subscription.updated — Subscription のフィールドが変更された
  3. subscription.on_hold — 更新または plan-change の charge に失敗した
  4. subscription.failed — Subscription の作成に失敗した(terminal。顧客は再 subscription が必要)
  5. subscription.renewed — recurring charge に成功した
  6. subscription.past_due — 更新に失敗し、grace period が開始された。顧客は past_due_ends_at まで access を維持する
  7. subscription.plan_changed — plan が upgrade、downgrade、または変更された
  8. subscription.cancelled — Subscription がキャンセルされた
  9. subscription.expired — Subscription が契約期間の終了に達した
これらが主要な event です。paused、unpaused、update_payment_method を含む完全な一覧については、Subscription Webhooks を参照してください。
subscription.updated を使用すると、subscription の変更に関するリアルタイム通知を取得できます。API をポーリングせずにアプリケーションの状態を同期できます。

Payment Scenarios

Successful Payment Flow webhook のシーケンスは、subscription に trial があるかどうかによって異なります。 Immediate billing(trial 0 日):
  1. subscription.active: mandate が承認され、subscription が有効化されます。
  2. payment.succeeded: 最初の charge を確認します。checkout から 2〜10 分以内 に発生します。
Trial period がある場合:
  1. Trial 開始時(checkout): payment method が承認されると subscription.active が発生します。この時点では recurring charge は発生しません。 最初の実際の charge は trial 終了まで延期されます。
  2. Trial 終了時: recurring amount が請求され、payment.succeeded と subscription.renewed を同時に受信します。
以降の各更新:
  • subscription.renewed: 各 billing cycle で更新 payment が引き落とされると発生し、常に payment.succeeded とともに送信されます。更新された next_billing_date も含まれます。
subscription product に対して実際に資金が引き落とされるたびに、subscription.renewed と payment.succeeded を受信します。次の cycle の access を延長するシグナルとして、payment.succeeded 単独ではなく subscription.renewed を使用してください。
Payment Failure Scenarios
  1. Subscription Failure
  • subscription.failed - mandate の作成に失敗したため、Subscription の作成に失敗しました。
  • payment.failed - payment の失敗を示します。
  1. Subscription On Hold
  • subscription.on_hold - 更新 payment または plan change charge の失敗により、Subscription が on hold になります。ビジネスに grace period がある場合、更新の失敗によって Subscription はまず past_due(subscription.past_due)に移行し、grace period の終了時にのみ on_hold(または grace period の設定に応じて cancelled)へ移行します。Subscription States を参照してください。
  • Subscription が on hold になると、payment method が更新されるまで自動的に更新されません。
Best Practice: 実装を簡単にするため、subscription lifecycle の管理では主に subscription event を追跡することを推奨します。
error_code/error_message の読み取り方、retry のタイミング、顧客への失敗の通知方法を含む完全な手順については、Handle Payment Failures を参照してください。

subscription.failed と subscription.on_hold

これら 2 つの event は混同しやすいものの、必要な対応は大きく異なります。
subscription.failed は terminal です。Subscription は再有効化できません。顧客は新しい subscription を作成する必要があります。この event が発生した場合、entitlement を付与しないでください。

Handling Subscription On Hold

Subscription が on_hold state になった場合、再有効化するには payment method を更新する必要があります。このセクションでは、subscription が on hold になるタイミングと対応方法を説明します。

Subscription が On Hold になるタイミング

以下の場合、Subscription は on hold になります。
  • 更新 payment の失敗: 資金不足、カードの有効期限切れ、または bank decline により自動更新 charge に失敗した
  • Plan change charge の失敗: plan の upgrade/downgrade 中に発生した即時 charge に失敗した
  • Payment method authorization の失敗: recurring charge に対して payment method を承認できない
on_hold state の Subscription は自動的に更新されません。Subscription を再有効化するには payment method を更新する必要があります。

On Hold の Subscription の再有効化

on_hold state の subscription を再有効化するには、Update Payment Method API を使用します。これにより自動的に以下が行われます。
  1. 未払い残額の charge を作成
  2. charge の invoice を生成
  3. 新しい payment method で payment を処理
  4. payment 成功時に subscription を active state へ再有効化
1

Handle subscription.on_hold webhook

subscription.on_hold webhook を受信したら、アプリケーションの state を更新し、顧客に通知します。
2

Update payment method

顧客が payment method を更新する準備ができたら、Update Payment Method API を呼び出します。
顧客が保存済みの payment method を持っている場合は、既存の payment method ID も使用できます。
3

Monitor webhook events

payment method の更新後、以下の webhook event を監視します。
  1. payment.succeeded - 未払い残額の charge に成功した
  2. subscription.active - Subscription が再有効化された

Subscription Event Payload の例


Subscription Plan の変更

change plan API endpoint を使用して、subscription plan を upgrade または downgrade できます。これにより、subscription の product と quantity を変更し、proration を処理できます。

Change Plan API Reference

subscription plan の変更について詳しくは、Change Plan API のドキュメントを参照してください。

Proration Options

subscription plan の変更時には、即時 charge の処理方法として 4 つの option があります。

1. prorated_immediately

  • 現在の billing cycle の未使用部分を、残り時間に応じて prorate して credit します。credit の対象は base plan、quantity、add-on です
  • その後、新しい plan、quantity、add-on で full cycle を charge します。charge 自体は proration されません
  • 即時 charge の純額 =(新しい cycle 全額)-(残りの割合 × 古い cycle 全額)。credit の方が大きい場合、差額は subscription-scoped credit として将来の更新に保持されます
  • trial period 中は、ユーザーを直ちに新しい plan に切り替え、顧客にすぐ charge します

2. full_immediately

  • 前の cycle に対する credit なしで、新しい plan の subscription amount 全額を顧客に charge します
  • upgrade と downgrade のどちらでも、顧客は新しい plan の価格全額を最初から支払います
  • 古い plan の残り時間にかかわらず全額を charge したい場合に便利です

3. difference_immediately

  • 顧客は古い plan の価格と新しい plan の価格の差額のみを支払います
  • 金額は cycle のいつ変更したかに左右されません。同じ upgrade であれば、1 日目でも 29 日目でも費用は同じです
  • upgrade の場合、顧客には差額が直ちに charge されます。例: $30/月 → $80/月 = $50 を即時 charge
  • downgrade の場合、価格差は subscription-scoped credit として保存され、将来の更新に自動適用されます。例: $50/月 → $20/月 = $30 を credit として保存

4. do_not_bill

  • plan の変更を直ちに適用しますが、変更時には何も charge しません。新しい plan、quantity、add-on はすぐに使用できます
  • 現時点で charge されないため、upgrade では現在の cycle の残り期間、高い plan を無料で利用できます。downgrade は、すでに支払った cycle の未使用部分に対する credit なしで直ちに適用されます
  • do_not_bill によって付与された add-on は、請求されていなかったため、後の plan change で credit されません。その後の変更では、新しい add-on quantity の全額が請求されます
  • 更新された plan(および quantity/add-on)は次回の予定された更新で請求され、元の billing date は維持されます
3 つの「今すぐ charge」mode はすべて billing cycle をリセットします。 prorated_immediately、difference_immediately、full_immediately は、subscription の next_billing_date を変更日に移動します。元の更新日を維持するのは do_not_bill だけですが、即時 charge は発生しません。

Behavior

  • この API を呼び出すと、Dodo Payments は選択した proration option に基づいて直ちに charge を開始します
  • prorated_immediately では、upgrade と downgrade のどちらでも、変更のたびに現在の cycle の未使用部分に対する credit が計算されます。その credit が新しい cycle の charge を上回る場合、残額は subscription の credit balance に追加されます。この credit はその subscription 専用であり、同じ subscription の将来の recurring payment を相殺するためにのみ使用されます
  • difference_immediately では、純額は常に正確な価格差になります。downgrade の場合、超過分は prorated_immediately と同様に subscription-scoped credit として保存されます
  • full_immediately option は credit の計算を行わず、新しい plan amount 全額を charge します
  • do_not_bill option は変更を直ちに適用しますが、billing を次回の更新日まで延期します。更新日は維持されます
Proration mode の選択:
  • difference_immediately — 顧客は価格差を支払います。最も予測しやすい option で、cycle のいつ変更しても charge は同じです。
  • prorated_immediately — 顧客には現在の cycle の未使用時間分だけ credit が付与されます。charge は cycle の変更時期によって変わります。
  • full_immediately — 顧客は新しい plan amount の全額を支払います。前の cycle に対する credit はありません。
  • do_not_bill — 今は charge しません。新しい plan は次回の更新時に請求されます。元の billing date を維持する唯一の mode です。

Charge Processing

  • plan change 時に開始された即時 charge は、通常 2 分未満で処理を完了します
  • この即時 charge が何らかの理由で失敗すると、問題が解決するまで Subscription は自動的に on hold になります

On-Demand Subscriptions

On-demand subscription を使用すると、固定スケジュールだけでなく、柔軟に顧客へ charge できます。この機能はすべての account で利用できます。
On-demand subscription を作成するには: on-demand subscription を作成するには、POST /checkouts API endpoint を使用し、request body に subscription_data.on_demand field を含めます。これにより、即時 charge なしで payment method を承認するか、カスタムの初回価格を設定できます。
POST /subscriptions は deprecated です。既存の integration では引き続き機能しますが、新しい integration では subscription_data.on_demand を指定した Checkout Session(POST /checkouts)を通じて on-demand subscription を作成してください。現在の flow については、On-Demand Subscriptions Guide を参照してください。
On-demand subscription に charge するには: 以降の charge には、POST /subscriptions//charge endpoint を使用し、その transaction で顧客に charge する amount を指定します。
request/response の例、安全な retry policy、webhook handling を含む完全な手順については、On-Demand Subscriptions Guide を参照してください。

Subscription Billing で知っておくべき重要事項

subscription period は payment frequency より長く設定してください。 subscription period が payment frequency と等しい場合(例: period = 1 month、frequency = 1 month)、subscription は単一の cycleのみ有効となり、その後更新されず expired に移行します。継続的な monthly plan には、長い subscription period(例: 20 years)と monthly payment frequency を設定してください。
Currency は最初の成功した charge で固定されます。 checkout の作成時には、billing_currency と billing_address.country を必ず明示的に渡してください。省略すると顧客の IP(Adaptive Currency)から検出され、subscription が最初の charge を受けると、その存続期間中 currency が固定されます。顧客が後で旅行しても変更できません。
Trial では charge ではなく $0 authorization が行われます。 subscription に trial がある場合、trial 開始時にカードを保存するため $0 mandate authorization が作成され、最初の実際の charge は trial 終了時に発生します。payments list では、free trial 中の subscription に total_amount が 0 の payment が正確に 1 件表示されます。paid trial では代わりに trial_amount が前払いで charge されます。
Subscription lifecycle: past_due = 更新に失敗し、grace period が進行中(顧客は access を維持)。on_hold = 更新に失敗(復旧可能。顧客に payment method の更新を促し、dunning retry が適用されます)。expired = 更新されないまま契約期間が終了し、再有効化できない。顧客は再 subscription が必要です。cancelled = 顧客または merchant によって終了。更新の失敗の多くは Dodo の error ではなく、issuer-side decline(資金不足、カード declined)です。
Indian card は RBI e-mandate で動作します。 off-session charge(更新および plan-change charge)の決済には最大約 48 時間かかる場合があり、₹15,000 を超える recurring auto-debit には新たな顧客認証が必要です(そのため、この上限を超える upgrade では既存の mandate を利用できません)。1 つの charge がまだ processing の間、同じ subscription に対する 2 つ目の charge は “Cannot create new charge as previous payment is not successful yet.” というエラーで失敗します。Indian 以外の card はほぼ即時に確認されます。
Subscription には USD で $1.00 の最低額があります。 Checkout は、合計がこれより低い場合に TOTAL_PAYMENT_AMOUNT_BELOW_MINIMUM_AMOUNT で拒否します。USD、EUR、GBP 以外の currency も少なくとも $1.00 相当である必要があります。Minimum Amounts を参照してください。product_price の on-demand charge が最小 currency unit で 100 未満の場合、product_price: value out of range で拒否されます。$0 とちょうど同額の subscription product は許可されます。Card-Optional at Zero Price を参照してください。カードに charge せず authorization を行うには、on-demand mandate_only setup を使用します。

関連 API Reference

Create Subscription (Deprecated)

subscription を直接作成するための Legacy API。新しい integration では Checkout Sessions を使用してください

Change Subscription Plan

proration option を使用して subscription plan を upgrade、downgrade、変更するための API reference

Update Payment Method

payment method の更新と on-hold subscription の再有効化のための API reference

Patch Subscription

subscription details と configuration を更新するための API reference
最終更新日 2026年10月8日