Skip to main content
@dodopayments/bunパッケージは、Bunサーバーに3つのリクエストハンドラーを提供します。Checkoutはcheckout URLを返し、CustomerPortalは顧客をCustomer Portalに移動させ、Webhooksはwebhookイベントを検証してコードにルーティングします。各ハンドラーは標準のRequestを受け取り、Responseを返すため、Bun.serve()のfetchハンドラーから呼び出せます。

Checkout Handler

静的、動的、checkout sessionのフローでcheckout URLを作成します。

Customer Portal

顧客がサブスクリプションと詳細情報を管理できるようにします。

Webhooks

Dodo Payments webhookイベントを受信して処理します。

インストール

1

Install the Package

このコマンドをプロジェクトのルートで実行します:
このパッケージにはzod 3.25以降も必要で、peer dependencyとして指定されています。
2

Set Up Environment Variables

プロジェクトのルートに.envファイルを作成します。Developer → API KeysでAPI keyを作成します。Developer → Webhooksでwebhook endpointを追加し、そのSigning secretをDODO_PAYMENTS_WEBHOOK_KEYにコピーします:
Bunは.envファイルを自動的に読み込むため、例ではprocess.envからこれらの値を読み取ります。DODO_PAYMENTS_RETURN_URLはcheckout後に顧客が移動する場所です。environmentを渡さない場合、ハンドラーはlive_modeを使用します。test modeのAPI keyはtest_modeでのみ機能します。
.envファイルやsecretをversion controlにcommitしないでください。

Route Handlerの例

すべての例ではBunのネイティブサーバーBun.serve()を使用し、fetchハンドラーでpathとmethodによってリクエストをルーティングします。
このハンドラーを使用して、BunサーバーにDodo Payments checkoutを追加します。静的ハンドラーはGETリクエストを処理します。sessionおよびdynamicハンドラーはPOSTリクエストを処理します。dynamic checkoutの例では、サーバーがPOSTリクエストに対してdynamicCheckoutHandler(request)を返すことを前提としています。

Checkout Route Handler

checkoutハンドラーは、Dodo Paymentsで支払いを受け付ける次の3つの方法すべてに対応しています:
  • 静的Payment Links: コードなしで支払いを受け付ける共有可能なURL。
  • 動的Payment Links: カスタム詳細情報を指定して生成するpayment link。非推奨のendpointを使用します。
  • Checkout Sessions: 商品カート、顧客情報、カスタマイズオプションを備えたホスト型checkout。推奨されるフローです。
Checkoutは次のoptionsを受け取ります: このハンドラーはGETリクエストに対して静的checkoutを提供します。POSTリクエストの場合、typeがdynamicならdynamic payment linkを作成し、それ以外の場合はcheckout sessionを作成します。

対応するQuery Parameters

string
必須
商品のidentifier。例: ?productId=pdt_xxx。
integer
デフォルト:"1"
商品の数量。
string
顧客の氏名。firstNameまたはlastNameが指定されている場合は無視されます。
string
顧客の名。
string
顧客の姓。
string
顧客のemail address。
string
ISO 3166-1 alpha-2 codeによる顧客の国。
string
顧客のstreet address。
string
顧客の市区町村。
string
顧客の州または都道府県。
string
顧客のZIPまたはpostal code。
boolean
trueに設定すると、氏名フィールドを無効にします。
boolean
trueに設定すると、名フィールドを無効にします。
boolean
trueに設定すると、姓フィールドを無効にします。
boolean
trueに設定すると、emailフィールドを無効にします。
boolean
trueに設定すると、国フィールドを無効にします。
boolean
trueに設定すると、address lineフィールドを無効にします。
boolean
trueに設定すると、市区町村フィールドを無効にします。
boolean
trueに設定すると、州フィールドを無効にします。
boolean
trueに設定すると、ZIP codeフィールドを無効にします。
string
支払い通貨。例: USD。
boolean
デフォルト:"true"
通貨selectorを表示または非表示にします。
number
請求額を主要通貨単位で固定します。例: $12.50の場合は12.5。Pay What You Want商品のみで機能し、商品の最低価格未満の場合は無視されます。
boolean
デフォルト:"true"
discountsセクションを表示または非表示にします。
string
metadata_で始まるquery parameterはmetadataとしてcheckoutに渡されます。例: metadata_orderId=123。
disable flagは、対応するフィールドに値がある場合のみ有効になります。例: disableEmail=trueと組み合わせたemail。ハンドラーはconfigのreturnUrlをredirect_urlとしてlinkに追加します。
productIdがない場合、ハンドラーは400 responseを返します。無効なquery parameterや、アカウントに存在しない商品でも400を返します。

