domains / families / software-engineering / stripe-integration

stripe-integration

combined

Implement Stripe payment processing for robust, PCI-compliant payment flows including checkout, subscriptions, and webhooks. Use when integrating Stripe payments, building subscription systems, or implementing secure checkout flows. Implement and verify Stripe checkout, subscriptions, webhooks and refunds with explicit server-side authorization and retry boundaries.

When to use

• Implementing payment processing in web/mobile applications
• Setting up subscription billing systems
• Handling one-time payments and recurring charges
• Processing refunds and disputes
• Managing customer payment methods
• Implementing SCA (Strong Customer Authentication) for European payments
• Building marketplace payment flows with Stripe Connect

When not to use

• The task is unrelated to stripe integration
• You need a different domain or tool outside this scope
• API versions, event payloads and SDK exception namespaces differ; verify the installed version rather than combining examples from different releases.
• Request idempotency keys must stay bound to the same logical operation and parameters; a new key on every retry can duplicate a charge or refund.
• Webhook deduplication alone does not prevent duplicate business effects from different events.
• Client success, test-card success and a signature check do not establish full fulfillment, tax, compliance or subscription correctness.
• Customer, payment-method, dispute and refund mutations require server-side ownership/role checks and explicit task authorization.

Skill page

Conflict

The two copies share the same core structure (payment flows, webhooks, subscriptions, customer management, and Python/JS snippets), but the second copy adds material safety and operational constraints that the first lacks: an explicit 'Inputs and safety boundary' section, server-side authorization requirements, idempotency keys in the code patterns, environment-variable key loading, and a note to inspect the installed SDK/API version. The first copy is a cleaner, more complete procedural guide with more patterns, but it omits these security and idempotency steps. Crowning one would hide the other's real alternative approach to safe integration.