How to Build Subscription Billing Without Stripe or PayPal

Sometimes Stripe, PayPal, or turnkey platforms aren’t an option: data residency rules, procurement redlines, or local payment rails force you to own subscriptions end-to-end. This playbook calls out the ugly parts we see teams struggle with when they go vendorless.

What You Still Need (Even Without Stripe)

• Catalog + plans: Versioned products, add-ons, and price books so you can prove what a customer bought on a given date.
• Subscriptions: State machine for trial → active → past due → canceled; proration and mid-cycle changes that survive clock skew and partial payments.
• Invoicing: Draft + finalize flows with taxes, credits, and line-level usage (see Usage API guide).
• Payments & reconciliation: Direct gateways (Adyen, Checkout.com, local ACH/SEPA) with settlement matching and fee capture.
• Dunning + comms: Retries, expirations, 3DS challenges, and receipts that match invoice math.
• Entitlements: Real-time feature flags so plan changes show up in-product in seconds, not at the next invoice.
• Customer-facing UI: A self-serve portal where customers see plans, usage, and invoices. If you would rather not build this layer by hand, a no-code builder like AppElixir assembles the dashboard and portal on top of your billing data.

Reference Architecture (No Stripe/PayPal)

1. Identity & tenants: Customer accounts, billing contacts, and KYC/AML checks where your acquiring bank requires it.
2. Product catalog service: Versioned plans, billing intervals, add-ons, and price tiers. Keep immutable versions; apply overrides per contract. Align with how you run experiments (see catalog iteration guide).
3. Subscription service: State machine with proration rules, renewal windows, pause/resume, and grace periods. Store the active catalog version per subscription.
4. Metering (optional): If usage is involved, ingest events into a ledger (see AI enforcement guide) and attach meters to line items.
5. Invoicing engine: Draft → finalize → deliver PDFs + JSON. Support one-off invoices, deposits, prepayments, and commit drawdowns.
6. Payment gateways: Integrate directly with acquirers (Adyen, Checkout.com, Worldpay) and local rails (ACH, SEPA, Pix, UPI). Tokenize via hosted fields to keep PCI scope narrow.
7. Reconciliation: Webhooks/files from gateways update payment intents; post settlements, fees, and chargebacks to a ledger (see revenue recognition playbook).
8. Dunning + comms: Configurable retry cadences per method, 3DS fallback paths, and receipts that itemize tax and credits.
9. Entitlements service: Issue signed tokens/flags that gate features and limits; expire on cancellation or downgrade.

Data Model Essentials

• product_item (versioned), plan (with price book), subscription (state + plan version), invoice (lines, taxes, credits), payment_intent (gateway reference + status), ledger_entry (double-entry for audit).
• Keep every price change immutable; create new versions instead of overwriting. Subscriptions reference the version at start date.
• Store tax jurisdiction and currency per invoice; apply FX only once and log the rate used.

Proration & Mid-Cycle Changes

Decide per plan: immediate proration, next-cycle changes, or credit-only downgrades. Calculate remaining value = (unused days ÷ cycle days) × price; issue credits as line items, not as silent adjustments. Watch for off-by-one errors around time zones and trial extensions.

Compliance & Risk

• PCI DSS: If you collect card PANs, you must tokenize via the gateway’s hosted fields/JS and avoid touching raw card data.
• PSD2/SCA: Support 3DS for EU/UK cards; handle challenge flows and retries without duplicating charges.
• Receipts & audit: Persist every invoice and event that mutates subscription state; keep signature or hash for PDFs if needed.

Bootstrap Checklist

• Ship a versioned catalog and subscription state machine first (mirror to a portal as in customer portal guide).
• Integrate one primary gateway with hosted fields to keep PCI scope minimal; add ACH/SEPA once cards are stable.
• Implement dunning with 2-3 retry cadences, expiring-card notifications, and 3DS fallbacks.
• Expose a customer portal for invoices, payment methods, and plan changes; mirror every action via API for enterprise accounts.
• Automate reconciliation: nightly settlement ingest + ledger postings; alert on mismatches and fees.
• Add sandbox data with real edge cases (partial refunds, currency switches, paused subs) before go-live.

Field Notes From Recent Builds

• Brazil and India launches: Local rails (Pix, UPI) forced a separate payment_intent path; keep one invoice but multiple payment attempts.
• Chargeback-heavy segments: Add velocity checks and delayed fulfillment for high-risk SKUs; reconcile disputes back to the ledger, not spreadsheets.
• Contracted rates: Store overrides per subscription to avoid global price edits when sales negotiates exceptions.
• API-first buyers: Publish the same invoicing and ledger data you trust internally (see Billing API blueprint).

Owning subscriptions without Stripe/PayPal is doable if you keep pricing immutable, enforce entitlements in real time, and treat payments, reconciliation, and dunning as first-class services rather than afterthoughts.

For the event-storage side of homemade billing (raw usage events, idempotency keys, per-customer counters), a simple KV like basekv is enough.