決済ゲートウェイのテストケース：種類とチェックリスト

ペイメントゲートウェイのテスト

ペイメントゲートウェイのテスト ユーザーによるオンライン購入および取引のためのシステムにおける決済ゲートウェイのテストです。決済ゲートウェイのテストの目的は、スムーズな支払い体験を提供しながら、ユーザーと販売者間の支払いの詳細を暗号化して保護することにより、決済ゲートウェイのセキュリティ、信頼性、パフォーマンスを確保することです。

ペイメントゲートウェイシステムとは、 Eコマースアプリケーションサービス オンライン購入のクレジットカード支払いを承認するゲートウェイです。決済ゲートウェイは、クレジットカード番号、口座名義人の詳細などの機密情報を暗号化して、クレジットカードの詳細を保護します。この情報は、顧客と販売者の間で安全に受け渡され、その逆も同様です。最新の決済ゲートウェイは、デビット カード、電子銀行振込、キャッシュ カード、ポイント還元などによる支払いも安全に承認します。

決済ゲートウェイは買い物客、販売業者、銀行の間に位置しているため、そこに不具合が生じると、収益が即座に停止してしまう。

Live Payment Gateway テスト プロジェクトに無料で参加してください

ペイメントゲートウェイシステムの種類

決済ゲートウェイによって、購入者がカード情報を入力する場所が異なります。以下をご覧ください。

ホスト型ペイメントゲートウェイ

ホスト型支払いゲートウェイ システムは、支払いプロセス中に顧客を電子商取引サイトからゲートウェイ リンクに誘導します。 支払いが完了すると、顧客は電子商取引サイトに戻ります。 このような種類の支払いの場合、販売者 ID は必要ありません。ホスト型支払いゲートウェイの例としては、PayPal、Noche、WorldPay があります。

共有ペイメントゲートウェイ

共有支払いゲートウェイでは、支払い処理中に顧客は支払いページに誘導され、e コマース サイトに留まります。 支払いの詳細が入力されると、支払いプロセスが続行されます。 支払い処理中に電子商取引サイトを離れることがないため、このモードは簡単でより好ましいものであり、共有支払いゲートウェイの例としては、eWay、Stripe があります。

自己ホスト型、APIホスト型、モバイルウォレットゲートウェイは、さらに別のバリエーションである。

決済ゲートウェイのテストが重要な理由

決済ページは、顧客が商品やサービスを購入するまでの最後のステップであるため、そこに不具合があると、発生した瞬間に損失が発生します。体系的なテストを実施することで、顧客が問題に遭遇する前に発見し、このステップを保護することができます。

• 収益を保護する： 取引が失敗したり、処理が遅かったりすると、買い物客はカートを放棄してしまう。そして、放棄されたカートが戻ってくることはほとんどない。
• 信頼を築きます: カード情報の入力欄をマスキングし、通信を暗号化し、明確な確認メッセージを表示することで、購入者は自分のお金が適切に処理されていることを確信できます。
• 不正による損失を防ぎます。 CVVルールの検証、住所確認、および配送速度チェックを行うことで、商品が出荷される前に不正注文を阻止できます。
• 加盟店の法令遵守を維持する： カード決済システムでは強力な顧客認証が求められ、テストはその認証方法が機能している証拠となる。
• サポートコストを削減します。 二重請求、領収書の紛失、返金の滞りなどは、高額なチケット発行やチャージバックの原因となる。
• 欠陥を早期に発見する： サンドボックス環境で統合バグを修正するコストは、本番環境の停止後に修正するコストのほんの一部で済みます。

これらのメリットは、次に説明する適切なテストの種類を組み合わせることによって得られます。

支払いドメインのテストタイプ

ペイメントゲートウェイのテストには以下を含める必要があります

機能テスト: これは、支払いゲートウェイの基本機能をテストする行為です。 これは、注文の処理、計算、国ごとの VAT の追加など、アプリケーションが想定どおりに動作するかどうかを検証するためです。

