Deprecation/Removal: Ecommerce service (DEPR #22)


edX’s monolithic Ecommerce Service was meant to be a full-featured product catalog, discounting, and order management service and has grown in complexity for many years until it has become very hard to maintain, let alone evolve. In that time, more and better hosted services have become available for solving many of these problems, and complex use cases have evolved that make flexibility vital for Open edX operators, including

We are building a new system that should be flexible and adaptable enough to support any ecommerce product of choice. By uncoupling openedx from a specific ecommerce product, we will enable more contributors and deployments, and remove edX as a blocker for others’ ecommerce.


At the center of the new system is the Commerce Coordinator, a highly modular Django web service written in Python. Coordinator will provide a framework for configuring ecommerce capabilities. Individual Django apps will act as plugins to implement specific functionality, for example a webhook for a payment service provider to call when a purchase is successful, that plugin can then signal one that performs the fulfillment in the LMS. The core of the Coordinator will allow commerce workflows to be tailored by combining plugins and routing signals, and will eventually include tools for validating configurations and tracing signal flows.


We have completed some upfront design and proof-of-concept work and are now bringing it to the community for awareness, review, and support. The next steps will be to flesh out the Coordinator Core while we begin building decoupling Coordinator Plugins to bridge legacy ecommerce. During this process, edX will also begin building plugins to bridge our ecommerce vendor of choice.

We intend to officially deprecate legacy ecommerce by April 1st 2022. When the legacy ecommerce service has been fully decoupled from the platform, it will be removed from openedx or transferred to a new maintainer. Please comment on the deprecation ticket by April 30th 2022 if you would be interested in taking over maintenance.


The community can support this development effort in three main ways:

  • Help with Core improvements, particularly signal validation and signal traceability
  • Write Plugins to decouple legacy ecommerce
  • Write “minimum viable” Plugins for development environment

Please reach out if you are interested in collaborating on any of these.

Coordinator will be rapidly evolving and may need some time to stabilize before being included in named releases. Once stabilized, the core should require relatively few changes, and anyone can write their own plugins to suit their needs and sideload them as desired.


Tight and transparent communication with the community will be critical to success. To keep the community informed of our progress, edX will provide monthly updates to Discourse.


Legacy Ecommerce Deprecation Ticket
Commerce Coordinator Repo
Commerce Coordinator Architecture Decisions


@bjh what will be the effect of the deprecation? It sounds like this deprecation is very early directional announcement and is meant to communicate that the ecommerce service is going to be put into “maintenance mode”. Meaning, new features are not likely to get added or accepted by the team that currently maintains the service?

When you are ready to proceed with the removal, I imagine there will be more communication as well as documented alternatives where it makes sense?


Correct on both counts


The ecommerce and ecommerce-worker repositories have been marked as deprecated; they will be in maintenance-only operation while we work on the replacement.


Have there been any updates to share? I’m definitely interested in keeping track of plans, progress, and timelines for commerce-coordinator as my team tries to plan out the eventual integration of our own payment provider.

1 Like

I have asked the Build-Test-Release Working Group if we are closely following the ecommerce deprecation and the forthcoming commerce-coordinator.

I felt “blindsided” when the Payment MFE stopped supporting custom payment processors with Lilac and this is the major reason why we have not migrated our Open edX instance to Lilac-Maple-Nutmeg yet. We are still using Netbanx/Paysafe with our Native Koa implementation. We will soon have to switch to Cybersource when we move to Tutor on our production system in the next few months. Months of dealing with the political implications of that change with our financial backend.

I know this is partially unrelated but I agree that most providers using ecommerce now will need to find a way to replace ecommerce, use commerce-coordinator and setup a new commerce solution in the near future. Regular updates would be a first step. Thanks.

1 Like

We can not upgrade to newer versions of tutor because custom payment processors are not supported and we don’t know when the new ecommerce is available. Really appreciate if we can get a very rough estimate of the timeline,

@michael, thanks for the question. We have only very recently begun coding on this project, but now that we have started I will set a reminder to post updates here on a monthly basis from here on out.

The main update is we are starting to build a small proof of concept focused on porting receipts and enrollment codes into the Coordinator.

We plan to build the prototype and Coordinator plugins we develop in the public edx/commerce-coordinator repo on GitHub, so you are welcome to follow the work there as well.

@sambapete I didn’t know of the historical context, so I’m glad you shared it. The plan continues to be to release documentation and preserve feature flags on how to do the migration to the Coordinator.

The first step is documentation for migrating from ecommerce receipts to frontend-app-ecommerce via the Coordinator. Development of that documentation will start after we finish the coding.

I’m not always the best at finding threads in Discord, but I try to be available in the #commerce-coordinator on the Open edX Slack. Looking forward to continuing to receive any thoughts, ideas, or feedback as we together as a community work on the future state of commerce in Open edX.


Hey @Anh_Vu_Nguy_n! We have wanted custom payment processors for a long time as well. Tutor is new to us, and we have experimenting with creating a Tutor plugin on our roadmap. Do you or anyone you know have the bandwidth to help us get a Tutor plugin set up for the Coordinator? Would love to work together.

1 Like

Thanks for the response @pshiu.

I have been trying to keep an eye on the repo, but your slides from the Slack channel were helpful in understanding how commerce-coordinator fits into the product. It sounds as if commerce-coordinator will eventually enable tremendous “pluggability” on the backend, but that it isn’t intended to address the issue of frontend-app-payment supporting only a fixed set of payment processors. Does that sound correct?

In any case, I’m really excited about the work you’re doing on commerce-coordinator, and looking forward to future updates.

That’s correct, @michael. Pluggability is something we’re hoping will make adding payment processors easier in the future.

Thank you!

Hi all,

this is a small update on ecommerce deprecation. We continue to build the prototype and Coordinator plugins in the public edx/commerce-coordinator repo on GitHub.

Hello everybody! Apologies again for our absence from the airwaves. Here is our update for October and November:

  • We just wrapped up a high-priority project to change our default payment processor from Cybersource to Stripe. This project upgrades the existing Stripe payment processor in ecommerce to support Stripe payment intents and makes it compatible with frontend-app-payment. It is now in master.

  • We have not made further progress on the Commerce Coordinator or the Ecommerce Replacement Project since the last time we posted about it.

  • We can now share that we picked an internal vendor to be the backend of our order management system. While this means other community members will not have access to integrate with the same internal vendor, we will continue to brainstorm ways to make the Coordinator useful for the Open edX community.

  • Right now we are picking it up again and are working on the open source strategy for the Theseus project and being intentional about working with the community on this.

  • We’re excited to welcome @grmartin, who together with myself (@pshiu) will serve as the the Open edX community’s technical points of contact for the Ecommerce Replacement Project.

  • We are still looking for a maintainer for our old ecommerce repository. Please let us know if you are interested or know someone who might be.

  • The Open edX Slack channels are being cleaned up, and we will fold the existing #commerce-coordinator Slack channel into the #ecommerce channel.

  • We plan to have a virtual ecommerce summit before the end of 2022. We hope to post more information about this soon.

While we will continue to watch this thread, the quickest way to reach us is via the #ecommerce channel on Slack. Hope to see you there.


Thanks for this update @pshiu!

This means that Stripe payment is now supported in Ecommerce, right? Are there any further instructions for connecting with Stripe other than modifying the settings, as indicated here? Payment Processors — E-Commerce Service 0.1 documentation

Also, is Stripe payment now supported in Olive? I would be great if it were.

1 Like

Hi @regis! Thanks for the questions.

Work on the documentation is scheduled for our upcoming sprint. We hope to have better documentation on Stripe in the future.

Olive was cut before our Stripe upgrades were completed. I am not very familiar with BTR’s process, so I assume we must wait until Palm to see Stripe in an Open edX release.

Honestly, having the Stripe upgrades arrive in Palm might be best, because it’ll allow us more time to do the documentation you mentioned above, do some clean up before the release, and get the word out to operators who may be running the old Stripe payment processor.


We have just announced an info session about ecommerce deprecation and replacement.

1 Like

Thanks @pshiu ! I’m just looking for a clarification on:

Does the intended setup look like this:

(InternalVendor) <-> (CommerceCoordinator) <-> (LMS/CMS)

or this:

(InternalVendor) <-> (LMS/CMS)
                (CommerceCoordinator) <-> ???


Put another way: Will 2U use Commerce Coordinator, and if so, where does it sit in the architecture?

1 Like

Hey Kyle,

Your first diagram is our plan!

1 Like

Our team held an info session on ecommerce deprecation. Please find materials from the session in this post.

1 Like

Hi all,

here is our winter update:

  • Our current focus: Documenting the commerce-related API calls between Open edX services, working on basic purchases & payments in ecommerce & frontend-app-payment.

  • Next info session: our quarterly Ecommerce info session will be postponed from March to April due to the scheduling conflict with the Open edX conference. If you are attending, come find Glenn and Phil there. We will announce date of the info session in April as soon as we can.