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で、サブスクリプションプロダクトと一回限りのプロダクトを組み合わせることもできます。これにより、セットアップ料金、SaaSとのハードウェアバンドル、その他類似のユースケースに対応できます。例については、Checkout Sessionsを参照してください。

APIレスポンス

レスポンスにはcheckout_urlが含まれます。
顧客をこのURLにリダイレクトします。顧客が支払い方法を承認すると、サブスクリプションが有効になります。

Webhooks

webhookは、サブスクリプションイベントが発生したときにサーバーへ通知します。ダッシュボードの Developer → Webhooks でエンドポイントを設定してください。 webhookエンドポイントの設定については、Webhooksを参照してください。

サブスクリプションイベントタイプ

サブスクリプションのライフサイクルを管理するため、以下のイベントを追跡します。
  1. subscription.active — サブスクリプションが有効化された
  2. subscription.updated — サブスクリプションのフィールドが変更された
  3. subscription.on_hold — 更新またはプラン変更の請求が失敗した
  4. subscription.failed — サブスクリプションの作成に失敗した(終端状態。顧客は再登録が必要)
  5. subscription.renewed — 定期請求に成功した
  6. subscription.past_due — 更新に失敗し、猶予期間が開始された。顧客はpast_due_ends_atまでアクセスを維持する
  7. subscription.plan_changed — プランがアップグレード、ダウングレード、または変更された
  8. subscription.cancelled — サブスクリプションがキャンセルされた
  9. subscription.expired — サブスクリプションが契約期間の終了に達した
これらが主要なイベントです。paused、unpaused、update_payment_methodを含む完全な一覧については、Subscription Webhooksを参照してください。
サブスクリプションの変更をリアルタイムで通知するにはsubscription.updatedを使用します。APIをポーリングせずに、アプリケーションの状態を常に同期できます。

支払いシナリオ

支払い成功フロー webhookのシーケンスは、サブスクリプションにtrialがあるかどうかによって異なります。 即時請求(trial日数が0日)の場合:
  1. subscription.active:mandateが承認され、サブスクリプションが有効になります。
  2. payment.succeeded:初回請求を確認します。チェックアウトから 2~10分以内 に発生します。
trial期間がある場合:
  1. trial開始時(チェックアウト時): 支払い方法が承認されるとsubscription.activeが発生します。この時点では定期請求は行われません。 最初の実際の請求はtrial終了まで延期されます。
  2. trial終了時: 定期料金が請求され、payment.succeededをsubscription.renewed と同時に受信します。
その後の各更新:
  • subscription.renewed:各請求サイクルで更新料金が引き落とされると発生し、常に payment.succeededと同時に送信されます。更新されたnext_billing_dateも含まれます。
サブスクリプションプロダクトに対して実際に料金が引き落とされるたびに、subscription.renewed と payment.succeededを受信します。次のサイクルへのアクセスを延長するシグナルとして、payment.succeeded単独ではなくsubscription.renewedを使用してください。
支払い失敗シナリオ
  1. サブスクリプションの失敗
  • subscription.failed - mandateの作成に失敗したため、サブスクリプションの作成に失敗しました。
  • payment.failed - 支払いの失敗を示します。
  1. サブスクリプションの保留
  • subscription.on_hold - 更新支払いまたはプラン変更の請求に失敗したため、サブスクリプションが保留になります。ビジネスに猶予期間がある場合、更新の失敗によってサブスクリプションはまずpast_due(subscription.past_due)に移行し、猶予期間が終了した場合のみon_hold(または猶予期間の設定に応じてcancelled)に移行します。Subscription Statesを参照してください。
  • サブスクリプションが保留になると、支払い方法が更新されるまで自動更新されません。
ベストプラクティス:実装を簡素化するため、サブスクリプションのライフサイクル管理では、主にサブスクリプションイベントを追跡することを推奨します。
error_code/error_messageの読み取り、再試行のタイミングの判断、顧客への失敗通知について詳しくは、Handle Payment Failuresを参照してください。

subscription.failedとsubscription.on_holdの違い

この2つのイベントは混同しやすいですが、必要な対応は大きく異なります。
subscription.failedは終端状態です。サブスクリプションを再有効化することはできません。顧客は新しいサブスクリプションを作成する必要があります。このイベントが発生した場合、決して権利を付与しないでください。

保留中のサブスクリプションの処理

サブスクリプションがon_hold状態になると、再有効化するために支払い方法を更新する必要があります。このセクションでは、サブスクリプションが保留になるタイミングと、その処理方法を説明します。

サブスクリプションが保留になるタイミング

サブスクリプションは、次の場合に保留になります。
  • 更新支払いの失敗:残高不足、カードの有効期限切れ、銀行による拒否などにより、自動更新の請求に失敗した
  • プラン変更の請求の失敗:プランのアップグレードまたはダウングレード時の即時請求に失敗した
  • 支払い方法の承認の失敗:定期請求の支払い方法を承認できない
