This issue is about adding built-in scheduled/recurring payment support to Payment 8.x-2.x. If you would like this feature for Payment 7.x-1.x, you will have to create your own module. Payment does not make recurring payments impossible. They are just not actively supported.

One of Payment's major drawbacks compared to Commerce Payment, for instance, is that there is no built-in way to handle recurring payments.

Because the 1.x branch is in code freeze, there is not much we can do, however, we can:
- Let payment method controllers declare whether they support recurring payments.
- Add an ISO 8601 period (required for recurring) and start datetime (defaults to time()) to Payments to indicate whether they are recurring.
- Update payment method controller validation to fail if the payment is recurring and the payment method controller doesn't support it.
This solution will not break existing code.

Comments

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Exposing the period to Views might be a problem, because the only existing ISO 8601 support is part of Date, but we can't add it as a dependency. We can add optional Views integration for this field, but at the very least that needs good documentation.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

See #1063470: Recurring Payments for another interesting discussion about the technical details of recurring payments.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Instead of making payments recurring, we should create payment schedule entities that implement the same interface as payments. This interface allows things line items and currency codes to be added to the entities. By doing this, we can easily create a payment based on a payment schedule. By adding an interval and a start datetime, the system knows *when* to create and execute payments. By setting a payment method (which in turn can add extra data, such as tokens/references), the system knows how to dispatch payment execution.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Another option may be to create unified payment 'blueprints', from which payments can be created. This would help with the payment form field as well, which also follows the concept of payments being created based on predefined configuration.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Status: Active » Postponed

Postponing to 8.x-2.x.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Issue summary: View changes

.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Title: Support recurring payments » Scheduled/recurring payments
xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Version: 7.x-1.x-dev » 8.x-2.x-dev
Status: Postponed » Active
mattsmith3’s picture

mattsmith3 commented

Couldn't this be done with rules in d7?

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Possibly, but someone would have to write a few custom Rules events and actions. It's like the recurring payments module for Drupal Commerce: the fact that the base system does not provide it, does not mean it's impossible. It's all perfectly possible to do with Payment, but nobody has written the extra code to initiate recurring payments yet.

mattsmith3’s picture

mattsmith3 commented

It seems like one would have to integrate per payment api- perhaps this is a localized issue for each integration (for example- stripe offers this out of the box- but you are supposed to use CIM and ARB for authorize.net)? It also occurs to me that with a simple admin form and rules you could trigger a function in payment that "authorizes" a payment, and then all the local integrations can handle their own logic. Would you have a recommended approach?

mattsmith3’s picture

mattsmith3 commented

It looks like there is a good rules action for payment completed- which could be used with rules_schuduler. But- does payment keep track of payment info so the cards can be charged on a recurring basis? Or is this part of what needs to be done here?

mattsmith3’s picture

mattsmith3 commented
Issue summary: View changes

.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Another option may be to create unified payment 'blueprints', from which payments can be created. This would help with the payment form field as well, which also follows the concept of payments being created based on predefined configuration.

See #2138231: Add a payment configuration class.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Issue summary: View changes

For payment methods that don't support native recurring payments: ship with a trait that prepares a link at which customers can make a payment using the selected payment method. The trait can, when a recurring payment is triggered, send the customer an email with this link.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Status: Active » Closed (won't fix)

Payment 8.x-2.x will not feature recurring payments out of the box. It's been decided that any such functionality should live in its own contributed module.

ricovandevin’s picture

ricovandevin commented

For Drupal 7 there is a first version of Payment Recurring (https://www.drupal.org/project/payment_recurring). A Drupal 8 version is planned (see #2875555: Port to Drupal 8).