クレジットを消費せずsandboxでテストする

アプリケーション名の下の切り替えでSandboxを選び、テスト用APIキーを作成して使用します。チェックはシミュレーションされ、課金されず、結果を指定できます。

Diditのsandboxは、決済プロバイダーのテストカードに相当するものです。実際のプロバイダーを呼び出したり、実際の個人データを扱ったり、残高に触れたりすることなく、任意の検証結果をオンデマンドで再現できます。

#独立したテスト環境

Sandboxは組織で共有するテスト用アプリケーションです。データ、キー、Webhook、リストはLiveと分離され、各ページ上部の帯で環境を確認できます。

1. Sandboxへ切り替える

   アプリケーション名の下でSandboxを選びます。Liveへ戻る前に、ワークフローの公開、Liveキーまたはリンク、Webhook、支払い、保存期間のチェックリストを確認し、切り替えるかSandboxに残るかを選びます。

2. テスト用キーを作成する

   開発者 → APIキーを開き、作成時にSandboxを選びます。キーが環境を決定するため、LiveキーではSandboxセッションを作成できません。

3. ワークフローを作成またはコピーする

   Sandboxには独自のワークフローがあります。テスト用に作成するか、Liveからコピーします。

4. 通常どおりセッションを作成する

   エンドポイントもコードパスも同じです。唯一の違いは、どのキーを送るかだけです。

#sandboxが変えるもの、変えないもの

結果がピクセル内容に一切依存しないため、意図的に悪い写真を使っても、sandboxでは拒否になりません。結果を決めるのはシナリオです。

#結果を選ぶ

セッション作成時にsandbox_scenarioとしてシナリオのスラッグを渡すか、テスト担当者に選ばせることもできます。ホスト型フローのsandboxセッションでは、撮影開始前にカード内のシナリオピッカーが表示され、アップロードコンポーネントの下にサンプル書類のストリップと、常時表示される「テストデータのみ」バナーも表示されます。

シナリオは、実際に対応が必要な結果をカバーしています。

review_*シナリオは、拒否レベルの入力を用意しなくても、コンソールのレビューキュー、In Reviewのwebhook、レビュアーによる承認や再提出依頼といった、手動レビューの流れ全体を確認できるように用意されています。

#自分のコード側で両者を見分ける

すべてのwebhookにはenvironmentフィールドがあり、"sandbox"または"live"のいずれかです。キーから環境を推測しようとするのではなく、このフィールドで分岐すれば、テストセッションを実際の顧客のものと取り違えることはありません。

#sandboxでできないこと

• 実在する企業の実際の登記データは返しません。sandboxのKYBはモック化された登記レスポンスを使用します。
• 実際のSMSやメールは送信しません。電話番号確認とメールアドレス確認はモック化されているため、sandboxで実際のメッセージ配信性をプレビューすることはできません。
• 月次のプランクレジットを消費しません。これは同時に、sandboxの実行が残りのクレジットについて何も教えてくれないことも意味します。

#実際のテスト検証が必要な場合

特定の国のデータベースサービスが利用可能かの確認や、特定キャリアへのSMS配信の確認など、本来ライブ呼び出しが必要なケースもあります。その場合はsandboxではなく、ライブアプリケーションへの少額のチャージが必要です。まずサポートに連絡し、そのサービスがアカウントで実際に有効になっているかを確認してから支出するようにしてください。