菜单
Guides Stripe integration decisions — API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, Treasury financial accoun
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Call the externally deployed DSG QUBO Policy Optimizer API to run a deterministic QUBO/Ising policy optimization. Use when a user wants to run a real optimization against the hosted service rather than the local Kotlin engine: registering/logging in for an api_key, checking account usage, and submitting an optimization run for a regulatory domain under a budget cap. Auth is an `api_key` query parameter that must come from runtime env, never from the repo. Running a real optimization may trigger solver work and may incur cost under the service's pricing tier.
Reason about deterministic QUBO/Ising policy optimization and Z3/SMT-style formal constraint verification using the Compliance-ising-z3-Deterministic engine. Use when a user asks to optimize a policy/control selection under a budget, verify logical constraints (implication, equivalence, mutual exclusion, at-least-one, cost cap), run a what-if counterfactual on budget shifts, or produce a reproducible, hash-chained compliance decision. The underlying engine is native Kotlin (no external Z3 process); constraint checks are Z3/SMT-style, implemented deterministically.
Run a studio-style agent control layer that turns a user goal into an explainable plan, deterministic decision flow, permission verdicts, and browser-first execution after approval. Use when the user
Use this skill when creating, packaging, validating, publishing, or maintaining DSG GitHub Marketplace Actions. It turns DSG control-plane, action-layer permission gates, deterministic GO/NO-GO valida
Use this skill for DSG multi-source governance work that combines UI trust upgrades, action-layer permission gates, deterministic execution, marketplace/enterprise cutover, portable SaaS architecture
Apply the DSG ONE / ProofGate truth boundary and claim policy. Use when writing or reviewing any status, readiness, compliance, or capability statement destined for code, docs, commits, PRs, issues, comments, logs, or a response. Classifies each statement as verified fact / inference / pending / blocked / not verified, and flags forbidden readiness claims that require fresh evidence.
| name | stripe-best-practices |
| description | Guides Stripe integration decisions — API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, Treasury financial accoun |
Latest Stripe API version: 2026-05-27.dahlia. Always use the latest API version and SDK unless the user specifies otherwise.
If you do not have a Stripe account, you can call a CLI command to generate working API keys with no registration required. You can install the Stripe CLI (npm i -g @stripe/cli) and run the command stripe sandbox create to get started.
API key default: Always recommend a restricted API key (RAK) (rk_ prefix) over a secret key (sk_ prefix).
| Building… | Recommended API | Details |
|---|---|---|
| One-time payments | Checkout Sessions | <references/payments.md> |
| Custom payment form with embedded UI | Checkout Sessions + Payment Element | <references/payments.md> |
| Saving a payment method for later | Setup Intents | <references/payments.md> |
| Connect platform or marketplace | Accounts v2 (/v2/core/accounts) | <references/connect.md> |
| Usage-based billing (new integration) | Metronome | <references/billing.md> |
| Subscriptions or recurring billing | Billing APIs + Checkout Sessions | <references/billing.md> |
| Sales tax, VAT, or GST compliance | Stripe Tax + Registrations API | <references/tax.md> |
| Embedded financial accounts / banking | v2 Financial Accounts | <references/treasury.md> |
| Security (key management, RAKs, webhooks, OAuth, 2FA, Connect liability) | See security reference | <references/security.md> |
Read the relevant reference file before answering any integration question or writing code.
payment_method_types in any Stripe API call, with one exception: Terminal (in-person payments) integrations must pass payment_method_types: ['card_present'] on the PaymentIntent. For all other integrations, omit this parameter entirely to enable dynamic payment methods, which enables you to configure payment method settings from the Dashboard and dynamically display the most relevant eligible payment methods to each customer to maximize conversion. To customize which payment methods you accept, use payment_method_configurations or excluded_payment_method_types instead of payment_method_types.When the user’s request does not clearly fit a single domain above, consult: