Context
The ecommerce service is deprecated, and Commerce Coordinator is dead, so there's no in-tree successor to the old purchase/upgrade backend. Paid enrollment today appears to be handled by external tools (e.g. openedx-wordpress-ecommerce) that create enrollments via the enrollment API and never touch the platform's basket/upsell integration. Meanwhile a fair amount of ecommerce integration code still lives in openedx-platform, and it's not clear what's load-bearing vs. dead.
This blocks the Basket/Payment and Order History rows in the MFE-rewrite tracker (#38936). Unlike the other rows there, these aren't standalone pages - the pages lived in the ecommerce service and its MFEs; what's in edx-platform is the integration layer plus the upsell call-sites.
What's in the platform today
lms/djangoapps/commerce/ - the integration layer: EcommerceService (basket/checkout/receipt URL builders), CommerceConfiguration model, API v0 (baskets) + v1 (courses, orders), the ecommerce API client (http.py), and management commands.openedx/core/djangoapps/commerce/ - commerce utils / API config.ORDER_HISTORY_MICROFRONTEND_URL setting - the link to the order-history MFE.- ~11 "upgrade to verified / buy" call-sites across
courseware, learner_home, programs, verify_student, credit, experiments, support.
What I found (current default behavior)
The integration is off and inert by default:
CommerceConfiguration.checkout_on_ecommerce_service defaults False, and there's no default ECOMMERCE_API_URL / ECOMMERCE_PUBLIC_URL_ROOT.EcommerceService.is_enabled() is False by default, and upgrade_url() falls back to reverse('dashboard') - so "upgrade" links are no-ops in vanilla.- Order history depends on
ORDER_HISTORY_MICROFRONTEND_URL (default None), so it's absent by default.
It only "wakes up" if an operator points it at the deprecated ecommerce service. One important wrinkle: EcommerceService exposes plugin hooks (OVERRIDE_GET_CHECKOUT_PAGE_URL, OVERRIDE_GET_ABSOLUTE_ECOMMERCE_URL, OVERRIDE_REFUND_ENTITLEMENT), so it may be a pluggable checkout seam that external commerce tools use to inject their own payment page. That's the piece that makes "just remove it" risky, and it's the main thing this discovery needs to settle.
Questions to answer
- Is there any supported in-platform purchase/upgrade path now, or is paid enrollment fully external (enrollment API + tools like
openedx-wordpress-ecommerce)?
- Are the
pluggable_override hooks on EcommerceService a supported extension point that external commerce tools rely on? If so, that seam - and the upsell call-sites that use it - needs to stay in some form.
- Given those answers, sort the surface into: safe to remove now (dead code), keep as an extension point, or needs a DEPR.
My starting hypothesis, to be confirmed or corrected:
- Likely removable: the order-history MFE link +
OrderView, the ecommerce-service-specific API client + checkout_on_ecommerce_service config, and commerce/api/v0 baskets.
- Needs a decision:
EcommerceService.get_checkout_page_url + the upsell call-sites - keep as a pluggable checkout seam, or remove.
Related
Context
The ecommerce service is deprecated, and Commerce Coordinator is dead, so there's no in-tree successor to the old purchase/upgrade backend. Paid enrollment today appears to be handled by external tools (e.g.
openedx-wordpress-ecommerce) that create enrollments via the enrollment API and never touch the platform's basket/upsell integration. Meanwhile a fair amount of ecommerce integration code still lives inopenedx-platform, and it's not clear what's load-bearing vs. dead.This blocks the Basket/Payment and Order History rows in the MFE-rewrite tracker (#38936). Unlike the other rows there, these aren't standalone pages - the pages lived in the ecommerce service and its MFEs; what's in
edx-platformis the integration layer plus the upsell call-sites.What's in the platform today
lms/djangoapps/commerce/- the integration layer:EcommerceService(basket/checkout/receipt URL builders),CommerceConfigurationmodel, APIv0(baskets) +v1(courses, orders), the ecommerce API client (http.py), and management commands.openedx/core/djangoapps/commerce/- commerce utils / API config.ORDER_HISTORY_MICROFRONTEND_URLsetting - the link to the order-history MFE.courseware,learner_home,programs,verify_student,credit,experiments,support.What I found (current default behavior)
The integration is off and inert by default:
CommerceConfiguration.checkout_on_ecommerce_servicedefaults False, and there's no defaultECOMMERCE_API_URL/ECOMMERCE_PUBLIC_URL_ROOT.EcommerceService.is_enabled()is False by default, andupgrade_url()falls back toreverse('dashboard')- so "upgrade" links are no-ops in vanilla.ORDER_HISTORY_MICROFRONTEND_URL(defaultNone), so it's absent by default.It only "wakes up" if an operator points it at the deprecated ecommerce service. One important wrinkle:
EcommerceServiceexposes plugin hooks (OVERRIDE_GET_CHECKOUT_PAGE_URL,OVERRIDE_GET_ABSOLUTE_ECOMMERCE_URL,OVERRIDE_REFUND_ENTITLEMENT), so it may be a pluggable checkout seam that external commerce tools use to inject their own payment page. That's the piece that makes "just remove it" risky, and it's the main thing this discovery needs to settle.Questions to answer
openedx-wordpress-ecommerce)?pluggable_overridehooks onEcommerceServicea supported extension point that external commerce tools rely on? If so, that seam - and the upsell call-sites that use it - needs to stay in some form.My starting hypothesis, to be confirmed or corrected:
OrderView, the ecommerce-service-specific API client +checkout_on_ecommerce_serviceconfig, andcommerce/api/v0baskets.EcommerceService.get_checkout_page_url+ the upsell call-sites - keep as a pluggable checkout seam, or remove.Related