on_hold状態のサブスクリプションは自動更新されません。サブスクリプションを再有効化するには、支払い方法を更新する必要があります。

保留中のサブスクリプションの再有効化

on_hold状態のサブスクリプションを再有効化するには、Update Payment Method APIを使用します。これにより自動的に次の処理が行われます。
  1. 未払い残額の請求を作成
  2. 請求に対するinvoiceを生成
  3. 新しい支払い方法で支払いを処理
  4. 支払い成功時にサブスクリプションをactive状態へ再有効化
1

Handle subscription.on_hold webhook

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

Update payment method

顧客が支払い方法を更新できる状態になったら、Update Payment Method APIを呼び出します。
顧客が保存済みの支払い方法を持っている場合は、既存の支払い方法IDも使用できます。
3

Monitor webhook events

支払い方法を更新した後、以下のwebhookイベントを監視します。
  1. payment.succeeded - 未払い残額の請求に成功した
  2. subscription.active - サブスクリプションが再有効化された

サブスクリプションイベントペイロードの例


サブスクリプションプランの変更

change plan API endpointを使用して、サブスクリプションプランをアップグレードまたはダウングレードできます。これにより、サブスクリプションのプロダクト、数量、日割り計算を変更できます。

Change Plan API Reference

サブスクリプションプランの変更について詳しくは、Change Plan APIのドキュメントを参照してください。

日割り計算オプション

サブスクリプションプランを変更する際、即時請求の処理方法として4つのオプションがあります。

1. prorated_immediately

  • 残り時間に応じて現在の請求サイクルの未使用分を日割り計算し、クレジットします。クレジットは基本プラン、数量、アドオンを対象とします
  • その後、新しいプラン、数量、アドオンで1サイクル分全額を請求します。請求自体は日割り計算されません
  • 即時請求の正味額 = (新しいサイクルの全額)-(残りの割合 × 古いサイクルの全額)。クレジットの方が大きい場合、差額はサブスクリプションに紐付くクレジットとして将来の更新に使用されます
  • trial期間中はユーザーが直ちに新しいプランへ切り替わり、顧客に即時請求されます

2. full_immediately

  • 前のサイクルに対するクレジットなしで、新しいプランのサブスクリプション料金全額を請求します
  • アップグレードでもダウングレードでも、顧客は新しいプラン料金全額を最初から支払います
  • 古いプランの残り時間に関係なく全額を請求したい場合に便利です

3. difference_immediately

  • 顧客は古いプラン料金と新しいプラン料金の差額のみを支払います
  • 金額はサイクル内の変更時期に左右されません。同じアップグレードなら1日目でも29日目でも費用は同じです
  • アップグレード時は差額が直ちに請求されます。例:$30/月 → $80/月 = $50を即時請求
  • ダウングレード時は料金差額がサブスクリプションに紐付くクレジットとして保存され、将来の更新に自動適用されます。例:$50/月 → $20/月 = $30をクレジットとして保存

4. do_not_bill

  • プラン変更を直ちに適用しますが、変更時には何も請求しません。新しいプラン、数量、アドオンはすぐに利用できます
  • 今は請求されないため、アップグレードでは現在のサイクルの残り期間、高いプランを無料で利用できます。ダウングレードは、すでに支払ったサイクルの未使用分をクレジットせず、直ちに適用されます
  • do_not_billで付与されたアドオンは請求されていないため、後のプラン変更時にクレジットされません。その後の変更では新しいアドオン数量が全額請求されます
  • 更新されたプラン(および数量/アドオン)は次回予定の更新時に請求され、元の請求日は維持されます
3つすべての「今すぐ請求」モードでは請求サイクルがリセットされます。 prorated_immediately、difference_immediately、full_immediatelyは、サブスクリプションのnext_billing_dateを変更日に移動します。元の更新日を維持するのはdo_not_billのみですが、即時請求は行いません。

動作

  • このAPIを呼び出すと、選択した日割り計算オプションに基づいて、Dodo Paymentsが直ちに請求を開始します
  • prorated_immediatelyでは、アップグレードとダウングレードのどちらでも、変更のたびに現在のサイクルの未使用分に対するクレジットが計算されます。クレジットが新しいサイクルの請求額を超える場合、残額はサブスクリプションのクレジット残高に追加されます。このクレジットはそのサブスクリプション専用で、同じサブスクリプションの将来の定期支払いとの相殺にのみ使用されます
  • difference_immediatelyでは、正味額は常に正確な料金差額になります。ダウングレードでは、余剰分がprorated_immediatelyと同様にサブスクリプション専用クレジットとして保存されます
  • full_immediatelyオプションではクレジット計算を行わず、新しいプランの全額を請求します
  • do_not_billオプションでは変更を直ちに適用しますが、請求は維持された次回更新日まで延期されます
