When we look at thirty bees right now we do not see a complete e-commerce system. We see major features missing and recurring payments is one. We think the platform can be expanded greatly by adding the ability to have recurring payments. We are starting to look forward at a system that will allow for these kind of payments, but we need ideas and help.
The basic system
In our minds the recurring system needs to be build into the core and be a managed core system. There are some platforms that deal with recurring payments in modules, but we feel that limits what you can do. When you bas a recurring payment system off a module, you will run into compatibility issues with payment modules. There are some major gateways that support card storage and charging such as Stripe, Authorize.net, PayPal, SkyBank, and a few others. When you have a recurring module it does not actually know to charge the cards. This is a huge problem. You can make the module in such a way that it is compatible with the gateways that you are aware of, but it still cannot execute the external module. That is why we want to build it into the core.
In speccing out the system we need input from merchants to figure out what kind of billing system we need to implement. Currently we are kicking around 3 different models, but with your input that can change. The 3 models are:
- A shop solely based on recurring payment products, like BirchBox or BarkBox
- Shops that sell products that also have subscriptions to products as well
- Shops that do B2B sales that need to keep track of open invoices for net customers
Those are the 3 models we have currently on our radar. If you have another model that we did not list, please let us know in great detail. We are going to design this system so it can work with the largest amount of shops possible.
A technical look
To be technical about what we are doing, we are going to create a new system like the order page, but just for recurring orders. A place where you can see the recurring orders before they are processed and see what is in the queue. This will also come with its own new set of hooks as well. The reason we are creating it like this is so that payment and shipping module developers can easily latch on to the system. This will allow module makers to be able to make their modules compatible with the recurring payment system and provide the most flexibility possible.
We also need to design a system of fail-safes and fall-backs as well. What happens when the charge for an order is declined? Or when a product is out of stock and an order is set to be billed? We need to have a system in place that can handle these issues. We need a robust system. A system that can be built off of in the future, that modules can be made around, a system that works for just about everyone.
Why do we need your help?
We are developers and designers, not shop owners. We need input from our customers to know the best routes to take to develop a system that will be most suitable for the most number of shops. We need the feedback, we need ideas, we need to know how merchants all over the world operate. I am positive that there are some uses for a recurring system that we have not even thought about. Not because we do not care, just because we do not know your business. The same with features in the system, we need to know what features merchants would need without making the system over complicated.
Come over to our forum thread or leave a comment below and let us know what you think a recurring payment system in thirty bees needs.
