A build-to-order Frappe app that connects ERPNext to Stripe for checkout, recurring subscription sync, card-present Terminal payments, and webhook-driven reconciliation. ECOSIRE scopes, builds, installs and supports it on your bench. Built to order by ECOSIRE for ERPNext v15, v16 — indicative price from $249.00 USD; request a quote for a scoped proposal.

A build-to-order Frappe app that connects ERPNext to Stripe for checkout, recurring subscription sync, card-present Terminal payments, and webhook-driven reconciliation. ECOSIRE scopes, builds, installs and supports it on your bench.
现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。
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.
Whitelisted server method that creates Stripe Checkout Sessions and Payment Links, storing the returned session/payment_intent id on the ERPNext Payment Entry
Signature-verified webhook receiver (validates the `Stripe-Signature` header against the endpoint secret) exposed through the Frappe REST layer
`Stripe Event Log` doctype for idempotent event storage, replay, and audit — no double-posting on Stripe's at-least-once delivery
Bi-directional Subscription sync: Stripe `Price`/`Product` objects mapped to ERPNext items, keeping the `Subscription` doctype and generated Sales Invoices aligned
`invoice.paid` / `invoice.payment_failed` / `customer.subscription.updated` handlers that reconcile renewals, proration and plan changes into ERPNext automatically
Stripe Terminal / card-present support: reader registration doctype, server-side connection-token minting, and PaymentIntent capture into Payment Entries
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 2-4 weeks from confirmed scope.
Runs recurring plans and seat-based billing in Stripe but needs MRR, renewals, proration and failed-payment recovery to land in ERPNext automatically instead of via monthly CSV reconciliation.
Owns the plan catalog, trials, coupons and dunning policy; needs Stripe subscription state and retry sequences reflected on ERPNext Customer and Subscription records without manual updates.
Responsible for the bench, upgrades and permissions; wants a clean Frappe app with proper doctypes, scheduler events, role profiles and a signature-verified, idempotent webhook rather than ad-hoc scripts.
Sells both online and in-store and needs Stripe Terminal card-present payments to settle into the same ERPNext Payment Entry and reconciliation flow as online checkout.
在 ecosire.com 上购买许可证并从您的帐户仪表板下载 Stripe Billing & Subscriptions Plus 应用程序 ZIP。
将 ZIP 解压到您的 bench 的 apps 文件夹中,或者使用解压缩的应用程序的路径运行“bench get-app”。
运行 `bench --site SITE_NAME install-app APP_NAME`,然后运行 `bench migrate` 以安装 Stripe Billing & Subscriptions Plus 并应用其架构。
打开您站点上的 ECOSIRE 许可证设置并激活您的许可证密钥。需要免费的 ecosire_connect 和 ecosire_license_client 应用程序。
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| Recurring subscription sync | Bi-directional Stripe Subscription ↔ ERPNext Subscription with proration | Possible but you design and maintain the sync logic | Often checkout-only, subscriptions partial or absent | |
| Webhook reconciliation | Signature-verified, idempotent event log, enqueued handlers | Build signature check, idempotency and retries yourself | Basic handler, idempotency/replay usually missing | |
| Card-present (Terminal/POS) | Reader doctype, server-side tokens, PaymentIntent capture | Significant extra build against Terminal SDK | Rarely offered | |
| Dunning & failed-payment retries | Scheduler-driven, Smart-Retry aware, configurable sequences | Hand-rolled scheduler and state tracking | Limited or manual | |
| Version fit (v15/v16) | Pinned and tested to your exact bench | Yours to keep current | Generic build, drift on upgrades | |
| Ownership & source | Full git repo handover, your version | You own it (and the cost of building it) | Vendor-locked, closed or licensed | |
| Delivery & support | Scoped build, UAT, training, post-go-live window | Depends on internal capacity | Download + forum/ticket support | |
| Fees & multi-currency posting | Fees to configured account, captured at Stripe FX | Implement fee/FX posting yourself | Often gross-only, no fee accounting |
This is a build-to-order app, not an instant download. After a scoping call to confirm your billing model, typical delivery is 2-4 weeks from confirmed scope, including a staging UAT before go-live. Complex multi-company or Stripe Connect setups may extend that, and we confirm the timeline in writing before we start.
We build against Frappe/ERPNext v15 and v16. Because we build to order, the app is pinned and tested against your exact bench version, so you avoid the compatibility drift common with generic marketplace apps.
Every build includes a post-go-live support window for defect fixes and reconciliation tuning. Beyond that we offer ongoing maintenance to track ERPNext version upgrades and Stripe API changes. You also receive the full git repository, so your own team can maintain it if you prefer.
Yes. A scheduler event tracks failed invoices, respects Stripe Smart Retries, and drives configurable email/notification retry sequences. Subscription state (past_due, canceled) is reflected on the ERPNext Customer and Subscription records so your team acts on real Stripe status.
The webhook receiver verifies Stripe's signature and writes every event to a `Stripe Event Log` doctype keyed for idempotency, so Stripe's at-least-once delivery never causes double-posting. Processing fees and net settlement are posted to configurable accounts, and a scheduler sweep re-polls any events Stripe could not deliver.
Yes. We support Stripe Terminal: readers are registered as a doctype, connection tokens are minted server-side, and PaymentIntents captured at the reader or through ERPNext POS settle into a Payment Entry in the same reconciliation flow as online checkout.
No. We build and test against your Stripe test-mode keys or a sandbox you control. Live keys are entered by your team into a permission-restricted settings doctype, readable only by Billing and System Manager roles, and are never committed to the repository.
A build-to-order Frappe app that connects ERPNext to Stripe for checkout, recurring subscription sync, card-present Terminal payments, and webhook-driven reconciliation. ECOSIRE scopes, builds, installs and supports it on your bench.