統合: クレジット カード サービスとの統合をテストします。

パフォーマンス: 特定の日にゲートウェイを経由してアクセスするユーザーの最大数やそれらのユーザーを同時ユーザーに変換するなど、さまざまなパフォーマンス指標を特定します。

セキュリティ: ペイメント ゲートウェイに対してディープ セキュリティ パスを実行する必要があります。

追加 ローカリゼーションテスト 通貨と言語については、 互換性テスト デバイス用、および 回帰試験 プロバイダーAPIの更新ごとに。

ペイメントゲートウェイをテストする方法: 完全なチェックリスト

テストを始める前に –

• マエストロ、ビザ、マスターなどのダミークレジットカード番号の適切なテストデータを収集します。
• 決済ゲートウェイ情報を収集します。 Google ウォレット、Paypal、またはその他
• エラーコードを含む支払いゲートウェイ文書を収集する
• アプリケーションと支払いゲートウェイを介して渡されるセッションとパラメータを理解する
• クエリ文字列、変数、またはセッションを通じて渡される量に関連する情報を理解し、テストする
• ペイメントゲートウェイの言語とともに、アプリケーションの言語もチェックしてください
• 通貨形式などの支払いゲートウェイのさまざまな設定の下で、加入者データが収集されます。

ヒント： 想定されるすべての不具合を、文書化されたプロバイダーのエラーコードにマッピングすることで、漠然とした「支払いがうまくいきませんでした」という不具合を、再現可能なチケットに変換します。

決済ゲートウェイのテスト環境をセットアップする方法

信頼性の高い結果を得るには、実際のお金のやり取りを行わずに、本番環境と同様の動作をする環境を構築することが重要です。ほぼすべてのプロバイダーが、実際のAPIを模倣しながらも決済処理を行わないサンドボックスを提供しており、ほとんどの決済ゲートウェイのテストはこのサンドボックスで行うべきです。

1. サンドボックスの認証情報をリクエストしてください。 別途、販売者ID、APIキー、シークレットを取得し、ソースリポジトリとは別の場所に保存してください。
2. アプリケーションをサンドボックスのエンドポイントに接続してください。 ネットワークログから、ライブゲートウェイホストにリクエストが到達していないことを確認してください。
3. 公式テストカードを読み込んでください。 どの制度も、承認、却下、残高不足、カードの有効期限切れ、カード紛失による利用停止といった、決まった結果をもたらす数値を公表している。
4. 生産データを決してコピーしないでください。 PCIセキュリティ標準評議会 規則により、テスト環境で実際のカード所有者データを使用することは禁止されているため、すべてのレコードをマスキングしてください。
5. 3Dセキュアテストモードを有効にします。 摩擦のないフローとチャレンジフローをトリガーして、リダイレクト、タイムアウト、キャンセルのパスを実行します。
6. ウェブフック受信機を登録します。 支払い状況は非同期で通知されることが多いため、決済、返金、チャージバックの通知が注文記録を更新していることを確認してください。
7. ネットワーク障害をシミュレーションする。 プロキシ経由で応答を破棄または遅延させ、購入者が再試行した際に重複請求が発生しないことを確認します。
8. 実行ごとに状態をリセットします。 カート、セッション、および保存されたトークンをクリアして、古いセッションが不具合を隠蔽しないようにします。

サンドボックスの簡単な手順書を用意しておく URLテストカード番号と期待される応答コードなどが含まれます。これにより、新規テスターはあらゆるシナリオを即座に再現でき、監査証拠としても活用できます。

警告： テストスイートを実際の認証情報に対して使用しないでください。実際のカードで一度でも認証が行われてしまうと、金融上のインシデントであると同時に、コンプライアンス違反にもなります。

ペイメントゲートウェイのテストケースの例

以下は決済ゲートウェイを確認するための重要なテストシナリオ/ケースです。

