🔐sumup-best-practices
- プラグイン
- sumup
- ライセンス
- Apache-2.0
- ソース
- GitHub で見る ↗
説明
適切なSumUpの統合パスを選択し、セキュリティのベストプラクティスを適用します。 次のような場合に使用: - Hosted Checkout、Card Widget、Checkouts API、モバイルSDK、ターミナルSDK、またはCloud APIの中から選択する場合 - APIキー、OAuth、または制限付きキーのどれを使用するか選択する場合 - SumUpの統合に関するセキュリティのレビューを行う場合
原文を表示
Pick the right SumUp integration path and apply security best practices. Use when deciding between Hosted Checkout, Card Widget, Checkouts API, mobile SDKs, terminal SDKs, or Cloud API; choosing API key vs OAuth vs restricted keys; or reviewing SumUp integration security.
ユースケース
- ✓統合パスを選択する
- ✓認証方式を選択する
- ✓セキュリティレビューを行う
本文(日本語訳)
SumUp 統合の意思決定とベストプラクティス
知識やAPIは変化します。古いメモリよりも、常に最新の SumUp ドキュメント(Markdown形式)を優先してください。
- ドキュメントルート:
https://developer.sumup.com/ - LLM エントリポイント:
https://developer.sumup.com/llms.txt
次のような場合に使用: アーキテクチャおよびセキュリティに関する意思決定。実装手順のウォークスルーには使用しません。
クイック決定ツリー
決済を受け付ける必要がある?
├─ 対面(カードあり)
│ ├─ ネイティブモバイルアプリがリーダーを直接制御 -> iOS Terminal SDK / Android Reader SDK
│ ├─ POS/バックエンドが非ネイティブ環境から Solo を制御 -> Cloud API
│ └─ SumUp アプリへのレガシーハンドオフが必須 -> Payment Switch
└─ オンライン(カードなし)
├─ 最速のリダイレクトフロー・埋め込み不要 -> Hosted Checkout
├─ PCI スコープを抑えた埋め込み型決済フォーム -> Card Widget
├─ モバイルアプリのチェックアウト UX -> Swift Checkout SDK / React Native SDK
├─ カードを保存して後から請求 -> Customers + トークン化
└─ カスタムオーケストレーションが必要 -> Checkouts API + 3DS + Webhook
最初に確認すること
- リクエストを分類する:
terminal、online、またはhybrid。 - 複雑度が最も低い実行可能なパスを優先する:
- カスタムオーケストレーションより先に Hosted Checkout または Card Widget を検討。
- 非ネイティブの Solo 制御には Cloud API を優先。
- 認証モデルを選択する:
- シングルマーチャントのサーバー統合には API キー。
- 委任型またはマルチマーチャントアプリには OAuth 2.0。
- 制限付きアクセスおよびアフィリエイトの前提条件を確認する:
- 必要に応じて
paymentsスコープを有効化。 - カードありの場合、Affiliate Key とアプリ/バンドル識別子の整合性を確認。
- 必要に応じて
- 運用上の制約を確認する:
- 通貨とマーチャントの整合性
- Webhook エンドポイントの準備状況と冪等性
- レガシー互換性の要件
必須ルール(例外なし)
- API キーと OAuth シークレットは必ずサーバーサイドのみで管理する。
- 生の PAN / カード情報を直接扱わない。
- オンラインチェックアウトはサーバー間通信で作成する。
- カスタムカード処理よりも Hosted / Widget / SDK のチェックアウト UI を優先する。
- 非推奨エンドポイントは使用しない。
- 一意のトランザクション参照を使用する(
checkout_reference、foreignTransactionId等)。 - Webhook コールバックはシグナルとして扱い、フルフィルメント前に API で最終状態を検証する。
- リトライや重複配信を前提とし、バックエンドは冪等な処理を徹底する。
回答時の必須契約
ガイダンスを提供する際は、必ず以下を返答してください:
- 選択した統合パスと、その選定理由の簡潔な説明。
- クレデンシャルモデルの推奨(API キー vs OAuth)とスコープ要件。
- 選択したパスに対するセキュリティチェックリスト。
- リスク・トレードオフ、および別のパスを選ぶべき状況。
- 本番リリース前の最低限のバリデーションプラン。
実装 Skill へのハンドオフ
- エンドツーエンドの実装手順には
sumupを使用。 - SDK / API の移行には
upgrade-sumupを使用。 - 障害の診断には
sumup-debugを使用。 - サンドボックスおよび QA のセットアップには
sumup-testingを使用。
原文(English)を表示
SumUp Integration Decisions and Best Practices
Knowledge and APIs can change. Always prefer the latest SumUp docs in markdown format over stale memory.
- Docs root:
https://developer.sumup.com/ - LLM entrypoint:
https://developer.sumup.com/llms.txt
Use this skill for architecture and security decisions, not implementation walkthroughs.
Quick Decision Tree
Need to accept a payment?
├─ In-person (card-present)
│ ├─ Native mobile app controls reader directly -> iOS Terminal SDK / Android Reader SDK
│ ├─ POS/backend controls Solo from non-native environment -> Cloud API
│ └─ Legacy handoff to SumUp app is mandatory -> Payment Switch
└─ Online (card-not-present)
├─ Fastest redirect flow, no embed required -> Hosted Checkout
├─ Embedded payment form with low PCI scope -> Card Widget
├─ Mobile app checkout UX -> Swift Checkout SDK / React Native SDK
├─ Save card and charge later -> Customers + tokenization
└─ Custom orchestration needs -> Checkouts API + 3DS + webhooks
Start Here
- Classify the request:
terminal,online, orhybrid. - Choose the lowest-complexity viable path first:
- Prefer Hosted Checkout or Card Widget before custom orchestration.
- Prefer Cloud API for non-native Solo control.
- Select auth model:
- API key for single-merchant server integrations.
- OAuth 2.0 for delegated or multi-merchant apps.
- Confirm restricted access and affiliate prerequisites:
paymentsscope activation where needed.- Affiliate Key plus app/bundle identifier alignment for card-present.
- Confirm operational constraints:
- Currency/merchant alignment
- Webhook endpoint readiness and idempotency
- Legacy compatibility requirements
Non-Negotiable Rules
- Keep API keys and OAuth secrets server-side only.
- Never handle raw PAN/card details directly.
- Create online checkouts server-to-server.
- Prefer hosted/widget/SDK checkout UI over custom card handling.
- Avoid deprecated endpoints.
- Use unique transaction references (
checkout_reference,foreignTransactionId, or equivalent). - Treat webhook callbacks as signals and verify final state via API before fulfillment.
- Assume retries and duplicate deliveries; enforce idempotent backend handling.
Required Response Contract
When giving guidance, always return:
- Chosen integration path with a brief why.
- Credential model recommendation (API key vs OAuth) and scope requirements.
- Security posture checklist for the chosen path.
- Risks/trade-offs and when to pick a different path.
- Minimum validation plan before production rollout.
Hand-off to Implementation Skills
- Use
sumupfor end-to-end implementation steps. - Use
upgrade-sumupfor SDK/API migrations. - Use
sumup-debugfor failure diagnosis. - Use
sumup-testingfor sandbox and QA setup.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。