Recurring billing

[mario]

Hey guys,
recurring billing is quite important, how come you are not interested in supporting that?

[heathdutton]

I suppose it's simply because the different gateways handle it (or don't) in very different ways. Tokenized payments needs to come first it seems, since it opens up the capability of manual recurring billing, among other uses.

[mario]

Right, well at least tokenized payments and then some glue would be big help, so many people don't have to reinvent the same thing.

[heathdutton]

I'm watching this space specifically because CI-Merchant doesn't support tokenization, and Omnipay hopes to.
+1 for tokens!

[amacneil]

Correct, token billing is the priority right now (since you can build your own recurring billing quite easily with it). Token billing is already supported by one gateway (payment express) so you can check out how it will look already.

Actual recurring billing profiles are only supported by a few of the newer gateways. I've never worked with the APIs so really not sure how much difference there is between their APIs and whether it would even be possible to abstract them, but for now if you want it you should probably use a library targeted to your specific gateway.

I already have enough on my hands implementing basic payments for all the gateways (which is a much higher priority), but if someone wants to look at recurring payments in as many gateways as possible, design a nice consistent API, write all the code, and submit a pull request, I'd be more than happy to take a look at supporting it :)

[heathdutton]

I will have a look at payment express. Thanks!

[makasim]

but for now if you want it you should probably use a library targeted to your specific gateway.

I've just added support of recurring payments to payum lib. It works for paypal express checkout.

Here's the doc and sandbox symfony 2 example.

Hope you find it useful.

[superasn]

@kayladnls on the main page it says:

Feel free to get in touch if you really think this should be a core feature and worth the effort.

I sincerely feel that this should be supported where possible, like 2Checkout, Paypal, etc.

Almost all SaaS companies I know off require recurring billing.

I was so excited to see this library and I'm sure recurring billing support will only make it 10x useful.

I propose that there should be a way to query the gateway like:

 if ( $gateway->supportsRecurringBilling() ) {
      ...

If you guys are considering it, I'd be more than happy to add code to Paypal and 2Checkout to support recurring billing (as I've implemented them quite a lot for many of my sites).

It would be great if we can decide the API for supporting recurring billing first.

Your thoughts?

[amacneil]

Since I wrote the original readme figure I should add a comment.

The reason we didn't originally support recurring billing isn't that it's not useful, but more because it is hard to abstract the differences between many gateways. I've seen different recurring billing APIs treat things like plans, timeframes, subscriptions, customers, very differently. I think it would be hard to come up with a consistent cross-gateway API for this (especially compared to single credit card charges, which are fairly straightforward).

Of course, it could still be added as a non-standard option in specific gateways (e.g. paypal). That might even be a better place to start, and after implementing a few gateways if we can see some common trends emerge, then that could be added as a common interface.

[superasn]

@adrianmacneil that is probably a good idea.. One of my site already have an abstraction layer over PP, 2CO and CCNow (including handling the IPN) and it seems to work just fine..

AFAIK there were a minor issues like 2CO not returning a unique IDs for each transaction within subscription but that ways many years ago.. maybe a fork would be a good way to start?

[Ezyweb-uk]

+1 for subscriptions/recurring billing for Stripe and Paypal.