SaaS and subscription businesses running on ERPNext quickly hit the ceiling of the native Stripe payment gateway. Core ERPNext treats Stripe as a one-shot checkout button on a Payment Request: it can collect a single card payment against a Sales Invoice, but it has no concept of a Stripe Subscription object, no MRR-aware recurring sync, no card-present hardware, and no reconciliation loop beyond the immediate redirect. When a subscription renews inside Stripe, when a card fails and Stripe's Smart Retries fire, or when a customer upgrades mid-cycle with proration, none of that flows back into ERPNext. Finance teams end up exporting CSVs from the Stripe Dashboard and hand-keying journal entries, and the ERPNext Subscription doctype drifts out of sync with the real source of truth in Stripe.

Stripe Billing & Subscriptions Plus is a proper Frappe app (its own module, doctypes, hooks.py doc events, and scheduler events) that we build to your billing model and install on your bench. On the checkout side we generate Stripe Checkout Sessions and Payment Links from a whitelisted server method, attach the Stripe payment_intent / checkout_session id back onto the ERPNext Payment Entry, and reconcile the captured amount, fees and currency automatically. On the recurring side we map Stripe Price / Product objects to ERPNext items and keep a bi-directional link so that customer.subscription.created/updated/deleted and invoice.paid events keep the ERPNext Subscription and its generated Sales Invoices in lockstep — including proration, plan changes, quantity-based seats and coupon/discount handling.

Technically, the reliability core is a signature-verified webhook endpoint. We expose a whitelisted method (via the Frappe REST API layer) that verifies the Stripe-Signature header against your endpoint secret, writes each event into a Stripe Event Log doctype for idempotency and replay, and dispatches handlers through frappe.enqueue so a slow downstream never times out Stripe's delivery. hooks.py doc events keep ERPNext-initiated actions (a new Sales Invoice, a cancelled Subscription) pushing outward to Stripe, while scheduler events run dunning sweeps, retry orphaned reconciliations, and re-poll any events Stripe couldn't deliver. For retail and hybrid businesses we add card-present support: registering Stripe Terminal readers as a doctype, minting connection tokens server-side, and settling PaymentIntents captured at the reader (or through the ERPNext POS) straight into a Payment Entry. Role profiles and doctype permissions keep the API keys and event logs restricted to Billing and System Manager roles, and client scripts surface Stripe status inline on the Customer, Subscription and Sales Invoice forms.

Because this is build-to-order, nothing ships as a blind download. We start with a scoping call to confirm your billing model — plans, seats, trials, tax handling, single vs. multi-company, and which Stripe features (Billing, Terminal, Connect) are in play — then build against your ERPNext v15 or v16 bench. You get the installable app source for your version, a staging install for UAT, and a documented go-live with reconciliation verified against real Stripe test-mode events before we touch production. Typical delivery is one working week from confirmed scope.