# Build A Stripe Integration

Write Stripe code against what the API does today, plan the product shape, confirm...

- Repository: https://github.com/ParadevAI/Paradev (15823 stars)
- Category: Testing
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add ParadevAI/Paradev --skill build-a-stripe-integration -g -a claude-code -y`
Codex: `npx skills add ParadevAI/Paradev --skill build-a-stripe-integration -g -a codex -y`
Cursor: `npx skills add ParadevAI/Paradev --skill build-a-stripe-integration -g -a cursor -y`
Gemini CLI: `npx skills add ParadevAI/Paradev --skill build-a-stripe-integration -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add ParadevAI/Paradev`

## Description

Write Stripe code against what the API does today, plan the product shape, confirm every parameter from Stripe's own docs and schemas, and keep the agent in a sandbox. Use when adding checkout, billing, subscriptions, invoicing, or webhooks to a codebase, or when debugging Stripe integration code that compiles but behaves wrong.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Confirm the API, do not recall it

Stripe's API is large, versioned, and still moving. Model memory of it is a
snapshot of whatever was true at training time, and the failure mode is not a
compile error: it is a field that is accepted and quietly ignored. Every
parameter you write should have come from a tool call in this session.

## 1. Pick the product before the endpoint

Run `stripe_implementation_planner` with what the integration has to do. The
first decision is which Stripe product owns the flow, and it is hard to reverse:

- A one-off payment with a page Stripe hosts is Checkout.
- A one-off payment inside your own UI is either embedded Checkout or
  PaymentIntents with Elements. Pick on how much of the checkout behavior you
  want Stripe to own, not on where the form renders; staying inside your UI does
  not oblige you to build the flow yourself.
- Anything recurring is Billing, with prices and subscriptions, not a payment
  you re-run on a timer.
- Charging after the fact with terms is Invoicing.

Writing a custom recurring charge loop on top of PaymentIntents is the common
wrong turn, and it costs retries, proration, tax, and the customer portal.

## 2. Read the current docs, then cite them

`search_stripe_documentation` before you write the first line, and link what you
used. If a doc disagrees with what you expected, the doc is right. Watch for
guidance that changed: the parameter that moved, the field that is now a nested
object, the method that is superseded.

## 3. Get parameters from the schema, never from memory

`stripe_api_search` finds the method, `stripe_api_details` gives its real
parameters and types. Do this even for calls you are sure of.

The rest: https://github.com/ParadevAI/Paradev/blob/HEAD/plugins/stripe/skills/build-a-stripe-integration/SKILL.md