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.