日割り計算モードの選択:
  • difference_immediately — 顧客は料金差額を支払います。最も予測しやすいオプションで、サイクル内の変更時期にかかわらず請求額は同じです。
  • prorated_immediately — 顧客には現在のサイクルの未使用時間分だけクレジットされます。請求額は変更時期によって変わります。
  • full_immediately — 顧客は新しいプランの全額を支払います。前のサイクルへのクレジットはありません。
  • do_not_bill — 今は請求しません。新しいプランは次回更新時に請求されます。元の請求日を維持できる唯一のモードです。

請求処理

  • プラン変更時に開始された即時請求は、通常2分未満で処理が完了します
  • この即時請求が何らかの理由で失敗すると、問題が解決するまでサブスクリプションは自動的に保留になります

オンデマンドサブスクリプション

オンデマンドサブスクリプションでは、固定スケジュールに限らず、柔軟に顧客へ請求できます。この機能はすべてのアカウントで利用できます。
オンデマンドサブスクリプションを作成するには: オンデマンドサブスクリプションを作成するには、POST /checkouts API endpointを使用し、リクエスト本文にsubscription_data.on_demandフィールドを含めます。これにより、即時請求なしで支払い方法を承認したり、カスタム初回価格を設定したりできます。
POST /subscriptionsは非推奨です。既存の連携では引き続き機能しますが、新しい連携では、subscription_data.on_demandを指定したCheckout Session(POST /checkouts)を使用してオンデマンドサブスクリプションを作成してください。現在のフローについては、On-Demand Subscriptions Guideを参照してください。
オンデマンドサブスクリプションに請求するには: その後の請求には、POST /subscriptions//charge endpointを使用し、その取引で顧客に請求する金額を指定します。
リクエスト/レスポンスの例、安全な再試行ポリシー、webhook処理を含む完全な手順については、On-Demand Subscriptions Guideを参照してください。

サブスクリプション請求について知っておくべき主なこと

サブスクリプション期間は支払い頻度より長く設定してください。 サブスクリプション期間が支払い頻度と等しい場合(例:期間 = 1か月、頻度 = 1か月)、サブスクリプションは1サイクルのみ有効で、その後更新されずexpiredに移行します。継続的な月額プランには、長いサブスクリプション期間(例:20年)と月次の支払い頻度を設定してください。
通貨は最初の支払い成功時に固定されます。 checkout作成時には、必ずbilling_currency と billing_address.countryを明示的に渡してください。省略すると顧客のIP(Adaptive Currency)から検出され、サブスクリプションの初回請求が行われた時点で、その通貨が存続期間中固定されます。顧客が後で旅行しても変更できません。
trialでは請求ではなく$0の承認が行われます。 サブスクリプションにtrialがある場合、trial開始時にカードを保存するための**$0のmandate承認**が作成され、最初の実際の請求はtrial終了時に行われます。支払い一覧では、無料trial中のサブスクリプションにはtotal_amountが0の支払いがちょうど1件表示されます。有料trialでは、代わりにtrial_amountが前払いで請求されます。
サブスクリプションのライフサイクル: past_due = 更新に失敗し、猶予期間が進行中(顧客はアクセスを維持)。on_hold = 更新に失敗(回復可能。顧客に支払い方法の更新を促し、督促の再試行が適用されます)。expired = 更新されずに期間が終了し、再有効化できない。顧客は再登録する必要があります。cancelled = 顧客またはマーチャントによって終了。更新失敗の大半はDodoのエラーではなく、発行会社側の拒否(残高不足、カード拒否)です。
インドのカードはRBI e-mandateで処理されます。 オフセッション請求(更新およびプラン変更の請求)は決済完了まで最大約48時間かかる場合があり、₹15,000を超える定期自動引き落としには顧客による新たな認証が必要です(そのため、この上限を超えるアップグレードは既存のmandateを利用できません)。1件の請求がまだprocessingの間、同じサブスクリプションへの2件目の請求は*“Cannot create new charge as previous payment is not successful yet.”*というエラーで失敗します。インド以外のカードはほぼ即時に確認されます。
サブスクリプション請求には$1の最低額(または通貨換算額)があります。$0.01–$0.99の金額はproduct_price: value out of rangeで拒否されます。価格がちょうど$0のサブスクリプションプロダクトは利用できます。Card-Optional at Zero Priceを参照してください。カードに請求せず承認するには、オンデマンドのmandate_only setupを使用します。

関連APIリファレンス

Create Subscription (Deprecated)

サブスクリプションを直接作成するためのLegacy API。新しい連携ではCheckout Sessionsを使用してください

Change Subscription Plan

日割り計算オプションを使用してサブスクリプションプランをアップグレード、ダウングレード、変更するためのAPIリファレンス

Update Payment Method

支払い方法を更新し、保留中のサブスクリプションを再有効化するためのAPIリファレンス

Patch Subscription

サブスクリプションの詳細と設定を更新するためのAPIリファレンス
最終更新日 2026年9月26日