テスト用ダミー決済ゲートウェイ:Casdoor の Dummy プロバイダー、Stripe テストモード、PayPal Sandbox
ダミー決済ゲートウェイとは、銀行やカードネットワークに連絡することなくすべてのチェックアウトを支払い済みとして受け入れる決済プロバイダーです。これにより、お金もゲートウェイアカウントも使わずに注文、サブスクリプション、履行(fulfillment)をテストできます。Casdoor にはこれがあります:Dummy payment provider。これを商品に追加し、商品を購入すると、Casdoor はサーバーの外に出ることなく、支払いと注文を Paid として記録し、サブスクリプションを開始し、取引を書き込みます。開発環境では Dummy を使用し、ステージング環境ではベンダーのサンドボックス(Stripe test mode、PayPal sandbox、Paddle sandbox)に切り替えてください。ステージング環境では、カード拒否、3-D Secure、実際のリダイレクトなども必要になります。
Dummy、Balance、およびベンダーサンドボックスの一覧
| プロバイダー | テスト環境 | Casdoor がテストまたは本番を選択する方法 | Casdoor プロバイダータイプ |
|---|---|---|---|
| Dummy | 不要、すべての支払いが成功する | 常にシミュレーションされる | Dummy |
| Balance | 内部、チャージ商品によって資金供給 | 常に内部 | Balance |
| Stripe | sk_test_ / pk_test_ キーによるサンドボックス | 入力したキーによる | Stripe |
| PayPal | サンドボックスアプリとサンドボックスアカウント | runmode が prod 以外の場合、サンドボックスを使用 | PayPal |
| Paddle | sandbox-vendors.paddle.com での別個のサンドボックスアカウント | runmode が prod 以外の場合、sandbox-api.paddle.com を使用 | Paddle |
| Adyen | テスト環境 (checkout-test.adyen.com) | runmode が prod 以外の場合、テスト環境を使用 | Adyen |
| AirWallex | Separate sandbox account | runmode other than prod calls api.sandbox.airwallex.com | AirWallex |
| Lemon Squeezy | テストモード API キーを用いたストアのテストモード | 入力した API キーによる | Lemon Squeezy |
| FastSpring | ホストに .test. を含むテストストアフロント | 入力した Host による | FastSpring |
| Polar | sandbox.polar.sh のサンドボックス | プロバイダーの Host を https://sandbox-api.polar.sh に設定する | Polar |
runmode は、構成リファレンスに記載されている conf/app.conf (または runmode 環境変数)内のオプションです。デフォルトは dev であるため、新しい Casdoor インスタンスは prod に設定するまで、PayPal、Paddle、Adyen、AirWallex のサンドボックスと通信します。
ダミートランザクションの意味
ダミートランザクションは、実際の購入と同じレコード(注文、支払い、サブスクリプション、台帳エントリ)を通りますが、お金は動きません。これはサンドボックストラザクションとは異なります。サンドボックスは依然としてベンダーの API を呼び出し、ベンダーのチェックアウトページを表示し、Webhook を送信します。偽物なのは金銭だけです。ダミートランザクションはシステムの外に出ることはありません。
この違いが、それぞれが何をテストできるかを決定します。ダミーゲートウェイは独自ロジックに適しています:プランが正しいロールを付与するか、注文が表示されるか、クーポンが使用済みとしてカウントされるか、ユーザーが正しいページに到着するか。サンドボックスは統合テストに適しています:認証情報、リダイレクト、カード拒否、認証チャレンジ、Webhook 配信。両方とも、異なる段階で必要になります。
Casdoor Dummy プロバイダーの仕組み
Dummy プロバイダーには設定や決済ページがありません。以下は、Casdoor master での完全なフローです:
- ユーザーが支払いを行うと、プロバイダーの
Pay呼び出しは、Casdoor の結果ページを支払い URL として返します。ベンダーで何かを作成する代わりに、価格と通貨を注文 ID に詰め込みます。 - Casdoor はステータス
Createdで支払いを保存し、ブラウザを直接結果ページにリダイレクトします。カード入力フォーム(偽物も含めて)はありません。 - 結果ページはステータスが
Createdの支払いを確認し、約1秒後にPOST /api/notify-paymentを呼び出します。 - プロバイダーの
Notify呼び出しは常にPaidと応答し、事前に詰め込んだ価格を返すため、価格チェックは通過します。 - その後、Casdoor は通常の成功パスを実行します。支払いと注文は
Paidになり、支払いに対して作成されたサブスクリプションが更新され、Purchaseトランザクションが書き込まれ、商品の在庫が減り、注文にあるクーポンが使用済みとしてマークされます。商品がチャージ商品の場合、Rechargeトランザクションによってユーザーの残高にも金額が追加されます。
つまり、Dummy は注文を即座に支払済みとし、ユーザーは中間ステップなしで成功ページを見ます。
この設計には2つの制限があります。Dummy は失敗できません:Canceled、Timeout、または Error を返す方法がないため、障害パスにはサンドボックスが必要です。また、Dummy は更新できません:Casdoor は Balance と Stripe のみを自動更新に対応させているため、Dummy で購入したサブスクリプションは常に自動更新が無効になります。
新しいデータベースでは、Casdoor は admin 組織内に provider_payment_dummy という名前の組み込み Dummy プロバイダーを、組み込み Balance プロバイダーとともに作成します。独自のプロバイダーを追加することも可能です:Identity > Providers で、Category を Payment、Type を Dummy に設定してください。
本番環境で Dummy を使用しないこと
/api/notify-payment is open to anonymous callers, because real gateways call it without a Casdoor session. For a real provider that is safe, since Notify checks the payment with the vendor. Dummy checks nothing and reports Paid, so for a Dummy payment Casdoor only accepts the call from the payment's own user or an admin of its organization. That still leaves the main risk: any product that lists Dummy in its Payment providers shows it at checkout, and any signed-in user who picks it gets the product for free. Remove Dummy from every product before you go live, and do not put it on products in an organization that real users can reach.
Balance: Dummy で資金を注入できる内部ウォレット
Balance プロバイダーを使用すると、ユーザーはアカウント残高から支払いを行えます。Casdoor は最初に残高を確認し、価格を差し引き、同じリクエスト内で支払いと注文を Paid とマークします。Balance はテストツールではなく実際の機能ですが、Dummy と組み合わせると効果的です:チャージ商品に Dummy を設定し、テストユーザーを「チャージ」すれば、お金を使わずに残高が入金されます。
これはサブスクリプションにとって重要です。なぜなら、Balance は自動更新をサポートする2つのプロバイダーの1つだからです。Dummy と Balance を併用すれば、ゲートウェイアカウントなしでノートパソコン上で更新ループ全体をテストできます。
ステージング用のベンダーサンドボックス
Stripe. Stripe はキーによってテストデータとライブデータを分離します:サンドボックスキーは pk_test_ と sk_test_ で始まり、ライブキーは pk_live_ と sk_live_ で始まります。一方のモードで作成されたオブジェクトはもう一方では見えません。Casdoor は Stripe プロバイダーに入力したキーを使用します。runmode は Stripe に対しては何も変更しません。Stripe のテストカードは Dummy ではカバーできないパスを提供します:4242 4242 4242 4242 は成功し、4000 0000 0000 0002 は拒否され、4000 0000 0000 3220 は 3-D Secure を要求します。有効期限は未来の日付、CVC は任意のものを使用してください。Stripe の利用規約により、ライブモードで実際のカード詳細を用いたテストは禁止されています。
PayPal. PayPal サンドボックスは、独自のアプリとテストアカウントを持つ別の環境です。開発者ダッシュボードに初めてログインすると、PayPal はデフォルトの個人およびビジネスのサンドボックスアカウントを作成します。支払いには個人アカウントを使用します。サンドボックスモードでアプリを作成し、その認証情報を PayPal プロバイダーに入力し、runmode を dev のままにしてください。
Paddle. サンドボックスは sandbox-vendors.paddle.com にある別アカウントであり、独自のキーと商品を持ち、ライブ環境とは何も共有しません。Paddle のテストカードには 4242 4242 4242 4242(成功)と 4000 0000 0000 0002(拒否)が含まれます。
Lemon Squeezy has a test mode per store, and API keys created in test mode only see test data. FastSpring test orders go through a test storefront: insert .test. into the store host, for example yourstore.test.onfastspring.com, and enter that as the provider's Host. Polar has a sandbox with its own tokens; set the provider's Host to https://sandbox-api.polar.sh to use it, and leave Host empty for live Polar. Alipay in Casdoor is also hard-wired to production.
Casdoor の商品、プラン、サブスクリプションのためのテスト計画
開発環境:Dummy を使用
- 商品を作成し、その Payment providers に Dummy を追加します。
- その商品のプランと、それをリストする料金ページを作成します(料金概要を参照)。
- テストユーザーとして料金ページを開き、プランを購入します。支払いと注文が
Paidになっていること、サブスクリプションがActiveになっていること、そしてユーザーにPurchaseトランザクションが表示されることを確認してください。 - ユーザーとしてサインインし、プランのロールがアプリケーションで有効になっていることを確認してください。
- プランで Is exclusive がオンになっている場合、再度購入し、ユーザーがすでにアクティブなサブスクリプションを持っているというエラーが発生することを期待してください。
- チェックアウト時にクーポンを適用し、その使用状況が記録されていることを確認してください。
- Dummy を持つチャージ商品を作成し、テストユーザーをチャージした後、Balance と Auto renew をオンにしてプランを購入します。
- 1ヶ月待たずに更新をテストするには、サブスクリプションの編集ページで End time を編集し、24時間以内に終了するようにします。Casdoor は1時間ごとにサブスクリプションをチェックします。Renewal state が
Renewedになり、次の期間の新しいサブスクリプションが作成されることを期待してください。次に、次の期間には残高が不足する状態でプランを再購入し、同様に終了時間を移動して、Failedとなり Renewal message に理由が表示されることを期待してください。正確なルールについてはサブスクリプションドキュメントを参照してください。
ステージング環境:サンドボックスを使用
runmode = devでステージング環境を実行し、サンドボックスまたはテスト用の認証情報のみを使用します。- 本番環境で使用するプロバイダー(サンドボックスキーで設定済み)に Dummy を置き換えます。
- 購入を繰り返し、ブラウザがベンダーのチェックアウトページへ遷移し、その後 Casdoor の結果ページに戻ることを確認します。
- Stripe を使用する場合、決済拒否カードで一度、3-D Secure カードで一度支払いを行い、それぞれの決済および注文ステータスを確認します。
- Stripe で Auto renew が有効な場合、Casdoor はチェックアウト時にカード情報を保存し、更新時に自動的に請求するため、上記の終了日時のテクニックはサンドボックス環境でも機能します。
本番公開
すべての製品から Dummy を削除し、PayPal、Paddle、Adyen、AirWallex を使用する場合は runmode = prod に設定して、ライブキーに切り替えます。最初の実際の注文の payment records を確認してください。
同じ環境でサインアップメールもテストする場合、ローカルメールドリャーを使うことで、これらのメッセージが実際の受信トレイに届かないようにできます。詳細は MailHog vs Mailpit を参照してください。
参考資料
- Casdoor ソース:
pp/dummy.go,pp/balance.go,object/order_pay.go,object/payment.go,object/subscription_renew.go - Casdoor ドキュメント: Payment providers, Dummy, Balance, Subscription
- Stripe: Testing, API keys
- PayPal: Sandbox, Sandbox accounts
- Paddle: Sandbox
- Lemon Squeezy: Test mode
- FastSpring: Test orders
- Polar: Sandbox
- Adyen: Live endpoints