Step 1 of 7
Define the payment spec
Lock what is being sold, prices, and payment states before touching Stripe.
Define the payment spec for this app. Specify: what is being sold (one-time purchase or subscription plans with exact prices and currency), the payment states we must track (pending, paid, failed, canceled), what a user gets when paid, and where payment records are stored. State explicitly that all amounts live on the server and that payment success is only confirmed server-side. Do not implement yet.
Expected after this step
A concrete payment spec with products, prices, states, and storage.
Should not happen
- ✕A 'Pay' button that redirects to a success page without ever calling Stripe
- ✕Payment status set from the client success redirect instead of server verification
- ✕Secret key exposed in frontend code
- ✕No handling of canceled or failed payments
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !A 'Pay' button that redirects to a success page without ever calling Stripe
- !Payment status set from the client success redirect instead of server verification
- !Secret key exposed in frontend code
- !No handling of canceled or failed payments
- !Amounts defined on the client where users can edit them
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The payment spec is vague. Rewrite it with exact products, prices, currency, payment states, and the rule that only the server confirms payment success.