• Projects
  • Service
  • About
  • branding.bz
  • Podcast
  • Tips
  • FAQ
  • Recruit
  • Download
  • Contact
  • branding.bz（ブランド構築SaaS）
  • DESIGN NOW（デザインメディア）
  • X
  • LinkedIn
  • Spotify
  • Facebook

213-0011 神奈川県川崎市高津区久本3-6-7-303

© 2026 ID INC. All rights reserved

claude-skills/スキル
SKILLOfficialdevelopment

sumup-best-practices

プラグイン
sumup
ライセンス
Apache-2.0
ソース
GitHub で見る ↗
説明

SumUpとの連携（外部サービスとの繋ぎ込み）における適切な方法を選択し、セキュリティの最良実践を適用します。 次のような場合に使用: - ホストされたチェックアウト、カードウィジェット、チェックアウトAPI、モバイルSDK、ターミナルSDK、クラウド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の連携方法を選択する場合
  • 認証方式を選ぶ場合
  • セキュリティを確認・検討する場合
本文（日本語訳）

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

最初に確認すること

  1. リクエストを分類する: terminal、online、または hybrid。
  2. 複雑度が最も低い実行可能なパスを優先する:
    • カスタムオーケストレーションより先に Hosted Checkout または Card Widget を検討。
    • 非ネイティブの Solo 制御には Cloud API を優先。
  3. 認証モデルを選択する:
    • シングルマーチャントのサーバー統合には API キー。
    • 委任型またはマルチマーチャントアプリには OAuth 2.0。
  4. 制限付きアクセスおよびアフィリエイトの前提条件を確認する:
    • 必要に応じて payments スコープを有効化。
    • カードありの場合、Affiliate Key とアプリ/バンドル識別子の整合性を確認。
  5. 運用上の制約を確認する:
    • 通貨とマーチャントの整合性
    • Webhook エンドポイントの準備状況と冪等性
    • レガシー互換性の要件

必須ルール（例外なし）

  • API キーと OAuth シークレットは必ずサーバーサイドのみで管理する。
  • 生の PAN / カード情報を直接扱わない。
  • オンラインチェックアウトはサーバー間通信で作成する。
  • カスタムカード処理よりも Hosted / Widget / SDK のチェックアウト UI を優先する。
  • 非推奨エンドポイントは使用しない。
  • 一意のトランザクション参照を使用する（checkout_reference、foreignTransactionId 等）。
  • Webhook コールバックはシグナルとして扱い、フルフィルメント前に API で最終状態を検証する。
  • リトライや重複配信を前提とし、バックエンドは冪等な処理を徹底する。

回答時の必須契約

ガイダンスを提供する際は、必ず以下を返答してください:

  1. 選択した統合パスと、その選定理由の簡潔な説明。
  2. クレデンシャルモデルの推奨（API キー vs OAuth）とスコープ要件。
  3. 選択したパスに対するセキュリティチェックリスト。
  4. リスク・トレードオフ、および別のパスを選ぶべき状況。
  5. 本番リリース前の最低限のバリデーションプラン。

実装 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

  1. Classify the request: terminal, online, or hybrid.
  2. Choose the lowest-complexity viable path first:
    • Prefer Hosted Checkout or Card Widget before custom orchestration.
    • Prefer Cloud API for non-native Solo control.
  3. Select auth model:
    • API key for single-merchant server integrations.
    • OAuth 2.0 for delegated or multi-merchant apps.
  4. Confirm restricted access and affiliate prerequisites:
    • payments scope activation where needed.
    • Affiliate Key plus app/bundle identifier alignment for card-present.
  5. 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:

  1. Chosen integration path with a brief why.
  2. Credential model recommendation (API key vs OAuth) and scope requirements.
  3. Security posture checklist for the chosen path.
  4. Risks/trade-offs and when to pick a different path.
  5. Minimum validation plan before production rollout.

Hand-off to Implementation Skills

  • Use sumup for end-to-end implementation steps.
  • Use upgrade-sumup for SDK/API migrations.
  • Use sumup-debug for failure diagnosis.
  • Use sumup-testing for sandbox and QA setup.

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