Recurring payments in thirty bees

  • 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,

  • 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

  • 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.

  • 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

  • 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?

  • 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

  • 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.

  • @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.

  • 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?

  • @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, 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.

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

  • @Havouza Absolutely, see the reply from @DavidP above

  • 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.

  • 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.

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

  • @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.

  • 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.

  • 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

  • @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.

  • @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.


Looks like your connection to thirty bees forum was lost, please wait while we try to reconnect.