Skip to main content

前提条件

Dodo Payments APIを統合するには、次のものが必要です:
  • Dodo Paymentsのマーチャントアカウント
  • ダッシュボードからのAPI認証情報(APIキーとWebhookシークレットキー)
前提条件に関する詳細なガイドについては、このセクションを確認してください。

API統合

チェックアウトセッション

Checkout Sessionsを使用して、セキュリティで保護されたホスト型チェックアウトでサブスクリプション商品を販売します。サブスクリプション商品を product_cart に渡し、返された checkout_url に顧客をリダイレクトしてください。
Mixed Checkout: サブスクリプション商品を単発商品と同じチェックアウトセッションで組み合わせることができます。これにより、サブスクリプションに設定料金を追加したり、SaaSとハードウェアバンドルをまとめて提供したりするユースケースが可能になります。例については Checkout Sessions guide を参照してください。

APIレスポンス

以下はレスポンスの例です:
顧客を checkout_url にリダイレクトします。

Webhook

サブスクリプションを統合する際、サブスクリプションライフサイクルを追跡するためのWebhookを受信します。これらのWebhookは、サブスクリプションの状態や支払いシナリオを効果的に管理するのに役立ちます。 Webhookエンドポイントを設定するには、詳細な統合ガイドに従ってください。

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

以下のWebhookイベントは、サブスクリプションの状態変更を追跡します:
  1. subscription.active - サブスクリプションが正常に有効化されました。
  2. subscription.updated - サブスクリプションオブジェクトが更新されました(任意のフィールドが変更されたときに発火します)。
  3. subscription.on_hold - 更新失敗によりサブスクリプションが保留されました。
  4. subscription.failed - マンダート作成中にサブスクリプションの作成が失敗しました。
  5. subscription.renewed - 次回請求期間に向けてサブスクリプションが更新されました。
信頼性の高いサブスクリプションライフサイクル管理のために、これらのサブスクリプションイベントを追跡することをお勧めします。
subscription.updated を使用して、サブスクリプションの変更をリアルタイムで通知し、APIをポーリングせずにアプリケーション状態を同期させます。

支払いシナリオ

受信する webhook とそのタイミングは、商品に trial があるかどうかによって異なります。 即時請求(trial 日数 0 日):
  1. subscription.active: mandate が承認され、subscription が有効化されます。
  2. payment.succeeded: 初回 charge を確認します。checkout から 2〜10 分以内 に発生します。
trial 期間がある場合:
  1. trial 開始時(checkout): 支払い方法が承認されると subscription.active が 1 回発生します。この時点では定期 charge は発生しません。 初回の実際の charge は trial 終了まで延期されます。
  2. trial 終了時: 定期金額が charge され、payment.succeeded と同時に subscription.renewed を受信します。
その後の更新ごと:
  • subscription.renewed: 更新 payment が引き落とされる各 billing cycle で発生し、常に 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 - renewal payment または plan change charge の失敗により、subscription が on hold になります。
  • subscription が on hold になると、payment method が更新されるまで自動的には更新されません。
Best Practice: 実装を簡素化するため、subscription の lifecycle 管理では主に subscription event を追跡することをおすすめします。
error_code/error_message の読み取り方、retry のタイミング、customer への failure の提示方法について詳しくは、Handle Payment Failures を参照してください。

subscription.failedsubscription.on_hold の違い

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

Subscription On Hold の処理

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

Subscription が On Hold になる場合

subscription は次の場合に on hold になります。
  • Renewal payment の失敗: 残高不足、カードの有効期限切れ、または bank decline により、自動 renewal charge に失敗した場合
  • Plan change charge の失敗: plan の upgrade/downgrade 中に発生する即時 charge に失敗した場合
  • Payment method の承認失敗: 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 を受信したら、application state を更新し、customer に通知してください。
2

Update payment method

customer が payment method を更新する準備ができたら、Update Payment Method API を呼び出します。
customer が 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 documentation を参照してください。

Proration Options

サブスクリプションプランを変更する場合、即時請求の処理方法には4つの選択肢があります:

1. prorated_immediately

  • 現在の billing cycle の残り時間に基づいて prorated amount を計算
  • old plan と new plan の差額のみを customer に charge
  • trial 期間中は user を直ちに new plan に切り替え、customer に即時 charge

2. full_immediately

  • new plan の subscription amount 全額を customer に charge
  • previous plan の残り時間や credit を無視
  • billing cycle を reset したい場合や、proration に関係なく全額を charge したい場合に便利

3. difference_immediately

  • upgrade すると、2 つの plan amount の差額が customer に即時 charge されます。
  • たとえば、current plan が 30 Dollars で customer が 80 Dollars の plan に upgrade すると、$50 が即時に charge されます。
  • downgrade すると、current plan の未使用 amount が internal credit として追加され、今後の subscription renewal に自動的に適用されます。
  • たとえば、current plan が 50 Dollars で customer が 20 Dollars の plan に切り替えると、残りの $30 が credit として付与され、次の billing cycle に使用されます。