Response Format

静的checkoutはcheckout URLを含むJSON responseを返します。test modeでは、URLにtest.checkout.dodopayments.comを使用します:
  • パラメーターをPOST requestのJSON bodyとして送信します。
  • 一回限りの支払いと継続支払いの両方に対応します。ハンドラーは商品を取得し、商品がrecurringならsubscriptionを、それ以外なら一回限りのpaymentを作成します。
  • bodyにはbilling(street、city、state、country、zipcodeを含む)とcustomerに加えて、product_idまたはproduct_cartが必要です。subscriptionにはproduct_idが必要です。
  • 対応するbody fieldはすべて次を参照してください:
Dynamic checkoutは非推奨のPOST /paymentsおよびPOST /subscriptions endpointのproxyとして動作します。既存のintegrationでは引き続き機能しますが、新しいintegrationではcheckout sessionsを使用してください。

Response Format

Dynamic checkoutは、payment linkをcheckout URLとして含むJSON responseを返します:
Checkout sessionsは、一回限りの購入とsubscription向けに、カスタマイズを完全に制御できるホスト型checkoutを作成します。必須フィールドはproduct_cartのみで、少なくとも1つの商品が必要です。bodyにreturn_urlがない場合、ハンドラーはconfigのreturnUrlを使用します。各checkout_urlは1回だけ使用でき、24時間後に期限切れになります。confirm: trueを渡した場合は15分後に期限切れになります。payment_method_idで作成したsessionはcheckout_urlを返さないため、ハンドラーは400を返します。詳細および対応するすべてのfieldについては、Checkout Sessions Integration Guideを参照してください。

Response Format

Checkout sessionsはcheckout URLを含むJSON responseを返します:

Customer Portal Route Handler

Customer Portal route handlerは、指定された顧客のCustomer Portal sessionを作成し、ブラウザーをそこへリダイレクトします。CustomerPortalは、Checkoutと同じbearerTokenおよびenvironment optionsを受け取ります。
このハンドラーは、誰が呼び出しているかを確認しません。customer IDを指定してリクエストした人は誰でも、その顧客のportalを取得できます。独自のauthenticationでrouteを保護し、サインイン中のユーザーのcustomer IDのみを渡してください。

Query Parameters

string
必須
portal sessionの顧客ID。例: ?customer_id=cus_123。
boolean
trueに設定すると、Dodo Paymentsは顧客にportal linkもemailで送信します。
customer_idがない場合、ハンドラーは400を返し、portal sessionを作成できない場合は500を返します。

Webhook Route Handler

webhook route handlerは、コードを実行する前に、webhookKeyとして渡されたwebhook secretで各リクエストを検証します:
  • Method: POST requestのみ対応しています。その他のmethodは405を返します。
  • Signature Verification: webhookKeyを使用し、Standard Webhooks仕様に従ってwebhook-id、webhook-timestamp、webhook-signature headersを検証します。検証に失敗すると401を返します。
  • Payload Validation: bodyをJSONとしてparseし、Zodで検証します。無効なJSONまたはpayloadには400を返します。
  • Error Handling:
    • 401: 無効なsignature
    • 400: 無効なpayload
    • 500: 検証中の内部エラー
  • Event Routing: すべてのeventに対してonPayloadを呼び出し、その後eventのtypeに対応するhandlerを呼び出して200を返します。
adaptorは、ハンドラーでthrowされたエラーを捕捉しません。エラーはBun.serve()に伝播し、requestは失敗します。

対応するWebhook Event Handler

各handlerは任意でasyncです。また、対応するevent typeの検証済みpayloadを受け取ります:
各eventの意味については、Webhook Event Guideを参照してください。

LLM向けPrompt

このpromptをAI coding assistantにコピーすると、projectにadaptorを追加できます。agentにDodo Paymentsのdocsとskillsも提供するには、Agent Pluginをインストールしてください。
最終更新日 2026年9月26日