[Discovery] What ecommerce / basket / payment / order-history integration should stay in openedx-platform?

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

1. Is there any supported in-platform purchase/upgrade path now, or is paid enrollment fully external (enrollment API + tools like openedx-wordpress-ecommerce)?
2. 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.
3. 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

• openedx/openedx-platform#38936 - MFE-rewrite tracker (Basket/Payment, Order History rows).

Start by reading lms/djangoapps/commerce/, openedx/core/djangoapps/commerce/, and the ~11 upgrade or buy call-sites listed in the issue. Trace EcommerceService, its pluggable_override hooks, configuration defaults, and the v0/v1 APIs to identify external dependencies. Done means documenting whether each surface is removable, should remain an extension point, or needs a DEPR, with the MFE tracker implications resolved.