mcpField
S
sumup-testing

sumup-testing

github.com/sumupテスト・品質558 回インストール3 週間前に更新
リポジトリ

sumup-testing について

sumup-testingは、SumUp連携に取り組む開発者やQAチーム向けのテストスキルです。サンドボックスの準備、決済シナリオ、エンドツーエンドの確認手順をまとめています。

主な機能

  1. 01サンドボックス環境の準備
  2. 02成功・失敗決済のテスト
  3. 033DSチャレンジフローの検証
  4. 04Webhookと冪等性の確認
  5. 05SDKスモークテストのガイド

活用シーン

  1. 01SumUp決済テストの計画
  2. 02決済と注文処理ロジックの検証
  3. 03Webhook再試行による副作用の調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sumup/sumup-skills --skill sumup-testing

インストール後、Claude Code で/sumup-testingを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlassets/small-logo.svg

詳細

SumUp サンドボックステストガイド

SumUp の連携に関するテスト環境の設定、シナリオの設計、検証には、このスキルを使用してください。

テスト環境の設定

  1. サンドボックスの加盟店アカウントのみを使用します。
  2. 認証情報がサンドボックス環境に紐付いていることを確認します。
  3. 本番環境以外に Webhook エンドポイントを準備します。
  4. チェックアウト ID、参照情報、ステータス、エラーコードのログ記録を有効にします。

基本的なカードテストデータ

ドキュメントで別途指定されていない限り、デフォルト値を使用します。

  • CVV:任意の 3 桁(例:123)
  • 有効期限:未来の任意の日付(例:12/30)
  • カード名義人:任意の名前

正常系のカード:

  • VISA 4200 0000 0000 0091
  • Mastercard 5200 0000 0000 0007

3DS チャレンジ用カード:

  • VISA 4200 0000 0000 0042
  • Mastercard 5200 0000 0000 0015

意図的な失敗の規約

  • スキルレベルのテスト手順では、強制的に失敗させるデフォルトのトリガーとして amount = 11 を使用します。
  • 連携ですでに標準的な金額ベースの失敗(例:42.01、42.76、42.91)を使用している場合は、両方のパターンを実行し、そのフローでどちらを正式な方法とするかを記録します。

エンドツーエンドのスモークテスト手順

  1. 一意の checkout_reference を指定してチェックアウトを作成します。
  2. 正常系のカードで支払いを完了します。
  3. フロントエンドでのコールバックと結果処理を検証します。
  4. フルフィルメントの前に、バックエンドが最終的な支払い済みステータスを取得することを検証します。
  5. Webhook の配信と冪等な処理を検証します。
  6. 強制失敗用の金額で再度実行し、注文が未払いのままであることを確認します。

cURL のひな形

curl -X POST "https://api.sumup.com/v0.1/checkouts" \
  -H "Authorization: Bearer $SUMUP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "checkout_reference": "order-12345",
    "amount": 11,
    "currency": "EUR",
    "pay_to_email": "[email protected]",
    "description": "Sandbox test payment"
  }'

選択したフローと認証モデルに合わせて、ペイロードのフィールドを調整してください。

SDK スモークテストのガイダンス

  • 連携対象ごと(サーバー SDK、モバイル SDK、ウィジェット)にスモークテストを 1 つ用意します。
  • 正規化された結果(success、pending、failed)を検証します。
  • 照合キー(チェックアウト ID、トランザクション ID/コード、加盟店コード、参照情報)を収集して保存します。

必須の QA マトリックス

  • 正常系の支払いが成功する。
  • 強制失敗の支払いでは注文がフルフィルメントされない。
  • 3DS チャレンジフローが完了し、期待するステータスが返される。
  • 参照情報が重複した場合の動作が一貫している。
  • 期限切れのチェックアウト/セッションが、新しいチェックアウトを使って適切に処理される。
  • Webhook の再試行によって副作用が重複して発生しない。

必須の応答要件

テスト計画を求められた場合は、必ず以下を提示してください。

  1. テスト環境の前提条件。
  2. 実行する具体的なシナリオ(成功、失敗、非同期)。
  3. フロントエンドとバックエンドでの検証項目。
  4. 照合/デバッグのために収集する証跡。

コメント