コンテンツにスキップ
アカウントを作成
または
サインイン
Stripe ドキュメントのロゴ
/
Ask AI
アカウントを作成
サインイン
始める
支払い
財務の自動化
プラットフォームおよびマーケットプレイス
資金管理
開発者向けのツール
始める
支払い
財務の自動化
始める
支払い
財務の自動化
プラットフォームおよびマーケットプレイス
資金管理
概要
バージョン管理
変更ログ
API バージョンのアップグレード
SDK バージョンをアップグレードする
開発者向けのツール
SDK
API
テスト
    実装内容をテストする
    ユースケースをテストする
    サンドボックス
    Apple Pay と Google Pay のレンダリングをテストする
ワークベンチ
イベントの送信先
ワークフロー
Stripe CLI
Stripe Shell
開発者ダッシュボード
エージェントツールキット
Stripe health alertsLLM を使用した構築Visual Studio Code をご利用の場合ファイルのアップロード
セキュリティ
セキュリティ
Stripe を拡張する
Stripe Apps
Stripe のコネクター
パートナー
Partner Ecosystem
パートナー認定
ホーム開発者向けのツールTesting

注

このページはまだ日本語ではご利用いただけません。より多くの言語で文書が閲覧できるように現在取り組んでいます。準備が整い次第、翻訳版を提供いたしますので、もう少しお待ちください。

テスト

支払いをシミュレーションして実装内容をテストします。

ページをコピー

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

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

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

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

テストカードの使用方法

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

よくある間違い

実際のカード詳細は使用しないでください。実際の支払い方法の情報を使用して本番環境でテストすることは、Stripe 利用規約で禁止されています。テスト API キーと以下のカード番号を使用してください。

対話式でテストする

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

  • 有効な将来の日付を使用します (12/34 など)。
  • 任意の 3 桁 (American Express カードの場合は 4 桁) のセキュリティーコードを使用します。
  • その他のフォームフィールドには任意の値を使用します。
テストカード番号の入力方法を示す支払いフォームの例。 カード番号は「4242 4242 4242 4242」、有効期限は「12/34」、セキュリティコードは「567」です。他のフィールドには、任意の値が入ります。たとえば、メールアドレスは「test@example.com」です

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

テストコード

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

Command Line
cURL
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 キーが使用されていると、本番の支払いは処理されません。

ブランド別のカード

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

注意

クロスボーダー手数料は、カード発行会社の国に基づいて計算されます。カード発行会社の国がアメリカ以外であるカード (JCB や銀聯など) は、テスト環境であってもクロスボーダー手数料がかかる場合があります。

ブランド番号セキュリティコード日付
Visa任意の 3 桁の数字任意の将来の日付
Visa (デビット)任意の 3 桁の数字任意の将来の日付
Mastercard任意の 3 桁の数字任意の将来の日付
Mastercard (2 シリーズ)任意の 3 桁の数字任意の将来の日付
Mastercard (デビット)任意の 3 桁の数字任意の将来の日付
Mastercard (プリペイド)任意の 3 桁の数字任意の将来の日付
アメリカン・エキスプレス任意の 4 桁の数字任意の将来の日付
アメリカン・エキスプレス任意の 4 桁の数字任意の将来の日付
ディスカバー任意の 3 桁の数字任意の将来の日付
ディスカバー任意の 3 桁の数字任意の将来の日付
ディスカバー (デビット)任意の 3 桁の数字任意の将来の日付
ダイナースクラブ任意の 3 桁の数字任意の将来の日付
ダイナースクラブ (14 桁のカード)任意の 3 桁の数字任意の将来の日付
BCcard と DinaCard任意の 3 桁の数字任意の将来の日付
JCB任意の 3 桁の数字任意の将来の日付
銀聯任意の 3 桁の数字任意の将来の日付
銀聯 (デビット)任意の 3 桁の数字任意の将来の日付
UnionPay (19 桁のカード)任意の 3 桁の数字任意の将来の日付

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

ブランド/提携ブランド番号セキュリティコード日付
Cartes Bancaires/Visa任意の 3 桁の数字任意の将来の日付
Cartes Bancaires/Mastercard任意の 3 桁の数字任意の将来の日付
eftpos オーストラリア/Visa任意の 3 桁の数字任意の将来の日付
eftpos オーストラリア/Mastercard任意の 3 桁の数字任意の将来の日付

国別のカード

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

