Recurring payments in thirty bees

[lesley]

We are starting to discus the recurring payment system that we will implement in future versions of thirty bees, as merchants we would love to know what your suggestions are. We have a blog post detailing some of the thoughts so far here, https://thirtybees.com/blog/recurring-payments-in-thirty-bees/

[Havouza]

So I will be the first

For us we need a system where the customer can subscribe to a service and be charged for it every month without human interference. Like a Paypal subsription. The customer must be able to in a simple way cancel the subscription if he want to

[Traumflug]

I think the task isn't too complicated. Orders go the normals way. Distinction from a non-recurring order is that shop software schedules another order regularly, without human interaction. Weekly, two-weekly, monthly, ...

This automatically scheduled order orders a prepared product. This can be an empty product, just collecting money, or a non-empty product like a license renewal, weekly pizza delivery, such stuff. Task for the merchant is then to set up the initial product, mark this as being something recurring, create and link a follow-up product. This follow-up-product is hidden for shop visitors, of course.

So far this doesn't touch payment modules at all. Customers get a weekly/monthly/yearly notification about their follow-up-product order and pay the usual way.

Merchants likely want to bill their customers without customer interaction in some cases. As far as I can see, this can be done with payment processors supporting this, only. Task for thirty bees would be to define an appropriate API for payment modules. After such an order is done, shop software's business is to accept payment notifications and compare them with ongoing schedules.

[Havouza]

I can see the good in involving the tb in this. At the same time it is still a longer and more complicated way, when there is payment providers that set this up and then just chanrge the customer account and send the money to the merchant. Simple and clean but ofc limit the number of payment gateways. Another Question is how the customer see it. Do they trust he shop to stop the billing when the customer want? Or do they have more trust in Paypal where they easy stop it without involve the shop

[dynambee]

A few random ideas:

1. An option to support automatic partial refunds. Some companies refund a prorated amount of the last subscription payment if a user cancels during the month. Other companies of course do not do this so it should probably be off by default so only those who want it can turn it on.

2. Cusomizable cutoff dates for cancellations. Some businesses need a bit of lead time to prepare for whatever their customers are subscribing to. If a given business needs 5 days of lead time then the last allowed cancellation date would be 5 days before the next bill.

3. Likewise customizable cutoff dates for new subscriptions. If it's a once-a-month service that needs lead time then any new subscriptions that sign up fewer than X days before the closest billing date are automatically sent to the following billing date. (Also, see groups below.)

4. The ability to assign customers to groups with each group having it's own billing & shipping dates. Some box subscription services send their boxes out in batches. Customers in Group 1 get boxes sent on the 5th of the month. Group 2 on the 10th, Group 3 on the 15th, etc. Maybe every 10 days, maybe every day or every 3 days. It should be possible to assign customers to groups both automatically and manually. Ideally the system should assign new customers to a group close to their signup date (allowing for the lead times mentioned in #3...) but then if things get too far unbalanced then an admin should be able to move customers from one group to another to maintain some sort of balance. No point in having groups if 75% of all customers are in one group.

5. An extension to the above, but if a customer is moved from Group 1 (earlier shipment date) to Group 3 (later shipment date) then the system must make sure that the customer isn't sent 2 boxes in one month. Likewise if a customer is moved from Group 3 to Group 1 the system must make sure that the customer doesn't get skipped for that month. Probably the best way to accomplish this is to make it so that group changes take effect from the following month onward.

6. Ability to choose how many days before a group's shipping date that the group is billed. This gives some lead time and also gives customers some time to update their payment details if a payment is declined.

And a question:

How are payments going to be processed? We can't store payment details or PayPal authorization details so I assume this system would have to integrate with PayPal's and/or Stripe's subscription systems. That way all the PITA storage of payment details is managed by someone else. I suppose this could complicate the idea of moving customers from one group to another as mentioned in #4 & 5 above. Is it possible to change a subscription billing date without customer authorization?

[Havouza]

This last question will not be easy, because f.ex Stripe has very limited cover in Europe. And as you say, I dont want to have the worrie with having customers payment data stored. Will never happen

[Guest]

This would be a very good feature for TB as it's a feature that other platforms have though Magento tends to have this provided as expensive extensions; this would be a draw to people away from them platforms if it was part of the core as it's a growing trend in 2017.

