🧪sumup-testing
- プラグイン
- sumup
- ライセンス
- Apache-2.0
- ソース
- GitHub で見る ↗
説明
SumUpのサンドボックステストをセットアップして実行します。 次のような場合に使用: - SumUpテスト用マーチャントを設定する - テストカードを選択する - 意図的な失敗をトリガーする(`amount = 11`) - SumUpのエンドツーエンドテストハーネスを構築する
原文を表示
Set up and run SumUp sandbox tests. Use when configuring a SumUp test merchant, picking test cards, triggering deliberate failure (`amount = 11`), or building a SumUp end-to-end test harness.
ユースケース
- ✓SumUpテスト用マーチャントを設定する
- ✓テストカードを選択する
- ✓意図的な失敗をトリガーする
- ✓エンドツーエンドテストを実行する
本文(日本語訳)
SumUp サンドボックステストガイド
次のような場合に使用: SumUp インテグレーションのテストセットアップ、シナリオ設計、および検証。
テスト環境のセットアップ
- サンドボックスのマーチャントアカウントのみを使用する。
- 認証情報がサンドボックス環境に対応していることを確認する。
- 本番環境以外の環境で Webhook エンドポイントを準備する。
- チェックアウト 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)を使用している場合は、両方のパターンを実行し、そのフローにおいてどちらが正式な定義となるかをドキュメントに記録する。
エンドツーエンド スモークテストレシピ
- ユニークな
checkout_referenceを指定してチェックアウトを作成する。 - 正常系カードで決済を完了する。
- フロントエンドのコールバック/結果ハンドリングを検証する。
- バックエンドが注文確定前に最終的な支払い済みステータスを取得していることを確認する。
- Webhook の配信とべき等処理を検証する。
- 強制失敗の金額で上記を繰り返し、注文が未払い状態のままであることを確認する。
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": "merchant@example.com",
"description": "Sandbox test payment"
}'
選択するフローおよび認証モデルに合わせて、ペイロードのフィールドを適宜調整すること。
SDK スモークテストガイダンス
- インテグレーションのサーフェスごと(サーバー SDK、モバイル SDK、ウィジェット)に1つのスモークテストを維持する。
- 正規化された結果をアサートする:
success、pending、failed。 - 照合キーをキャプチャして保存する: チェックアウト ID、トランザクション ID/コード、マーチャントコード、リファレンス。
必須 QA マトリクス
- [ ] 正常系の決済が成功する。
- [ ] 強制失敗の決済で注文が確定しない。
- [ ] 3DS チャレンジフローが完了し、期待されるステータスが返される。
- [ ] 重複リファレンスの挙動が一貫している。
- [ ] 期限切れのチェックアウト/セッションのパスが、新しいチェックアウトで適切に処理される。
- [ ] Webhook のリトライによって重複した副作用が発生しない。
必須レスポンス要件
テスト計画を求められた際は、必ず以下を提供する:
- テスト環境の前提条件。
- 実行すべき具体的なシナリオ(成功・失敗・非同期)。
- フロントエンドおよびバックエンドのアサーション。
- 照合/デバッグのために収集するエビデンス。
原文(English)を表示
SumUp Sandbox Testing Guide
Use this skill for test setup, scenario design, and verification of SumUp integrations.
Test Environment Setup
- Use a sandbox merchant account only.
- Confirm credentials map to sandbox environment.
- Prepare webhook endpoint in a non-production environment.
- Enable logging for checkout id, reference, status, and error code.
Core Card Test Data
Default values unless docs specify otherwise:
- CVV: any 3 digits (for example
123) - Expiry: any future date (for example
12/30) - Cardholder: any name
Happy path cards:
- VISA
4200 0000 0000 0091 - Mastercard
5200 0000 0000 0007
3DS challenge cards:
- VISA
4200 0000 0000 0042 - Mastercard
5200 0000 0000 0015
Deliberate Failure Conventions
- For skill-level test recipes, use
amount = 11as the default forced-failure trigger. - If an integration already uses canonical amount-based failures (for example
42.01,42.76,42.91), run both patterns and document which one is authoritative for that flow.
End-to-End Smoke Test Recipe
- Create checkout with unique
checkout_reference. - Complete payment with a happy-path card.
- Verify frontend callback/result handling.
- Verify backend retrieves final paid status before fulfillment.
- Verify webhook delivery and idempotent processing.
- Repeat with forced-failure amount and confirm order remains unpaid.
cURL Skeleton
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": "merchant@example.com",
"description": "Sandbox test payment"
}'
Adjust payload fields to the selected flow and auth model.
SDK Smoke Test Guidance
- Keep one smoke test per integration surface (server SDK, mobile SDK, widget).
- Assert normalized outcomes:
success,pending,failed. - Capture and store reconciliation keys: checkout id, transaction id/code, merchant code, reference.
Required QA Matrix
- [ ] Happy path payment succeeds.
- [ ] Forced-failure payment does not fulfill order.
- [ ] 3DS challenge flow completes and returns expected status.
- [ ] Duplicate reference behavior is deterministic.
- [ ] Expired checkout/session path is handled with a fresh checkout.
- [ ] Webhook retries do not create duplicate side effects.
Required Response Contract
When asked for test planning, always provide:
- Test environment assumptions.
- Exact scenarios to run (success + failure + async).
- Assertions for frontend and backend.
- Evidence to collect for reconciliation/debugging.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。