claude-skills/

Anthropic公式スキル・プラグインの日本語ディレクトリ

last sync 22h ago
スキルOfficialdevelopment

🧪sumup-testing

プラグイン
sumup
ライセンス
Apache-2.0

説明

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 インテグレーションのテストセットアップ、シナリオ設計、および検証。


テスト環境のセットアップ

  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.0142.7642.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": "merchant@example.com",
    "description": "Sandbox test payment"
  }'

選択するフローおよび認証モデルに合わせて、ペイロードのフィールドを適宜調整すること。


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

  • インテグレーションのサーフェスごと(サーバー SDK、モバイル SDK、ウィジェット)に1つのスモークテストを維持する。
  • 正規化された結果をアサートする: successpendingfailed
  • 照合キーをキャプチャして保存する: チェックアウト ID、トランザクション ID/コード、マーチャントコード、リファレンス。

必須 QA マトリクス

  • [ ] 正常系の決済が成功する。
  • [ ] 強制失敗の決済で注文が確定しない。
  • [ ] 3DS チャレンジフローが完了し、期待されるステータスが返される。
  • [ ] 重複リファレンスの挙動が一貫している。
  • [ ] 期限切れのチェックアウト/セッションのパスが、新しいチェックアウトで適切に処理される。
  • [ ] Webhook のリトライによって重複した副作用が発生しない。

必須レスポンス要件

テスト計画を求められた際は、必ず以下を提供する:

  1. テスト環境の前提条件。
  2. 実行すべき具体的なシナリオ(成功・失敗・非同期)。
  3. フロントエンドおよびバックエンドのアサーション。
  4. 照合/デバッグのために収集するエビデンス。
原文(English)を表示

SumUp Sandbox Testing Guide

Use this skill for test setup, scenario design, and verification of SumUp integrations.

Test Environment Setup

  1. Use a sandbox merchant account only.
  2. Confirm credentials map to sandbox environment.
  3. Prepare webhook endpoint in a non-production environment.
  4. 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 = 11 as 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

  1. Create checkout with unique checkout_reference.
  2. Complete payment with a happy-path card.
  3. Verify frontend callback/result handling.
  4. Verify backend retrieves final paid status before fulfillment.
  5. Verify webhook delivery and idempotent processing.
  6. 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:

  1. Test environment assumptions.
  2. Exact scenarios to run (success + failure + async).
  3. Assertions for frontend and backend.
  4. Evidence to collect for reconciliation/debugging.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。