TLDR: I’m currently investigating the feasibility of building upon the work done with the Woocommerce plugin to substitute Woocommerce for Stripe Checkouts using the same or similar API calls. Feedback, input, or connection to other related ongoing work is greatly appreciated.
Slack thread regarding the genesis for this idea: Slack
The major question I have right now is how the Woocommerce plugin functions when a student initiates enrollment from the LMS - does it redirect to the Woocommerce checkout when they click ‘Enroll Now’ in the LMS catelog? We don’t utilize Wordpress so I haven’t tested the plugin personally. I’m working based on the information provided in eduNEXT demo here. The old ecommerce plugin required configuring a waffle flag to change the redirect from basket to the payment processor of choice. I didn’t see anything like that configured in the WooCommerce demo, so I’m assuming this may be a missing user flow?
Otherwise, I feel pretty good about the success prospects of being able to substitute WooCommerce with Stripe Checkout for enrollments initiated in an ecommerce environment external to the LMS. After which, we can then pass the enrollment to the LMS via API after the Stripe Checkout session clears payment.
Thoughts, input, guidance, wisdom, flat out open mockery… all welcome
Thanks @omar - I looked through this. Seems like a good option to pair with Stipe checkout pages/links that are intentionally built to reduce the need for a developer to configure the embed code. A “lower code” solution, per se.
For Stripe Checkout embeds where some code manipulation is needed anyway, using direct API calls is probably a little cleaner solution as it doesn’t require another app running etc.
My main impression - it all depends on which Stripe Checkout tool is being used. Personally, I’m looking into the Stripe Checkout Embed tools because I want to create a really clean user flow that requires minimal page changes.
Overall, after a nice conversation with @mafermazu on slack yesterday evening. I was able to establish that flows starting in the LMS don’t have any sort of redirect to the checkout configured at the moment. Together we broke a potential update approach down into two main buckets:
Adding Stripe Checkout as a substitute for WooCommerce for flows starting in an ecommerce environment. This should be a relatively straightforward modification using the same APIs except the API calls will be made from the Stripe Checkout Client as opposed to WooCommerce Wordpress Plugin.
Adding the ability for a flow to start in the LMS. This is a python/django solution that will require quite a bit more discovery and implementation work, but applicable to both the existing WooCommerce plugin, a new stripe checkout modification, and potentially any future payment processor additions.
Yes, @Ryan_Radwanski, as you said, there is no way to go from LMS to WordPress/WooCommerce checkout. Currently, the openedx-wordpress-ecommerce plugin works from the WordPress side, listening to the purchase event and generating the Open edX enrollments with Open edX API calls. This behavior works well if we use WordPress as a marketing site or our course catalog, but we don’t have a way for the flow you are proposing to start in the LMS.
My first thought about this is doing it through filters to avoid changing the openedx code directly. But we should take a look at it.
Regarding the Stripe checkout, I think it will be helpful for the community to have more options to adjust their necessities, particularly if they don’t want to have a WordPress page. I only want to add that we selected to work with WooCommerce for its extensibility; without extra effort, you could use the Stripe extension for WooCommerce, other payment methods, or any other feature, such as Coupons, Analytics, Tax, etc.
Yea, I was wondering about this. @Ryan_Radwanski is there a capability missing when using stripe via woocommerce? It having payment providers for whatever you need was one of the reasons we chose it so it’d be good to understand when that use case falls short.
@feanil I would suspect it all works well for the Wordpress user, but we don’t use WordPress so using WooCommerce isn’t really an option for us. There is no magic bullet, everything has trade-offs:
WooCommerce is extensible to multiple payment processors and abstracts away API configuration for each individual payment processor but adds the constraint of Worpress.
Configure payment processors directly to make API calls to LMS enrollment and you’re free from the constraint of Wordpress, but now every payment processor requires individual setup.
In my humble opinion, both are needed and useful; the WooCommerce plugin is an excellent starting point and there is good cause to build upon it.
@feanil thanks, this is all exactly what we were looking at when evaluating our solutions. I think for now, our group has found a relatively easy workaround to just avoid using ecommerce solutions for our immediate needs, but we are interested in seeing more payment processor options come available. Is this something to potentially explore as a funded development project? My group has decided not to pursue it right now on the basis of conserving limited resources of time and funding as a nonprofit, but several of us developers volunteering with the organization have worked or are actively working in the corporate payment processing fintech space so this would comfortably be inline with our skill set. It’s just not the organization’s highest pro-bono development priority.
