Stripe Customer and Subscription Sync
Keep local billing state matching Stripe as subscriptions, invoices, and plans change.
What it adds
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.
What your agent is told to do
5
What your agent is told to do
5-
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.
-
4
Build a reconciliation pass that reads current state from the provider for a given account and repairs the projection, and make it runnable for one account or for all of them. Every event pipeline eventually misses something.
-
5
First-payment checkout flow is owned by the Stripe Checkout brief. This brief owns everything after: renewals, plan changes, invoices, and access revocation. One event handler, in this brief, and the checkout brief defers to it.
Edge cases it handles
8
Edge cases it handles
8- Verified provider events are the authority over local guesses, but they do not arrive in order. Apply them by their own sequence or timestamp rather than by arrival, or a late event will undo a newer one.
- The same event will be delivered more than once. Persist processed event identifiers and make each handler produce the same result on the second run as on the first, including the ones that create invoices or send email.
- A billing customer must resolve to exactly one tenant. If an event arrives for a customer nobody owns, park it for an operator to look at rather than attaching it to a plausible-looking account.
- Trials, paused subscriptions, scheduled plan changes, cancellations that take effect at period end, and past-due delinquency are all distinct states with different access consequences. Cancelled-but-still-paid-until must keep access; past-due must not silently keep it forever.
- Drift will happen. Provide a repair or backfill path that can rebuild an account's projection from the provider's current state, and log what it changed so an operator can see what the pipeline missed.
- A handler that fails partway through must not leave the projection half-updated. Write the change atomically, and if the event cannot be processed, return a failure so the provider retries rather than swallowing it.
- When the provider is unreachable, existing access must continue on the last known projection rather than being revoked. Never treat an inability to check as evidence of non-payment.
- Downgrades and revocations affect what the user can see and do. Decide what happens to data over the new plan's limits, and tell the user before it becomes unreachable.
Definition of done
9
Definition of done
9- Every entitlement check in the app reads a single local billing projection.
- Unverified events are rejected and duplicate deliveries produce no repeated side effects.
- Out-of-order events cannot overwrite newer state.
- Trials, pauses, scheduled changes, cancellations, and delinquency each map to a defined access outcome.
- A reconciliation pass repairs an account's projection from provider state and reports what it corrected.
- Events for an unmapped customer are quarantined for review rather than guessed at.
- A provider outage preserves existing access rather than revoking it.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
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
Shopify Customer Sync
Shopify Customer Sync
Keep Shopify customers current from app users without crossing stores or resetting consent.
What it does
A sync that creates or updates a customer record in the connected store whenever an app user's details or consent change.
How it works
- 1 Find the app events that should reach the store — account creation, profile edit, address change, consent change — and sync from those events rather than sweeping every user on a timer.
- 2 Scope every request, every lookup, and every stored identifier to one connected shop. Treat the shop as part of the customer's identity, not as ambient configuration.
- 3 Store the provider's customer identifier against the app user per shop and match on it first, falling back to a normalized email address only when no identifier has been recorded yet.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/shopify-customer-sync
Paddle Subscription Checkout
Paddle Subscription Checkout
Sell subscriptions through Paddle with entitlements granted only by verified events.
What it does
A Paddle-backed subscription purchase and lifecycle flow where local access follows verified server events and prices stay under server control.
How it works
- 1 Hold the catalogue mapping on the server: which local plan corresponds to which provider offering, at which price and currency. The client passes a plan identifier and nothing about money.
- 2 Carry an account or workspace reference into the checkout so the subscription that comes back can be attached to the right tenant without matching on email address.
- 3 Grant access only from verified server-side events, and store the event identifier so a retried delivery changes nothing a second time.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/paddle-subscription-checkout
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.