feat(stripe): subscriptions and recurring reconciliation

[Tarunkumar0601]

Adds native recurring billing through Stripe and reconciles each renewal back to ERPNext.

• Subscription Payment Requests go through Hosted Checkout in subscription mode
• Two billing models: Bill From Cycle One and Charge Now + Defer First Cycle
• Syncs each Subscription Plan to a Stripe Price; links the ERPNext Subscription to the Stripe subscription
• invoice.paid → finds/generates the period Sales Invoice and books a Payment Entry
• Handles invoice.payment_failed (dunning) and customer.subscription.updated/deleted (status sync)

Depends on feat/stripe-webhooks-reconciliation.

Backport Needed: V15 & V16

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[greptile-apps]

Confidence Score: 4/5

The webhook reconciliation path is now correct for the happy path, but the SI-generation inside _generate_and_find_sales_invoice calls sub_doc.process(), which commits internally in ERPNext — meaning a subsequent _create_payment_entry failure cannot roll back the generated Sales Invoice despite the comment claiming otherwise.

All 20 previously-flagged concerns appear addressed. One residual concern: sub_doc.process() is ERPNext-internal and performs its own frappe.db.commit(), so the 'no commit here' comment in _generate_and_find_sales_invoice is incorrect — a PE failure after it will leave a committed, orphaned SI with no Payment Entry until Stripe retries.

payments/payment_gateways/stripe_reconcile.py — specifically _generate_and_find_sales_invoice and the transactional guarantee it claims around sub_doc.process().

_{Reviews (27): Last reviewed commit: "feat(stripe): subscriptions and recurrin..." | Re-trigger Greptile}

[greptile-apps]

ERPNext sub_doc.process() commits internally — orphaned SI on PE failure

The comment says "No commit here: keep SI generation in the webhook's transaction so a later Payment Entry failure rolls back the SI too." ERPNext's Subscription.process() calls frappe.db.commit() internally after generating each invoice, so the SI is committed to the database before _create_payment_entry is called. If _create_payment_entry then raises (e.g., validation error), handle_event rolls back — but the SI commit is already durable. The result is a submitted SI with no Payment Entry, identical to the issue that was fixed by removing the earlier explicit frappe.db.commit(). The retry will find _find_period_sales_invoice returning the committed SI and can proceed to create the PE, so it is eventually consistent — but the claim in the comment that the SI is inside the webhook transaction is incorrect and may mislead future contributors into assuming rollback protection that does not exist.