Recurly

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Think carefully before building subscription billing. **The arithmetic is where this goes wrong, and it goes wrong in money.**

The specific traps, so you can judge honestly:
- Proration on an upgrade mid-cycle, then a downgrade, then a refund. Getting this consistent is harder than it sounds and every error is a customer complaint or an overcharge
- Failed payment recovery: a card fails, and when and how you retry decides whether you keep the customer. Getting this wrong quietly loses revenue that never appears as a number
- Tax: VAT in the EU depends on where the customer is and whether they are a business, and sales tax in the US depends on thresholds per state. **This is a compliance obligation, not a feature**
- Revenue recognition: what you invoice and what you have earned are different, and your accountant needs the second

**The honest recommendation: use your payment processor's own billing.** Stripe Billing, or the equivalent, handles proration, dunning and tax and costs a percentage rather than a platform fee. This entry is a 'no' because a billing platform on top of a processor is usually paying twice for the same arithmetic.

If you do build the layer, here is what it must hold.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A payment processor for everything involving a card
- Caddy in front

THE DATA MODEL
- plans, prices with an effective date, subscriptions, and subscription_items
- ledger: id, subscription_id, kind, amount_cents, currency, occurred_at, description, ref — **append-only, and every invoice is derived from it.** Never store a balance
- invoices, invoice_lines, payments, credit_notes
- dunning_attempts: id, invoice_id, attempt, at, outcome
- Money in integer minor units, one currency per subscription, never a float anywhere

THE RULES
- **Proration computed in days and stated on the invoice line.** A customer must be able to reconstruct the number themselves, or you will spend your life explaining it
- A plan change is a credit for the unused period and a charge for the new one, both as ledger entries. Never an adjusted single figure
- Webhooks from the processor are the truth about payment, verified by signature, processed idempotently. **A subscription activated by a client-side callback rather than a verified webhook is a subscription anybody can activate for free**
- Dunning: retry on a schedule that respects the card network rules, with an email that says what to do, and a stated end. Record every attempt
- Never delete or edit an invoice. Issue a credit note

WHAT MATTERS MOST
Use the processor's billing. If you must build, make the ledger append-only and derive everything from it — that is the only structure that stays reconcilable when the edge cases arrive.