Stripe Checkout
Take payment through a Stripe-hosted checkout with prices the browser cannot alter.
What it adds
A server-initiated Stripe-hosted checkout session carrying the correct customer, trusted pricing, and a return path that resolves the same regardless of when confirmation arrives.
What your agent is told to do
5
What your agent is told to do
5-
1
Create the checkout session on the server. Take only an identifier for what is being bought from the browser, then look up the price, currency, quantity limits, and tax treatment from the app's own records.
-
2
Resolve the billing customer before creating the session: reuse the one already recorded for this workspace or account, and create a new one only when none exists. Store the identifier the moment it is known so a retry does not create a second customer.
-
3
Carry the app's own reference for the purchase into the session so the confirmation that arrives later can be matched back to a workspace, a user, and an intended outcome without guessing.
-
4
Grant nothing on the browser returning to the success page. Access is granted only when a verified server-side confirmation says the money was taken, which may arrive before, during, or long after the redirect.
-
5
Reconciling the ongoing state of customers, subscriptions, and invoices belongs to the Stripe Customer and Subscription Sync brief. This one ends at a confirmed first payment; do not build a second event handler that competes with it.
Edge cases it handles
8
Edge cases it handles
8- Anything the browser sends about price, quantity, currency, or discount must be discarded. Read those from server-held records, or a user can edit the request and buy at a price you never offered.
- A user can abandon a checkout, let it expire, complete it, or pay by a method that settles hours later. Each of those needs a defined local state, and the pending case must not look identical to a failure.
- Confirmations from the provider must be verified as genuine before anything is granted, and must be safe to receive more than once. Providers retry, so the same confirmation arriving twice must not create two purchases or two subscriptions.
- The redirect back and the server confirmation race each other. The success page must handle arriving first by showing a pending state that resolves on its own, and handle arriving second by showing the finished result, without ever telling the user something contradictory.
- The same person clicking through checkout twice, or reloading the initiation, must not end up with two customers or two charges. Make session creation idempotent against the app's own reference.
- If the provider is down or the session cannot be created, say so plainly and leave the user's cart or intent intact so they can try again, rather than sending them to a blank page.
- A user who closes the tab mid-payment and returns later must find their account in a truthful state: either paid, or not paid with a clear way to resume.
- Never place a secret credential in the page. Only values the provider designates as publishable may reach the browser.
Definition of done
9
Definition of done
9- Checkout sessions are created server-side and price, quantity, and currency come only from server-held records.
- A workspace resolves to exactly one billing customer, even across repeated or retried checkouts.
- Access is granted only after a verified server-side confirmation, never from the browser's return.
- Completed, expired, abandoned, and asynchronously settled sessions each map to a distinct, correct local state.
- Repeated confirmations for the same purchase produce no duplicate records or duplicate access.
- The success page resolves correctly whether it loads before or after the confirmation arrives.
- A provider failure at initiation shows a clear message and preserves the user's intent to retry.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Lemon Squeezy License Sync
Lemon Squeezy License Sync
Sync Lemon Squeezy orders and license keys into the app's entitlement state.
What it does
A verified event pipeline mapping Lemon Squeezy orders, subscriptions, and license keys onto local entitlements, with activation limits and revocation handled.
How it works
- 1 Verify the authenticity of every incoming provider event before it changes anything. An unverified purchase notification is a request from the internet to give away your product.
- 2 Keep an explicit server-side table mapping each purchasable variant to the entitlement it grants. Do not infer the plan from a product name, because names get edited for marketing reasons and entitlements should not move when they do.
- 3 Bind each license key to a single account on first activation and refuse to activate it against a different one afterwards, with a documented path for an operator to release a key that genuinely needs to move.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/lemon-squeezy-license-sync
Stripe Customer and Subscription Sync
Stripe Customer and Subscription Sync
Keep local billing state matching Stripe as subscriptions, invoices, and plans change.
What it does
A verified event pipeline that projects Stripe customer, subscription, and invoice state onto the app's own access records, with reconciliation for anything the pipeline missed.
How it works
- 1 Define one local projection of billing state per account: which plan, which status, which period it runs to, and whether access is currently allowed. Every entitlement check in the app reads that projection and nothing else.
- 2 Verify every incoming event as genuinely from the provider before acting on it, and record its identifier so a replay is recognised and ignored. Providers retry on any non-success response, so handlers must be safe to run repeatedly.
- 3 Store a timestamp or version with the projection and refuse to apply an event that is older than what has already been written. Events arrive out of order, and a stale cancellation overwriting a fresh renewal locks a paying customer out.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/stripe-customer-and-subscription-sync
Shopify Order Import
Shopify Order Import
Import Shopify orders into the app with money, fulfilment, and later edits accurately kept.
What it does
A resumable import of the connected store's orders, mirroring line items, discounts, taxes, and fulfilment state locally.
How it works
- 1 Separate the initial backfill from the ongoing feed. The backfill walks history in a stable order behind a resumable cursor; the feed applies live updates as they arrive.
- 2 Key every imported order on the shop identifier together with the store's own order identifier, so re-running the import updates existing rows instead of duplicating them.
- 3 Store money as an exact decimal with its currency alongside it, and keep both the shop currency and the presented currency where they differ. Do not convert to a single display currency on the way in, because the original amounts cannot be recovered afterwards.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/shopify-order-import
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.