4. do_not_bill

  • plan change を即時に適用しますが、変更時には 何も charge しません
  • 更新後の plan(および quantity/add-ons)は次回予定されている renewalで請求され、元の billing date は維持されます
3 つの「今すぐ charge」mode はすべて billing cycle を reset します。 prorated_immediatelydifference_immediatelyfull_immediately は subscription の next_billing_date を変更日に移動します。元の renewal date を維持するのは do_not_bill のみですが、即時 charge は発生しません。

Behavior

  • この API を呼び出すと、Dodo Payments は選択した proration option に基づいて直ちに charge を開始します
  • plan change が downgrade で、prorated_immediately を使用した場合、credit が自動的に計算され、subscription の credit balance に追加されます。これらの credit はその subscription 専用であり、同じ subscription の今後の recurring payment の offset にのみ使用されます
  • full_immediately option は credit の計算を bypass し、新しい plan の金額全額を charge します
proration option は慎重に選択してください: 未使用時間を考慮した公平な billing には prorated_immediately を使用し、current billing cycle に関係なく new plan の金額全額を charge したい場合は full_immediately を使用してください。

Charge Processing

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

On-Demand Subscriptions

Create Subscription

サブスクリプション製品の作成およびサブスクリプションライフサイクルの管理に関する API リファレンス

Change Subscription Plan

プロレートオプションを使用したサブスクリプションプランのアップグレード、ダウングレード、または変更に関する API リファレンス

Update Payment Method

支払い方法の更新および保留中のサブスクリプションの再有効化に関する API リファレンス

Patch Subscription

サブスクリプション詳細および設定の更新に関する API リファレンス
on-demand subscription を作成するには: on-demand subscription を作成するには、POST /subscriptions API endpoint を使用し、request body に on_demand field を含めます。これにより、即時 charge なしで payment method を承認するか、custom initial price を設定できます。
POST /subscriptions非推奨 です。既存の統合では引き続き動作しますが、新しい統合では、subscription_data.on_demand を使用して Checkout SessionPOST /checkouts)経由でオンデマンドサブスクリプションを作成してください。現在のフローについては、オンデマンドサブスクリプションガイド を参照してください。
オンデマンドサブスクリプションに請求するには: 後続の請求には、POST /subscriptions//charge エンドポイントを使用し、その取引で顧客に請求する金額を指定します。
リクエストとレスポンスの例、安全な再試行ポリシー、webhook の処理を含む、完全な手順ガイドについては、オンデマンドサブスクリプションガイドを参照してください。

サブスクリプション請求で知っておくべき重要事項

サブスクリプション期間は支払い頻度より長く設定してください。 サブスクリプション期間と支払い頻度が同じ場合(例:期間 = 1か月、頻度 = 1か月)、サブスクリプションは 1サイクルのみ 有効となり、更新されずに expired に移行します。継続的な月額プランには、長いサブスクリプション期間(例:20年)を設定し、支払い頻度を月次にしてください。
通貨は最初の請求が成功した時点で固定されます。 checkout の作成時には、billing_currency billing_address.country を必ず明示的に渡してください。省略すると、顧客の IP(Adaptive Currency)から検出され、サブスクリプションの最初の請求が行われた時点で、その存続期間中の通貨が固定されます。その後、顧客が旅行しても通貨を切り替えることはできません。
トライアルでは請求ではなく、$0 のオーソリが行われます。 サブスクリプションにトライアルがある場合、トライアル開始時にカードを保存するため $0 の mandate authorization が作成され、最初の実際の請求はトライアル終了時に行われます。支払い一覧では、トライアル中のサブスクリプションに amount: 0 を含む支払いがちょうど1件表示されます。
サブスクリプションのライフサイクル: on_hold = 更新に失敗した状態(回復可能:顧客に支払い方法の更新を促します。督促の再試行が適用されます)。expired = 更新されないまま期間が終了した状態で、再有効化できません。顧客は再度サブスクライブする必要があります。cancelled = 顧客またはマーチャントによって終了された状態。更新の失敗の多くは issuer 側の拒否(残高不足、カード拒否)であり、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 で拒否されます。許可されるのは、オンデマンドの mandate_only セットアップを通じた $0 のみです。

関連する API リファレンス

Create Subscription

サブスクリプション商品の作成とサブスクリプションのライフサイクル管理に関する API リファレンス

Change Subscription Plan

プロレーションのオプションを使用した、サブスクリプションプランのアップグレード、ダウングレード、変更に関する API リファレンス

Update Payment Method

支払い方法の更新と保留中のサブスクリプションの再有効化に関する API リファレンス

Patch Subscription

サブスクリプションの詳細と設定の更新に関する API リファレンス
最終更新日 2026年8月21日