国番号ブランド
アメリカ
アメリカ (US)Visa
アルゼンチン (AR)Visa
ブラジル (BR)Visa
カナダ (CA)Visa
チリ (CL)Visa
コロンビア (CO)Visa
コスタリカ (CR)Visa
エクアドル (EC)Visa
メキシコ (MX)Visa
メキシコ (MX)Carnet
パナマ (PA)Visa
パラグアイ (PY)Visa
ペルー (PE)Visa
ウルグアイ (UY)Visa
ヨーロッパ、中東

セキュリティのヒント

強力な顧客認証規制では、欧州経済領域内でのオンライン決済に対して 3D セキュア認証を要求します。このセクションのテストカードは、認証なしで成功する支払いをシミュレートします。また、3D セキュアテストカードを使用して、認証を伴うシナリオをテストすることもお勧めします。

アラブ首長国連邦 (AE)Visa
アラブ首長国連邦 (AE)Mastercard
オーストリア (AT)Visa
ベルギー (BE)Visa
ブルガリア (BG)Visa
ベラルーシ (BY)Visa
クロアチア (HR)Visa
キプロス (CY)Visa
チェコ共和国 (CZ)Visa
デンマーク (DK)Visa
エストニア (EE)Visa
フィンランド (FI)Visa
フランス (FR)Visa
ドイツ (DE)Visa
ジブラルタル (GI)Visa
ギリシャ (GR)Visa
ハンガリー (HU)Visa
アイルランド (IE)Visa
イタリア (IT)Visa
ラトビア (LV)Visa
リヒテンシュタイン (LI)Visa
リトアニア (LT)Visa
ルクセンブルク (LU)Visa
マルタ (MT)Visa
オランダ (NL)Visa
ノルウェー (NO)Visa
ポーランド (PL)Visa
ポルトガル (PT)Visa
ルーマニア (RO)Visa
サウジアラビア (SA)Visa
スロベニア (SI)Visa
スロバキア (SK)Visa
スペイン (ES)Visa
スウェーデン (SE)Visa
スイス (CH)Visa
イギリス (GB)Visa
イギリス (GB)Visa (デビット)
イギリス (GB)Mastercard
アジア太平洋

地域的な考慮事項
インド

同意書と、引き落としに関する顧客への事前通知を必要とするサブスクリプションをテストするには、インドの継続支払いをご覧ください。

オーストラリア (AU)Visa
中国 (CN)Visa
香港 (HK)Visa
インド (IN)Visa
日本 (JP)Visa
日本 (JP)JCB
マレーシア (MY)Visa
ニュージーランド (NZ)Visa
シンガポール (SG)Visa
台湾 (TW)Visa
タイ (TH)Visa (クレジット)
タイ (TH)Visa (デビット)

HSA and FSA test cards

Below are test card numbers for simulating transactions using Health Savings Accounts (HSA) and Flexible Spending Accounts (FSA). These accounts are commonly used for medical expenses, and testing with them ensures proper handling of healthcare-related transactions within your application.

Brand/Type番号セキュリティコード日付
Visa FSA任意の 3 桁の数字任意の将来の日付
Visa HSA任意の 3 桁の数字任意の将来の日付
Mastercard FSA任意の 3 桁の数字任意の将来の日付

拒否された支払い

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

よくある間違い

セキュリティコードの誤りをシミュレーションするには、任意 3 桁の数字を指定する必要があります。セキュリティコードを指定しない場合、Stripe はセキュリティコードの確認を実行しないため、確認が失敗することはありません。

説明番号エラーコード拒否コード
一般的な支払い拒否card_declinedgeneric_decline
残高不足による支払い拒否card_declinedinsufficient_funds
カードの紛失による支払い拒否card_declinedlost_card
盗難カードによる支払い拒否card_declinedstolen_card
期限切れのカードによる支払い拒否expired_card適用外
セキュリティーコードの誤りによる支払い拒否incorrect_cvc適用外
処理エラーによる支払い拒否processing_error適用外
番号の誤りによる支払い拒否incorrect_number適用外
利用頻度の上限を超過したことによる支払い拒否card_declinedcard_velocity_exceeded

上記の表のカードを Customer オブジェクトに関連付けることはできません。正常に関連付けられたカードを使用した支払いの拒否をシミュレーションするには、下記のカードを使用します。

説明番号詳細
関連付けた後の支払い拒否このカードを Customer (顧客) オブジェクトに関連付けることができますが、顧客への請求は失敗します。