This has to be done in conjunction with the payment providers due to the issues with PCI DSS compliance and storing customer card data. Many of the large payment providers allow for integration whereby they store the customer data in secure tokens on their PCI compliant servers. Both WorldPay and SagePay provide this service and they cover the UK though I don't know about the rest of Europe.

You might want to take a look at AheadWorks Magento extension for this to get some ideas of how they do it.

[lesley]

@Traumflug and @Havouza The main reason a lot of the payment processors do have api's that allow for recurring billing, but I think using just them is a bad idea. If you do that you run into issues of having orders created and paid for that could have products that are no longer available. Having the logic in the shops gives us the chance to have contingencies in place where the order can be delayed, or cancelled altogether.

Also having a "hidden" product is not a perfect idea either. Say I have a shop that sells dog products and I have a subscribe and save option like Amazon has. I need to be able to pull a monthly stock status and see how many bags of xxx food are going to be autoshipped. Things like that will be very useful to merchants, especially the ones that sell physical goods.

@dynambee I agree with everything you said, we need to make this system robust to be able to handle all of those situations because they are real life use cases, I subscribe to several box sites and I have seen some of those cases before.

[Havouza]

I just see it in my own perspective. We sell virtual products/services and will never run out of products A question. Still there need to be a payment processor in the background. Some that the merchant has to have contract with. There are hundreds of different ones out there. How will that be solved?

[lesley]

@Havouza What I see is having the recurring system have hooks that are called. That way we can only worry about a couple of payment gateways internally like auth.net, stripe, and maybe a couple of others. But by having hooks other developers that develop payment gateways can develop their gateways to hook to that hook. When that hook is ran it will do the charge.

[Havouza]

So what you say is that the merchant must have a contract with one of these gateways?

[roband7]

@Havouza Absolutely, see the reply from @DavidP above

[lesley]

Correct. We want to make this in such a way that as more gateways start supporting tokenized charges that more modules can be made. But at the same time, I know there are going to be companies that use this system for other uses that won't need actual payment, they will need to generate invoices only. That is why we need to have it where it has hooks to interface with modules. So the payment modules have flexibility on what to do.

[Havouza]

I just try to see it a little from the buyers perspective. Do they really trust an internal shop solution that get the right to charge their credit card without my authorization every time. With all the card fraud goingf around I would be very vary.

[lesley]

Some people will, some people wont. We need to have both built in.

[dynambee]

@Havouza said in Recurring payments in thirty bees:

I just try to see it a little from the buyers perspective. Do they really trust an internal shop solution that get the right to charge their credit card without my authorization every time. With all the card fraud goingf around I would be very vary.

I think (and I could be wrong) that what you are imagining isn't quite what happens. When the customer signs up they go through the checkout process and agree to have their card charged a certain amount ($25 for example) once in a certain period (every two weeks, once a month, etc). This is sent to the payment processing company who stores all the this information and then returns a token to 30bz. 30bz stores this token together with the subscription details for the customer.

When it comes time to charge the customer 30bz will send this token to the payment processor and request that the charge happen. If the payment processor agrees that it is time to charge the customer then the charge is processed onto the customer's credit card and 30bz is told if the payment succeeded or not.

This type of system means that 30bz does not have to be PCI compliant and that no customer credit card details are stored with 30bz.

[Guest]

SagePay is one of the biggest in Europe (I just checked) so I think you should support that. :) You can do American Express and PayPal through SagePay, which is a big bonus. American Express is growing in Europe due to the bonuses they offer.

@Havouza you're not storing the customers credit card in your store, it's done through the payment system, which is as secure as a bank, that's why you use them. You're storing a token that's tied to your company account details so the recurring payment request must have your company ID on it. You need to ensure the customer knows up front what you're storing, maybe put it in the T&Cs.

I think in terms of security the payment gateway should seek confirmation from the customer if there's a requested change in the subscription amount, delivery location or any other change. This could happen if your website was hacked and the payment gateway / customer details taken. This would prevent the hacker getting access to the service / product that the customer has paid for.

[Havouza]

I dont think the storing that is the problem. I think it is the possibillity of cheating when the consent to recurring payments is held by the store not the gateway. But it is my opinion

[dynambee]

@Havouza said in Recurring payments in thirty bees:

I dont think the storing that is the problem. I think it is the possibillity of cheating when the consent to recurring payments is held by the store not the gateway. But it is my opinion

With a tokenized system the authorization is (AFAIK) held by the gateway, not the store.

[dynambee]

@DavidP said in Recurring payments in thirty bees:

You might want to take a look at AheadWorks Magento extension for this to get some ideas of how they do it.

Agreed 100%. Look at the current market leaders and see what they are doing that makes them a market leader. Then find out what features they lack that stores would like and add them where possible.

[lesley]

@DavidP and @dynambee I could not agree more. That is exactly how you make a better system. We might even go so far as to find a couple users and ask them what could be done to make it better and add those features in.

[dynambee]

If there is any possible way to integrate this with PayPal's subscription payments it would really be ideal to do so.

PayPal is available almost everywhere, almost anyone can open a PayPal account, customers like that they can see & manage the subscription info in their own PayPal account, there are no monthly fees for offering subscriptions, etc. I think it would make the overall subscription feature more useful to more people and thus have more potential upside for 30bz.

[ajensen27]

I currently have "Auto-Ship" setup in my store (still using Prestashop 1.6) using a customized Stripe module and it is working pretty well for me. So I will give a few of my ideas on what I currently have setup and what I would also like to see.

1. Each product in my store can bet set to turn on and off auto-ship for that product. The customer is also allowed to order these products without auto-ship. 1 time charge.
2. I'm able to set a discount for auto-ship. I can only set this to 1 value for the whole store but this works for me. Some people might want to have the ability to change the percentage based on each individual product.
3. I'm also able to set up the different auto-ship periods (1 week, 2 weeks, 1 month, etc.). This is for the whole store as well and works fine for my store. But some people might want to be able to set up these time periods for each individual product.
4. At the start of a new auto-ship period for a particular subscription, a new order is created in our system and the customer is automatically charged again in Stripe.
5. Customers are able to purchase product A with auto-ship and product B without auto-ship in the same order. When the time period comes to create a new order, it only creates it for product A.
6. Customers are able to cancel their auto-ship orders any time in their customer account. For customers who checked out as a guest, we would have to cancel those manually.
7. Customers cannot use a voucher on an order that contains a subscription. Ideally I would like for them to be able to use a voucher but it would not discount the subscription products in the cart. And if the voucher was for say $5 off, it would take the $5 off for that order but add it back on for the subsequent orders.

Things I don't have due to my developer not being able to complete them for me or I just didn't want to spend the money to have it developed.

1. Being able to change the subscription time period in the cart.
2. Guests being able to cancel (or change) their subscription (preferably by looking up the order in the order look up function).
3. Customer has being able to modify a subscription (the time period, add/remove products, etc.). Also the ability to skip the next subscription.
4. Send a reminder email to the customer a few days (can be set to whatever amount) before the subscription runs again.
5. Have the auto-ship orders created at a certain time (3 am for instance). Right now, my auto-ship orders are created at the same time they were ordered initially. So if a customer placed the initial order at 6 pm, then the subsequent auto-ship orders won't be created till 6 pm. My developer said this is a restriction of Stripes subscription API but if you aren't going to be using Stripe's subscription API and just use the customer token, then I believe this could be done.
6. And of course, add the ability for other payment gateways. Right now, if someone has a subscription product in their cart, I had my developer turn off the ability to pay by Paypal or check. Would love for a customer to be able to pay via Stripe, Paypal or check.

There might be a few other things I'm forgetting. I'll add them in later if I remember anything else.

You can see how I have auto-ship setup in my current Prestashop store here (https://tinyurl.com/yagsfrgf).

[Traumflug]

Also having a “hidden” product is not a perfect idea either. Say I have a shop that sells dog products and I have a subscribe and save option like Amazon has. I need to be able to pull a monthly stock status and see how many bags of xxx food are going to be autoshipped.

Having a hidden product would be the natural handle to define follow-up sales somehow. Merchants have to express somehow what should happen on subsequent shippings. I'm thinking of dog food coming with a feeding bowl first time, just the food on subsequent shippings. Or hosting subscriptions, which require processing initially, just money collection later. And of course it should be possible with a few lines of code to look up the schedule table to find out what's about to ship next week/month.

[lesley]

@Traumflug That is where all of the overwhelming logic comes in. I think using hidden products it will create a spiderweb of queries that are going to be hard to untangle. One thing that we will need is the option to exclude products. No one wants the dog bowl autoshipped I will imagine.

I like to follow Amazon's lead on things, I like the way their system works in the frontend

I think to pull reliable stats and not to overwhelm the database we need to do it off of the products themselves, not the orders as a whole. Let each autoship order have its own entry, one product per entry, then build from there.