テスト

構築済みのシステムが正しく機能することを確認するには、テスト環境またはサンドボックスで、特別な値を使用して資金を移動せずに取引をシミュレートします。

テストカードは偽のクレジットカードとして機能し、複数のシナリオのシミュレートに使用できます。

• 支払いの成否をカードブランドまたは国別にテスト
• 支払い拒否、不正利用、または無効なデータによるカードエラー
• 不審請求の申請および返金
• 3D セキュア および PIN による認証

カード以外の支払いのテストも同様に機能します。それぞれの決済手段(#non-card-payments)に応じた固有の値があります。レート制限があるため、テスト環境を使用してシステムの負荷テストを行うことはお勧めしません。代わりに、負荷テストをご覧ください。

テストカードの使用方法

テストカードを使用するときは必ず、すべての API コールでテスト用の API キーを使用します。これは、対話式でテストできる決済フォームを提供する場合にも、テストコードを作成する場合にも当てはまります。

対話式でテストする

対話式でテストする場合は、4242 4242 4242 4242 などのカード番号を使用します。ダッシュボードまたは決済フォームにカード番号を入力します。

• 有効な将来の日付を使用します (12/34 など)。
• 任意の 3 桁 (American Express カードの場合は 4 桁) のセキュリティーコードを使用します。
• その他のフォームフィールドには任意の値を使用します。

テストカード番号 4242 4242 4242 4242 を使用したフォームの対話式のテスト

テストコード

テストコードを記述するときは、カード番号の代わりに pm_card_visa などの PaymentMethod を使用してください。テスト環境であっても、API コールやサーバー側のコードでカード番号を直接使用することはお勧めしません。それらを使用すると、本番稼働時にコードが PCI 準拠にならない可能性があります。デフォルトでは、PaymentMethod は Customer に関連付けられていません。

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d amount=500 \
  -d currency=gbp \
  -d payment_method=pm_card_visa \
  -d "payment_method_types[]"=card

実装の大半では Tokens が使用されなくなっていますが、必要に応じて tok_visa などのテスト用トークンを使用できます。

導入を本番に移行する準備ができたら、テストの公開可能キーとシークレット API キーを本番用のものに置き換えます。導入でテスト用 API キーが使用されていると、本番の支払いは処理されません。

ブランド別のカード

特定のカードブランドの支払いの成功をシミュレーションするには、以下に記載されているテストカードを使用します。

大半の Cartes Bancaires および eftpos のカードは Visa または Mastercard とブランド提携しています。次の表のテストカードは、ブランド提携カードによる支払いの成功をシミュレーションします。

国別のカード

特定の国の支払いの成功をシミュレーションするには、以降のセクションに記載されているテストカードを使用します。

HSA および FSA のテストカード

以下は、Health Savings Accounts (HSA) と Flexible Spending Accounts (FSA) を使用した取引をシミュレーションするためのテストカード番号です。これらの口座は一般的に医療費の支払いに使用され、これらでテストすることで、アプリケーション内で医療関連の取引が適切に処理されるようになります。

拒否された支払い

カード発行会社がさまざまな理由で拒否する支払いをシミュレーションすることでシステムのエラー処理ロジックをテストする場合は、このセクションに記載されているテストカードを使用します。これらのカードのいずれかを使用すると、カードのエラーが発生して、特定のエラーコードと拒否コードが示されます。

不正防止

Stripe の不正防止システムである Radar により、リスクレベルが高い場合や検証チェックに失敗した場合に支払いがブロックされることがあります。このセクションに記載されているカードを使用して、Radar の設定をテストできます。また、自社で構築済みの Stripe システムが、ブロックされた支払いにどう対応するかをテストする場合にも使用できます。

各カードは特定のリスク要因をシミュレーションします。 ご使用の Radar の設定により、支払いをブロックする原因となるリスク要因が決定されます。ブロックされた支払いは、不正利用のエラーコードでカードエラーになります。

無効なデータ

無効なデータが原因のエラーをテストするには、無効な詳細を指定します。これに専用のテストカードは必要ありません。どの無効な値でも機能します。以下に例を示します。

• invalid_expiry_month: 無効な月 (13 など) を使用する。
• invalid_expiry_year: 50 年前までの過去の年 (95 など) を使用する。
• invalid_cvc: 2 桁の数字を使用する (99 など)。
• incorrect_number: Luhn チェックに失敗するカード番号を使用する (4242424242424241
  など)。

不審請求の申請

不審請求が申請された取引をシミュレーションするには、このセクションに記載されているテストカードを使用します。また、不審請求の申請に対する主張が認められる場合または認められない場合をシミュレーションするには、主張が認められる反証資料または認められない反証資料を提出します。

反証資料

不審請求の申請に対する主張が認められる場合と認められない場合をシミュレーションするには、次の表のいずれかの反証資料の値で応答します。

• API を使用して応答する場合は、表の値を uncategorized_text として渡します。
• ダッシュボードで応答する場合は、表の値を追加情報フィールドに入力してから、反証資料の提出をクリックします。

返金

本番環境では、返金は非同期で行われます。返金は、成功したように表示されてから失敗したり、最初は pending として表示され、後で成功したりする場合があります。このような動作の返金をシミュレーションするには、このセクションに記載されているテストカードを使用します。(その他のテストカードはすべて、返金が即時に成功して、その後はステータスが変わりません。)

カードの返金は、ダッシュボードでのみキャンセルできます。本番環境では、短時間内であればカードの返金をキャンセルできますが、猶予期間が特に決まっているわけではありません。テスト環境ではその期間をシミュレートするために、30 分以内であればカードの返金をキャンセルできるようになっています。

利用可能な残高

テスト取引から利用可能残高に直接、資金を送金するには、このセクションに記載されているテストカードを使用します。他のテストカードでは、成功した支払いから保留中の残高に資金が送金されます。

3D セキュア認証

3D セキュアでは、クレジットカード取引に追加の認証レイヤーが必要になります。このセクションに記載されているテストカードを使用して、各種決済フローにおける認証のトリガーをシミュレーションできます。

このセクションのカードのみが、定義された 3DS の動作 (チャレンジフローや未対応のカードなど) をシミュレーションすることによって、3D セキュアの実装を効果的にテストできます。他の Stripe テストカードでも 3DS がトリガーされる可能性がありますが、attempt_acknowledged が返され、追加のステップは迂回されます。これは、3DS テストがそれらのカード用には設計されていないためです。

認証と設定

認証を含む決済フローをシミュレーションするには、このセクションに記載されているテストカードを使用します。一部のカードは、将来の支払いに備えた設定が可能であるか、すでに設定されていることもあります。

サポートおよび対応状況

規制により義務付けられている場合や、Radar ルールまたはカスタムコードによってトリガーされた場合に、Stripe は認証をリクエストします。ただし、認証がリクエストされた場合でも、必ず実行できるとは限りません。たとえば、顧客のカードが登録されていなかったり、エラーが発生したりして実行できない場合があります。このセクションに記載されているテストカードを使用して、このような要因のさまざまな組み合わせをシミュレーションしてください。

3D セキュアのモバイルでのチャレンジフロー

モバイル決済の場合、顧客が UI プロンプトに対応するチャレンジフローをいくつか提供できます。テスト目的で特定のチャレンジフローを起動するには、このセクションに記載されているテストカードを使用します。このカードは、ブラウザーベースの決済フォームまたは API コールでの使用には適しません。こうした環境では、機能はするものの、特定の動作を起動することはありません。API コールには適さないため、テスト用の PaymentMethod と Token の値は提供していません。

CAPTCHA チャレンジ

不正利用を防止するため、Stripe は、決済ページでユーザーに CAPTCHA チャレンジを表示する場合があります。以下のテストカードを使用して、このフローをシミュレーションします。

PIN を使用した支払い

PIN が使用される対面支払いの成功をシミュレーションするには、このセクションに記載されているテストカードを使用します。その他にも、シミュレーションされたリーダーやテスト用の法人カードなど、対面支払いをテストするための多くのオプションがあります。詳細については、Stripe Terminal をテストするをご覧ください。

イベントの送信先

To test your webhook endpoint or event destination, choose one of these two options:

1. Perform actions in a sandbox that send legitimate events to your event destination. For example, to trigger the charge.succeeded event, you can use a test card that produces a successful charge.
2. Stripe CLI を使用してイベントをトリガーするか、Stripe for Visual Studio Code を使用してイベントをトリガーします。

レート制限

テスト環境でリクエストが 429 HTTP エラーを受け取り始めたら、頻度を減らします。これらのエラーは、本番環境よりもテスト環境のレート制限が厳しいために発生します。

テスト環境で、構築済みのシステムの負荷テストを Stripe API を使用して行うことはお勧めしません。テスト環境では負荷制限が厳しくなっているため、本番環境では発生しないエラーが表示される場合があります。代わりに利用できる方法については、負荷テストをご覧ください。

カード以外の支払い

テスト用のカード以外の支払い方法を使用するときは必ず、すべての API コールでテスト用の API キーを使用します。これは、対話式でテストできる決済フォームを提供する場合にも、テストコードを作成する場合にも当てはまります。

テスト手順は支払い方法ごとに異なります。

Link

Link は現在、クレジットカード、デビットカード、および資格要件を満たしたアメリカの銀行口座からの購入にのみ対応しています。Link では、ドメインの登録が必要です。

You can create sandbox accounts for Link using any valid email address. The following table shows the fixed one-time passcode values that Stripe accepts for authenticating sandbox accounts:

複数の資金供給元

対応する資金供給元を Stripe が追加した場合でも、貴社で構築済みのシステムを更新する必要はありません。Stripe が自動的に対応し、カード決済や銀行口座決済の場合と同じ売上処理時間と保証が適用されます。

リダイレクト

リダイレクトフローを使用する支払い (iDEAL など) をシミュレーションしてシステムのリダイレクト処理ロジックをテストする場合は、リダイレクトを必要とするサポート対象の支払い方法を使用します。

結果が成功または失敗になるテスト用 PaymentIntent を作成するには、以下のようにします。

1. ダッシュボードの決済手段の設定に移動し、テスト環境で有効にするをクリックして、対応している決済手段を有効にします。
2. 支払い詳細を収集します。
3. Stripe に支払いを送信します。
4. テスト支払いをオーソリするか、失敗させます。

ウェブサイト上のページ (return_url に対応するページ) で、必ず支払いのステータスが確認できるようにしてください