不正防止

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

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

よくある間違い

セキュリティコードの確認の失敗をシミュレーションするには、任意の 3 桁の数字を使用してセキュリティコードを指定する必要があります。郵便番号チェックの失敗をシミュレーションするには、任意の有効な郵便番号を指定する必要があります。これらの値を指定しない場合、Radar は、対応するチェックを実行しないため、チェックが失敗することはありません。

説明番号詳細

常にブロック

支払いのリスクレベルは「非常に高い」です

Radar によって常にブロックされます。

非常に高いリスク

支払いのリスクレベルは「非常に高い」です

設定によっては、Radar によってブロックされる場合があります。

比較的高いリスク

支払いのリスクレベルは「比較的高い」です

Radar for Teams を使用する場合、Radar で審査リストに追加されることがあります。

セキュリティーコードの確認の失敗

セキュリティーコードを指定した場合に、セキュリティーコードの確認が失敗します。

設定によっては、Radar でブロックされる場合があります。

郵便番号チェックの失敗

郵便番号を指定した場合に、郵便番号チェックが失敗します。

設定によっては、Radar でブロックされる場合があります。

比較的高リスクの結果によるセキュリティコードチェックの失敗

セキュリティコード番号を入力した場合、セキュリティコードチェックは「比較的高い」リスクレベルの結果とともに失敗します

設定によっては、Radar でブロックされる場合があります。

比較的高リスクの結果による郵便番号チェックの失敗

郵便番号を入力した場合、郵便番号チェックは「比較的高い」リスクレベルの結果とともに失敗します

設定によっては、Radar にブロックされる場合があります。

住所 (1 行目) のチェックの失敗

住所 (1 行目) のチェックが失敗します。

支払いは、カスタムの Radar ルールによってブロックしない限り、成功します。

住所チェックの失敗

住所の郵便番号チェックと住所 (1 行目) のチェックのどちらも失敗します。

設定によっては、Radar でブロックされる場合があります。

住所を使用できない

住所の郵便番号チェックと住所 (1 行目) のチェックのどちらも使用できません。

支払いは、カスタムの Radar ルールによってブロックしない限り、成功します。

無効なデータ

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

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

不審請求の申請

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

説明番号詳細
不正使用デフォルトのアカウント設定では、支払いが成功しますが、不正利用として不審請求が申請されることになります。このタイプの不審請求の申請は、3D セキュア認証の後に保護されます。
未着デフォルトのアカウント設定では、支払いが成功しますが、商品未着として不審請求が申請されることになります。このタイプの不審請求の申請は、3D セキュア認証の後でも保護されません。
照会デフォルトのアカウント設定では、支払いが成功し、照会としてのみ不審請求が申請されます。
警告デフォルトのアカウント設定では、支払いが成功し、不正利用の早期警告のみが返されます。
複数回の不審請求の申請デフォルトのアカウント設定では、支払いが成功し、不審請求の申請が複数回行われる結果となります。
Visa Compelling Evidence 3.0 (Visa の有力な反証資料 3.0)デフォルトのアカウント設定では、支払いが成功し、Visa Compelling Evidence 3.0 の適格な不審請求の申請 としてのみ不審請求の申請が行われます。
Visa コンプライアンスデフォルトのアカウント設定では、支払いが成功し、Visa 法令遵守の不審請求の申請としてのみ不審請求の申請が行われます。

反証資料

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

  • API を使用して応答する場合は、表の値を uncategorized_text として渡します。
  • ダッシュボードで応答する場合は、表の値を追加情報フィールドに入力してから、反証資料の提出をクリックします。
反証資料説明
winning_evidence不審請求の申請がクローズされ、主張が認められたとマークされます。アカウントには支払い金額と関連手数料が入金されます。
losing_evidence不審請求の申請が終結し、主張が認められなかったとマークされます。アカウントへの入金は行われません。

返金

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

説明番号詳細
非同期の成功支払いは成功します。返金を開始する場合、ステータスは pending で始まります。しばらくすると、ステータスは succeeded に移行し、refund.updated イベントが送信されます。
非同期の失敗支払いは成功します。返金を開始する場合、ステータスは succeeded で始まります。しばらくすると、ステータスは failed に移行し、refund.failed イベントが送信されます。

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

利用可能な残高

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

