PayPal Checkout
Accept PayPal payments with approval, capture, cancellation, and refund states tracked.
What it adds
A server-driven PayPal payment flow that records each stage separately and reconciles the browser's return against the app's own record of what was paid.
What your agent is told to do
5
What your agent is told to do
5-
1
Create the order on the server from trusted records. The browser may say which item is being bought and nothing about what it costs.
-
2
Model approval and capture as two distinct stages in the app's own data. A payer approving a payment is not the same as the money having moved, and collapsing them into one boolean is where this integration usually goes wrong.
-
3
Generate a stable reference for each attempt and use it on every capture request, so a retry after a timeout resolves to the original capture rather than taking the money a second time.
-
4
Verify incoming provider notifications as genuine and record their identifiers before acting, so retried deliveries update nothing twice.
-
5
If the app also carries a Stripe brief, keep one shared local record of a completed purchase and its entitlement, with each provider writing into it. Do not let two providers each maintain their own idea of whether the user has paid.
Edge cases it handles
8
Edge cases it handles
8- Prices, currency, and totals must be assembled server-side from records the user cannot edit. A total submitted by the browser is a suggestion from a stranger.
- An order can sit approved but uncaptured, or be captured for less than the full amount. Both need their own local state and their own operator-visible resolution, rather than being treated as either paid or not paid.
- Notifications from the provider must be signature-verified and deduplicated by their identifier, because they are retried until acknowledged.
- The payer's return to the app and the provider's server notification arrive independently and in either order. Resolve both against the app's own record of the attempt, and show a pending state rather than a contradiction while they disagree.
- A capture request that times out may still have succeeded. Never blindly retry the raw request; retry with the original reference or query the current state first, or you will double-charge.
- Refunds, partial refunds, and disputes change what the customer is entitled to. Decide what each does to access and reflect it in the same place the rest of the app reads.
- When the provider is unavailable, present the failure honestly and leave the order in a resumable state instead of clearing the cart.
- Currency support and payer country restrictions vary. Handle a rejection on those grounds with an explanation, not a generic error.
Definition of done
9
Definition of done
9- Orders are created server-side and no amount, currency, or quantity is accepted from the browser.
- Approved, captured, partially captured, cancelled, and refunded are distinct, visible local states.
- Provider notifications are signature-verified and processed once regardless of retries.
- The browser return and the server notification reconcile to one truthful state in either arrival order.
- A timed-out or repeated capture never results in a second charge.
- Refunds and partial refunds update entitlement through the same record the rest of the app reads.
- Provider outages leave the order resumable and the user informed.
- 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.