Sylius: [Roadmap] Recurring orders / Subscriptions
The idea is to handle order payments for specified month counts.
Describe the proposed solution
Conceptually I see an additional entity e.g. RecurringOrder, which have relation many-to-one to Order, and in Admin section there are an custom form, which shows and allows to edit paid months.
doctorx32
All 12 comments
@doctorx32 You mean something like subscriptions?
pjedrzejewski
on 20 Jun 2018
@pjedrzejewski yes, as use case magazine subscriptions
doctorx32
on 20 Jun 2018
This would be fantastic to have. There are several gateways out there that support subscription payments and this would be great for LMS type applications
alexrowesoap
on 17 Jul 2018
Trust me, it is hard to handle properly. (I founded https://pagaio.com)
And It's a long journey :).
jacquesbh
on 16 Aug 2018
For those looking for a lead / example: https://github.com/BitBagCommerce/SyliusMolliePlugin
alexrowesoap
on 15 Nov 2018
Hey all,
Thought I'd add an update. We are progressing with our build, and we have a working recurring setup which I thought would be worth outlining.
After a lot of thought we decided to separate the subscription away from the order: the order simply spawns the subscription (by taking a deposit). A subscription entity stores the payment token, and it also has x number of subscription payments, where x is the term length times the frequency of payments. Subscription payments have a due date.
A cron processes subscription payments.
Once all the Subscription Payments in a Subscription are successful the order is transitioned from a state representing it is on subscription, to complete.
The reason we went with the recurring payments rather than orders meant there was a separation of concerns in that the order didn't rely on the subscription's existence or state, allowing the order to remain immutable without having to link to other orders. It also allowed for easier (in our case) management of subscriptions, in that the terms and scheduled payments can be altered / cancelled if the customer requests it.
This kind of approach means that the customer only has one order for a subscription rather than lots, but it wouldn't work for other scenarios.
I think it would be great for us to make some example use cases where recurring payments are needed in one form or another. eg:
- Software subscriptions
- Perishable goods deliveries
- Membership fees
Our approach only works because the products are virtual, so don't need shipping. For physical goods, you'd have to create new orders to track the shipments against.
Thoughts?
alexrowesoap
on 20 Feb 2019
@alexrowesoap Do you have any code examples of this concept? I will need to implement recurring payments as a Sylius plugin soon, can't wait for this to be part of Sylius, unfortunately :)
moodledev
on 9 Jul 2019
I'm also very very very interested in this. I'll need to add a "Premium Membership" feature sooner or later, with recurring anual payments. Does anyone have any code example that can be shared? It may be useful in quite a lot of cases, including this issue in the roadmap.
migmolrod
on 30 Sep 2019
Hey everyone. Apologies for the slow reply.
Unfortunately the code's IP is with the client, so I can't share it right now.
That being said, it's not too hard to implement.
alexrowesoap
on 12 Nov 2019
Is there an update to this? Thanks in advance!
softrare
on 1 May 2020
It isn't that hard to implement on your own, the hardest part is the payment system as Sylius' out of the box payment system options aren't great right now. I've done it using my own implementation of Stripe's payment intent (inspired from Combodo's Stripe Plugin at first but then went on to implement StripeJS w/ 3D secure instead of Checkout, both worked). Just got a Subscription entity that is created by a payment complete listener if an order has a Product with the added is_subscription flag = true. Then a cron job command that generates the order from that Subscription entity when times comes to ship it and proceeds to payment via Stripe's off session payment intent. Sadly, I can't share the code either. I think the focus for this as far as Sylius is concerned should be on the payment systems rather than the Subscription itself because as alex pointed out it does depend a lot on your business logic.
tuala
on 4 May 2020
Gotcha! Thanks a lot for your instructions. I will try implementing Mollie as payment provider.
softrare
on 6 May 2020
Related issues
stefandoorn
路
3Comments
loic425
路
3Comments
hmonglee
路
3Comments
xleliberty
路
3Comments
bnd170
路
3Comments
Most helpful comment
Hey all,
Thought I'd add an update. We are progressing with our build, and we have a working recurring setup which I thought would be worth outlining.
After a lot of thought we decided to separate the subscription away from the order: the order simply spawns the subscription (by taking a deposit). A subscription entity stores the payment token, and it also has x number of subscription payments, where x is the term length times the frequency of payments. Subscription payments have a due date.
A cron processes subscription payments.
Once all the Subscription Payments in a Subscription are successful the order is transitioned from a state representing it is on subscription, to complete.
The reason we went with the recurring payments rather than orders meant there was a separation of concerns in that the order didn't rely on the subscription's existence or state, allowing the order to remain immutable without having to link to other orders. It also allowed for easier (in our case) management of subscriptions, in that the terms and scheduled payments can be altered / cancelled if the customer requests it.
This kind of approach means that the customer only has one order for a subscription rather than lots, but it wouldn't work for other scenarios.
I think it would be great for us to make some example use cases where recurring payments are needed in one form or another. eg:
Our approach only works because the products are virtual, so don't need shipping. For physical goods, you'd have to create new orders to track the shipments against.
Thoughts?