前提条件
開始する前に、以下が必要です。- Dodo Paymentsのマーチャントアカウント
- ダッシュボードの Developer → API Keys にあるAPI key。
DODO_PAYMENTS_API_KEYに保存します - Developer → Webhooks にあるwebhook secret。
DODO_PAYMENTS_WEBHOOK_KEYに保存します - Products で作成したサブスクリプションプロダクトが少なくとも1つ
API連携
Checkout Sessions
サブスクリプションプロダクトを使用してcheckout sessionを構築し、サブスクリプションを作成します。顧客が支払い方法を承認し、チェックアウトを完了するとサブスクリプションが有効になります。- Node.js SDK
- Python SDK
- REST API
APIレスポンス
レスポンスにはcheckout_urlが含まれます。
Webhooks
webhookは、サブスクリプションイベントが発生したときにサーバーへ通知します。ダッシュボードの Developer → Webhooks でエンドポイントを設定してください。 webhookエンドポイントの設定については、Webhooksを参照してください。サブスクリプションイベントタイプ
サブスクリプションのライフサイクルを管理するため、以下のイベントを追跡します。subscription.active— サブスクリプションが有効化されたsubscription.updated— サブスクリプションのフィールドが変更されたsubscription.on_hold— 更新またはプラン変更の請求が失敗したsubscription.failed— サブスクリプションの作成に失敗した(終端状態。顧客は再登録が必要)subscription.renewed— 定期請求に成功したsubscription.past_due— 更新に失敗し、猶予期間が開始された。顧客はpast_due_ends_atまでアクセスを維持するsubscription.plan_changed— プランがアップグレード、ダウングレード、または変更されたsubscription.cancelled— サブスクリプションがキャンセルされたsubscription.expired— サブスクリプションが契約期間の終了に達した
paused、unpaused、update_payment_methodを含む完全な一覧については、Subscription Webhooksを参照してください。
支払いシナリオ
支払い成功フロー webhookのシーケンスは、サブスクリプションにtrialがあるかどうかによって異なります。 即時請求(trial日数が0日)の場合:subscription.active:mandateが承認され、サブスクリプションが有効になります。payment.succeeded:初回請求を確認します。チェックアウトから 2~10分以内 に発生します。
- trial開始時(チェックアウト時): 支払い方法が承認されると
subscription.activeが発生します。この時点では定期請求は行われません。 最初の実際の請求はtrial終了まで延期されます。 - trial終了時: 定期料金が請求され、
payment.succeededをsubscription.renewedと同時に受信します。
subscription.renewed:各請求サイクルで更新料金が引き落とされると発生し、常にpayment.succeededと同時に送信されます。更新されたnext_billing_dateも含まれます。
サブスクリプションプロダクトに対して実際に料金が引き落とされるたびに、
subscription.renewed と payment.succeededを受信します。次のサイクルへのアクセスを延長するシグナルとして、payment.succeeded単独ではなくsubscription.renewedを使用してください。- サブスクリプションの失敗
subscription.failed- mandateの作成に失敗したため、サブスクリプションの作成に失敗しました。payment.failed- 支払いの失敗を示します。
- サブスクリプションの保留
subscription.on_hold- 更新支払いまたはプラン変更の請求に失敗したため、サブスクリプションが保留になります。ビジネスに猶予期間がある場合、更新の失敗によってサブスクリプションはまずpast_due(subscription.past_due)に移行し、猶予期間が終了した場合のみon_hold(または猶予期間の設定に応じてcancelled)に移行します。Subscription Statesを参照してください。- サブスクリプションが保留になると、支払い方法が更新されるまで自動更新されません。
ベストプラクティス:実装を簡素化するため、サブスクリプションのライフサイクル管理では、主にサブスクリプションイベントを追跡することを推奨します。
subscription.failedとsubscription.on_holdの違い
この2つのイベントは混同しやすいですが、必要な対応は大きく異なります。
保留中のサブスクリプションの処理
サブスクリプションがon_hold状態になると、再有効化するために支払い方法を更新する必要があります。このセクションでは、サブスクリプションが保留になるタイミングと、その処理方法を説明します。
サブスクリプションが保留になるタイミング
サブスクリプションは、次の場合に保留になります。- 更新支払いの失敗:残高不足、カードの有効期限切れ、銀行による拒否などにより、自動更新の請求に失敗した
- プラン変更の請求の失敗:プランのアップグレードまたはダウングレード時の即時請求に失敗した
- 支払い方法の承認の失敗:定期請求の支払い方法を承認できない
保留中のサブスクリプションの再有効化
on_hold状態のサブスクリプションを再有効化するには、Update Payment Method APIを使用します。これにより自動的に次の処理が行われます。
- 未払い残額の請求を作成
- 請求に対するinvoiceを生成
- 新しい支払い方法で支払いを処理
- 支払い成功時にサブスクリプションを
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イベントを監視します。
payment.succeeded- 未払い残額の請求に成功した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で付与されたアドオンは請求されていないため、後のプラン変更時にクレジットされません。その後の変更では新しいアドオン数量が全額請求されます- 更新されたプラン(および数量/アドオン)は次回予定の更新時に請求され、元の請求日は維持されます
動作
- このAPIを呼び出すと、選択した日割り計算オプションに基づいて、Dodo Paymentsが直ちに請求を開始します
prorated_immediatelyでは、アップグレードとダウングレードのどちらでも、変更のたびに現在のサイクルの未使用分に対するクレジットが計算されます。クレジットが新しいサイクルの請求額を超える場合、残額はサブスクリプションのクレジット残高に追加されます。このクレジットはそのサブスクリプション専用で、同じサブスクリプションの将来の定期支払いとの相殺にのみ使用されますdifference_immediatelyでは、正味額は常に正確な料金差額になります。ダウングレードでは、余剰分がprorated_immediatelyと同様にサブスクリプション専用クレジットとして保存されますfull_immediatelyオプションではクレジット計算を行わず、新しいプランの全額を請求しますdo_not_billオプションでは変更を直ちに適用しますが、請求は維持された次回更新日まで延期されます
請求処理
- プラン変更時に開始された即時請求は、通常2分未満で処理が完了します
- この即時請求が何らかの理由で失敗すると、問題が解決するまでサブスクリプションは自動的に保留になります
オンデマンドサブスクリプション
オンデマンドサブスクリプションでは、固定スケジュールに限らず、柔軟に顧客へ請求できます。この機能はすべてのアカウントで利用できます。
subscription_data.on_demandフィールドを含めます。これにより、即時請求なしで支払い方法を承認したり、カスタム初回価格を設定したりできます。
オンデマンドサブスクリプションに請求するには:
その後の請求には、POST /subscriptions//charge endpointを使用し、その取引で顧客に請求する金額を指定します。
リクエスト/レスポンスの例、安全な再試行ポリシー、webhook処理を含む完全な手順については、On-Demand Subscriptions Guideを参照してください。
サブスクリプション請求について知っておくべき主なこと
trialでは請求ではなく$0の承認が行われます。 サブスクリプションにtrialがある場合、trial開始時にカードを保存するための**$0のmandate承認**が作成され、最初の実際の請求はtrial終了時に行われます。支払い一覧では、無料trial中のサブスクリプションには
total_amountが0の支払いがちょうど1件表示されます。有料trialでは、代わりにtrial_amountが前払いで請求されます。サブスクリプションのライフサイクル:
past_due = 更新に失敗し、猶予期間が進行中(顧客はアクセスを維持)。on_hold = 更新に失敗(回復可能。顧客に支払い方法の更新を促し、督促の再試行が適用されます)。expired = 更新されずに期間が終了し、再有効化できない。顧客は再登録する必要があります。cancelled = 顧客またはマーチャントによって終了。更新失敗の大半はDodoのエラーではなく、発行会社側の拒否(残高不足、カード拒否)です。関連APIリファレンス
Create Subscription (Deprecated)
サブスクリプションを直接作成するためのLegacy API。新しい連携ではCheckout Sessionsを使用してください
Change Subscription Plan
日割り計算オプションを使用してサブスクリプションプランをアップグレード、ダウングレード、変更するためのAPIリファレンス
Update Payment Method
支払い方法を更新し、保留中のサブスクリプションを再有効化するためのAPIリファレンス
Patch Subscription
サブスクリプションの詳細と設定を更新するためのAPIリファレンス