[18.0][IMP] subscription_oca: Add automatic recurring payment

[chrisandrewmann]

Adds automatic recurring payment to subscription_oca. When enabled, a subscription charges the customer's saved payment token on each billing run, removing the manual collection step for merchant-initiated recurring payments (stored card, BACS/SEPA direct debit, etc. via a tokenizing payment provider).

Purpose

subscription_oca could only generate invoices; collecting payment was always manual. This closes that gap while guaranteeing a customer is never sent an invoice for money that has not actually been collected.

Changes

• Charge before posting. The invoice is kept in draft and is only posted and reconciled once the payment succeeds. A failed charge never posts an owed invoice and never consumes an invoice number.
• New field Automatic payment boolean on the subscription template, compatible with every invoicing mode (including Draft for silent billing).
• New Payment Token field on the subscription: suggested from the partner's most recent token, constrained to the same commercial partner, and carried over automatically from the originating eCommerce or initial portal sale order payment.
• Success: invoice posted, reconciled, and (per invoicing mode) the paid invoice emailed — never an "amount due" document.
• Asynchronous capture: transaction left pending, invoice posted later on provider webhook confirmation; billing continues normally.
• Failure: invoice stays draft, subscription flagged with Payment Exception, a to-do activity is raised (visible in list/kanban), and the next invoice date is not advanced so the period is retried after a fix.
• The cron skips flagged subscriptions and isolates each one in a savepoint so a single rejected charge can't roll back the batch. Payment Exception is a public field so external retry integrations can set/clear it.
• Add tests for the success, pending, failure, retry and silent-draft paths.
• New manifest dependency: account_payment.
• Version bumped minor: 18.0.1.0.0 → 18.0.2.0.0.
• Added updated USAGE.md - See usage guide for manual testing

Invoicing mode behaviour with automatic payment

Invoicing mode	On a successful charge
Draft	Invoice posted, no email (silent background billing)
Invoice	Invoice posted, paid invoice emailed
Invoice & send	Invoice posted, paid invoice emailed
Sale order & Invoice	Sale order confirmed, invoice posted (no email)

History

This supersedes and improves upon #1331 (an 16.0 PR by @adasatorres, which stuck open with unresolved test failures). It is a fresh 18.0 implementation that keeps the spirit — automatic token-based collection on the billing cron — while addressing its main limitations:

• auto_create_payment boolean instead of a new invoicing-mode option, so automatic payment composes with every mode
  (including Draft for silent billing) rather than being one mode.
• Charge before posting: [16.0][IMP] subscription_oca: recurrent payment #1331 posts and sends the invoice and then marks it paid (or sends it for manual payment when no token exists); here the invoice stays in draft until the charge succeeds, so a failed charge never posts an
  owed invoice, never burns an invoice number, and the customer is never sent an "amount due" document for money already taken.
• Explicit failure handling: a payment_exception flag, a to-do activity in list/kanban, an unchanged next-invoice date for retry, and a cron that skips flagged subscriptions — instead of silently falling back to manual collection.
• Robustness: per-subscription savepoint isolation in the cron, support for asynchronous (pending) capture posted on webhook confirmation, automatic token hand-off from the originating sale order.

Credit to @adasatorres for the original PR

[chrisandrewmann]

@tarteo@yvaucher@carlos-domatix@rousseldenis

Would appreciate your input in testing and hopefully getting merged this time around! I think it's a feature we've all needed for a while.

[chrisandrewmann]

@alvaro-domatix@jelenapoblet@rrebollo@pedrobaeza

Keen to get some opinions on this please? Appreciate everyone is busy but I think it's a valuable improvement that warrants being part of the base subscription_oca module to make it feature complete.

I built it for 18.0 but if it helps happy to close this PR and redo for 19.0 instead.

[pedrobaeza]

I would decouple this feature from the module, as you don't want both on your system at the same time. Even more, I'm using contract, not this one.

[chrisandrewmann]

I would decouple this feature from the module, as you don't want both on your system at the same time. Even more, I'm using contract, not this one.

Thanks @pedrobaeza
I'd disagree that "you don't want both on your system at the same time".
The changes are additive so don't affect the other use cases, they add the ability (via auto_create_payment field) to choose a new mode in the subscription template and take payment automaticallly if you choose.
I feel it's a feature needed to make the module fully capable as a self-contained, all-in-one subscription module which can be a viabile alternative to Enterprise where needs are simpler, without requiring a multitude of seperate dependencies such as contract does.

I understand contract is more mature and has wider scope, but feel that subscription_oca lacking payments is really what limits it's use in real-world scenarios, such as recurring subscriptions tied to eCommerce purchases and ongoing support contracts.
Appreciate that you and some people will find contract more suitable for your use-cases

As mentioned i'd be happy to migrate to 19.0 if that helps and if other's also are of your opinion that this improvement needs to be a separate module, then i'll consider it.

[pedrobaeza]

I mean that you may want just recurring invoicing, but not recurring payment. Anyway, as said, I'm not using this alternative recurring invoicing module.

[alvaro-domatix]

I think you could do another module (subscription_oca_autopay) and would be better as we did #1454 or #1455

[rrebollo]

From a design perspective, I would keep this feature separated. It's clear that the contract and subscription approaches continue to compete, splitting community efforts.

[chrisandrewmann]

@alvaro-domatix@rrebollo
Thanks for your comments.

I was surprised to find the module contract_payment_auto exists but has not been migrated.
It hints that few people using that really need it for automated payments.
They seem to serve similar but slightly different needs.

I'm looking for something that would allow recurring automated billing to sell a SaaS subscription product, hence why I was planning to contribute to either contract or subscription_oca, but i'm wary to spend more time if there is no real demand for this.
In the meantime, i've built a seperate module that integrates with Stripe Subscriptions, essentially making Stripe the master of recurrence. This might be the easiest option for me but was hoping that I could contribute one of them to OCA.

[jans23]

I'm interested in such recurring/automated payment module for 18.0 and Stripe would be my first choice too. I would help reviewing and testing it.