説明番号詳細
保留中の残高のバイパスアメリカでの支払いは成功します。売上は利用可能残高に直接追加され、保留中の残高をバイパスします。
保留中の残高のバイパス国際決済は成功します。売上は利用可能残高に直接追加され、保留中の残高をバイパスします。

3D セキュア認証

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

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

ダッシュボードはサポート対象外

Stripe ダッシュボードで直接作成された支払いでは 3D セキュアのリダイレクトは行われません。代わりに、自社で構築されたフロントエンドまたは API コールを使用してください。

認証と設定

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

説明番号詳細
設定がない場合に認証このカードでは、将来の支払いに備えて設定していない限り、オフセッションの支払いで認証が必要です。設定した後は、オフセッションの支払いで認証は不要になります。ただし、このカードを使用したオンセッション支払いには常に認証が必要です。
常に認証このカードは、カードの設定にかかわらず、すべての取引で認証が必要です。
すでに設定このカードはあらかじめオフセッションで使用するように設定されています。1 回限りの支払いと、その他のオンセッション支払いの場合は、認証が必要です。ただし、オフセッション支払いはすべて、カードが事前に設定されている場合と同様に成功します。
残高不足このカードは 1 回限りの支払いの場合、認証が必要です。認証に成功しても、以前に設定してあっても、すべての支払いが insufficient_funds 失敗コードで拒否されます。

サポートおよび対応状況

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

注

すべての 3DS の記載は、3D セキュア 2 を指しています。

3D セキュアの使用結果番号詳細
3DS が必須OKこの支払いを正常に完了させるには、3D セキュア認証を実行する必要があります。デフォルトの場合、Radar ルールによってこのカードの 3D セキュア認証がリクエストされます。
3DS が必須拒否3D セキュア認証が必要ですが、認証後に支払いが card_declined エラーコードで拒否されます。デフォルトの場合、Radar ルールによってこのカードの 3D セキュア認証がリクエストされます。
3DS が必須エラー3D セキュア認証が必要ですが、3D セキュア検索リクエストが処理エラーで失敗します。支払いは、card_declined 失敗コードで拒否されます。デフォルトの場合、Radar ルールでこのカードの 3D セキュア認証がリクエストされます。
3DS に対応OK3D セキュア認証を実行できますが、必須ではありません。デフォルトの場合、Radar ルールでこのカードの 3D セキュア認証はリクエストされません。
3DS に対応エラー3D セキュア認証を実行できますが、必須ではありません。ただし、3D セキュアを実行しようとすると、処理エラーが発生します。デフォルトの場合、Radar ルールでこのカードの 3D セキュア認証はリクエストされません。
3DS に対応未登録このカードでは 3D セキュアがサポートされていますが、このカードは 3D セキュアに登録されていません。Radar ルールによって 3D セキュアがリクエストされても、顧客は認証するように求められません。デフォルトの場合、Radar ルールではこのカードの 3D セキュア認証がリクエストされません。
3DS に未対応このカードでは 3D セキュアがサポートされていないため、呼び出すことができません。PaymentIntent または SetupIntent は、認証を行わずに続行されます。

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

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

チャレンジフロー番号詳細
Stripe 以外すべての取引で 3D セキュア 2 認証を実行する必要があります。外部 UI を使用してチャレンジフローを起動します。
1 回限りのパスコードすべての取引で 3D セキュア 2 認証を実行する必要があります。1 回限りのパスコード UI を使用してチャレンジフローを起動します。
単一選択すべての取引で 3D セキュア 2 認証を実行する必要があります。単一選択の UI を使用してチャレンジフローを起動します。
複数選択すべての取引で 3D セキュア 2 認証を実行する必要があります。複数選択の UI を使用してチャレンジフローを起動します。

CAPTCHA チャレンジ

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

説明番号詳細
CAPTCHA チャレンジユーザーが CAPTCHA チャレンジに正しく回答すると、支払いは成功します。
CAPTCHA チャレンジユーザーが CAPTCHA チャレンジに正しく回答すると、支払いは成功します。

PIN を使用した支払い

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