シニア#	テストケース
1	支払いプロセス中に支払いゲートウェイの言語を変更してみてください
2	支払いが成功したら、必要なコンポーネントをすべてテストし、それが取得されたかどうかを確認します。
3	支払い中に支払いゲートウェイが応答を停止した場合に何が起こるかを確認する
4	支払いプロセス中に、セッションが終了した場合にどうなるかを確認してください
5	支払いプロセス中にバックエンドで何が起こっているかを確認する
6	支払いプロセスが失敗した場合に何が起こるかを確認する
7	データベースエントリにクレジットカードの詳細が保存されているかどうかを確認します
8	支払いプロセス中にエラーページとセキュリティページを確認してください
9	ポップアップ ブロッカーの設定を確認し、ポップアップ ブロッカーがオンまたはオフの場合に何が起こるかを確認します。
10	支払いゲートウェイとアプリケーションチェックバッファページ間
11	支払いが成功したかどうかを確認し、成功コードがアプリケーションに送信され、確認ページがユーザーに表示されます。
12	取引が即時に処理されるか、処理が銀行に委ねられるかを確認します。
13	トランザクションが成功した後、支払いゲートウェイがアプリケーションに戻ったかどうかを確認します。
14	支払い処理が成功したときのすべてのフォーマットとメッセージを確認してください
15	支払いゲートウェイからの承認受領書がない限り、商品は発送されるべきではありません
16	電子メールで処理された取引を所有者に通知します。メールの内容を暗号化します。
17	金額形式と通貨形式を確認する
18	各支払いオプションが選択可能かどうかを確認する
19	リストされている各支払いオプションが仕様に従ってそれぞれの支払いオプションを開くかどうかを確認します
20	支払いゲートウェイがデフォルトで希望のデビット/クレジット カード オプションになっているかどうかを確認します。
21	デビット カードのデフォルト オプションにカード選択ドロップダウン メニューが表示されていることを確認します。

次に決めるべきことは、これらのシナリオのうちどれが脚本化に値するかということだ。

手動テストと自動テストによる決済ゲートウェイのテスト

どちらのアプローチも支払いプログラムに含まれており、重要なのは、どのケースにどちらの方法が適しているかという点です。手作業は、新規統合や人間の判断が必要なあらゆる場面で最も効果を発揮します。自動化は、すべてのビルドで必ず実行しなければならない、安定した反復的な処理において真価を発揮します。

側面	手動テスト	自動テスト
に最適	探索的チェック初回統合、ビジュアルおよび文言のレビュー	デプロイメントごとに回帰テストスイートと動作確認を実施
速度	動作が遅い。テスト担当者1人が一度に1つのシナリオを実行する。	高速。多くのシナリオが並行して実行される。
コストプロファイル	初期設定の手間は少ないが、継続的な運用には多大な労力が必要となる。	初期設定の手間は高いが、その後の運用は容易である。
一般的な工具	ブラウザ開発者ツールとサンドボックスダッシュボード	Selenium, Appium, Postman APIチェック用
主な弱点	様々なカードタイプや負荷レベルに対応して拡張するのが難しい	レイアウトやユーザビリティの問題に気づかない

実用的な分割方法は、カードの種類ごとに成功、拒否、返金のパスを自動化し、新しいゲートウェイバージョン用に手動セッションを確保することです。ドライブロードプロファイルを個別に JMeter.

ゲートウェイ パッケージを購入する前に考慮すべきこと

• ショップを購入した場合ping カートパッケージ、互換性について調べてください
• ショップping ゲートウェイパッケージの期限が近づいています。サポートされているアプリケーションの一覧については、決済ゲートウェイプロバイダーにお問い合わせください。
• ゲートウェイはアドレス検証システム保護を提供する必要があります
• 提供されているトランザクション保護の種類を確認する
• 選択した支払いゲートウェイでどの種類のデビットカードまたはクレジットカードが受け入れられるかを確認してください
• 支払いゲートウェイによって課される取引手数料を確認する
• ゲートウェイがフォーム上で直接支払いを回収するか、別のページに誘導して購入を完了するかを確認します。

よくあるご質問