説明番号詳細
オフライン PINこのカードは、カード保有者がオフライン PIN の入力を求められる支払いをシミュレートします。結果として得られる支払いでは、cardholder_verification_method が offline_pin に設定されます。
オフライン PIN の再試行SCA によってトリガーされる再試行フローをシミュレートします。カード保有者が最初の非接触型決済を失敗すると、リーダーがユーザーにカードを挿入してオフライン PIN を入力するように求めます。結果として得られる支払いでは、cardholder_verification_method が offline_pin に設定されます。
オンライン PINこのカードは、カード保有者がオンライン PIN の入力を求められる支払いをシミュレートします。結果として得られる支払いでは、cardholder_verification_method が online_pin に設定されます。
オンライン PIN の再試行SCA によってトリガーされる再試行フローをシミュレートします。カード保有者が最初の非接触型決済を失敗すると、リーダーがユーザーにカードを挿入してオンライン PIN を入力するように求めます。結果として得られる支払いでは、cardholder_verification_method が online_pin に設定されます。

イベントの送信先

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 を使用してイベントをトリガーします。

レート制限

If your requests in your testing environments begin to receive 429 HTTP errors, make them less frequently. These errors come from our rate limiter, which is more strict in testing environments than in live mode.

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

カード以外の支払い

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

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

Financial Connections を使用して即時確認を行うシナリオをテストする方法をご紹介します。

Send transaction emails in a sandbox

After you collect the bank account details and accept a mandate, send the mandate confirmation and microdeposit verification emails in a sandbox. To do this, provide an email in the payment_method_data.billing_details[email] field in the form of {any-prefix}+test_email@{any_domain} when you collect the payment method details.

よくある間違い

You need to activate your Stripe account before you can trigger these emails while testing.

テスト用口座番号

Stripe では、手動入力の銀行口座の組み込みが本番環境に移行する準備が整ったかどうかを確認するため、テスト用の口座番号と対応するトークンをいくつか用意しています。

口座番号トークン金融番号動作
000123456789pm_usBankAccount_success110000000支払いは成功します。
000111111113pm_usBankAccount_accountClosed110000000口座が解約済みであるため、支払いは失敗します。
000111111116pm_usBankAccount_noAccount110000000口座が見つからないため、支払いは失敗します。
000222222227pm_usBankAccount_insufficientFunds110000000残高不足のため、支払いは失敗します。
000333333335pm_usBankAccount_debitNotAuthorized110000000引き落としがオーソリされていないため、支払いは失敗します。
000444444440pm_usBankAccount_invalidCurrency110000000通貨が無効であるため、支払いは失敗します。
000666666661pm_usBankAccount_failMicrodeposits110000000支払いで少額入金の送金が失敗します。
000555555559pm_usBankAccount_dispute110000000支払いによって不審請求の申請が開始されています。
000000000009pm_usBankAccount_processing110000000支払いは無期限に処理中のままになります。これは PaymentIntent のキャンセルをテストするのに便利です。
000777777771pm_usBankAccount_weeklyLimitExceeded110000000The payment fails due to payment amount causing the account to exceed its weekly payment volume limit.

テスト取引を完了する前に、自動的に支払いに成功または失敗するテスト用のすべての口座を確認する必要があります。確認するには、下記の少額入金のテスト用の金額または明細書表記コードを使用します。

少額入金の金額と明細書表記コードをテストする

さまざまなシナリオを再現するために、これらの少額入金の金額「または」明細書表記コードの値 0.01 を使用します。

少額入金の金額明細書表記コードの値 0.01シナリオ
32 および 45SM11AAアカウントの確認をシミュレーションします。
10 および 11SM33CC許容された確認回数の超過をシミュレーションします。
40 および 41SM44DD少額入金のタイムアウトをシミュレーションします。

Test settlement behavior

Test transactions settle instantly and are added to your available test balance. This behavior differs from livemode, where transactions can take multiple days to settle in your available balance.

Link

注意

Don’t store real user data in sandbox Link accounts. Treat them as if they’re publicly available, because these test accounts are associated with your publishable key.

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:

値結果
以下に記載されていない任意の 6 桁の数字成功
000001エラー: コードが無効です
000002エラー: コードの有効期限が切れています
000003エラー: 最大試行回数を超えました

複数の資金供給元

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

リダイレクト

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

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

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

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

参照情報

  • Connect の導入をテストする
  • Billing の導入をテストする
  • Terminal の導入をテストする
  • 負荷テスト
このページはお役に立ちましたか。
はいいいえ
お困りのことがございましたら 、サポートにお問い合わせください。
早期アクセスプログラムにご参加ください。
変更ログをご覧ください。
ご不明な点がございましたら、お問い合わせください。
LLM ですか?llms.txt を読んでください。
Powered by Markdoc
関連ガイド
ユースケースをテストする
API キー