What Open edX with WordPress and WooCommerce sells and how the pieces connect
A WordPress site with WooCommerce sells access to Open edX courses by treating a paid order as the trigger for an LMS enrollment. WordPress carries the marketing pages and course listings, WooCommerce handles the cart, checkout, payment and order records, and Open edX runs the courses and each learner's enrollment. A commerce bridge joins the two sides, and the sale is only complete when the buyer can open the course they paid for. Because the legacy e-commerce service is deprecated, that bridge must be one of the supported paths named for this work: the Open edX Commerce plugin or the Webhook Receiver.
Walk one order through the system. A learner buys a course product in WooCommerce. Once the payment is confirmed, the bridge receives the order, identifies the learner's account on the LMS, and identifies the course run tied to that product. It then requests an enrollment in that run. Your team should define the mapping between WooCommerce products and course runs, and the rule that matches a buyer to an LMS account, probably by email address. A mismatch in either leaves a paid learner without access. Confirm whether the chosen method enrolls the learner directly or only passes the order to another component that does.
The harder cases are the ones that reverse or never finish. A failed or pending payment should create no enrollment, so the bridge must act only on order states that WooCommerce has finalized. A refund needs a defined outcome: revoke the enrollment, keep access in place, or route the case to a person. Agree that policy with finance and the course owners before the build, because the code path depends on it. Plan for retries when the LMS is unavailable during a webhook call, and for a reconciliation report that compares paid orders with active enrollments so gaps are found before learners complain.
Several points are not settled by the material available here. The documentation for the Commerce plugin and the Webhook Receiver must be checked against the Open edX release in use, because the latest named release is the only supported one and plugin support can differ by release. Confirm with the vendor or plugin maintainers which method is supported for your release, how refunds and cancellations are signaled, how free or bulk enrollments are handled, which WordPress and WooCommerce versions the plugin supports, and who maintains the bridge after go-live. Keep WordPress on a supported version as well, since only the latest release is officially supported.
What the WordPress and WooCommerce side needs before the Open edX work starts
The WordPress and WooCommerce side depends on a small set of versions, network paths, certificates and secrets that the Open edX work relies on. Confirm each one before the build starts so the commerce integration can be tested against the same Open edX release from the beginning.
Running Open edX release
Confirm that the LMS runs as a Tutor-based install on Verawood, the current named release published on 30 July 2026. Open edX supports only the latest named release at a time, so the chosen release sets the plugin and commerce versions you test against. Check the upgrade path to Willow, listed for December 2026, before you fix the build plan.
WordPress hosting baseline
WordPress.org recommends PHP 8.3 or greater and either MariaDB 10.11 or greater or MySQL 8.0 or greater for hosting WordPress. Run WordPress in the 7.1 series on its most recent release, because only the latest release in that series is actively maintained. Confirm these versions on the host that will serve checkout, since an older PHP version can hold back WooCommerce and plugin updates.
WooCommerce and plugin compatibility
Confirm each pairing before the build: WooCommerce, every commerce-related plugin, and the Open edX Commerce plugin or Webhook Receiver must be checked against the chosen Open edX release. Keep a written test matrix that records each version and the date it was verified. Because the legacy e-commerce service is deprecated, ask the implementation team to confirm which plugin version supports your release.
Network paths between hosts
Map every request that crosses between the WordPress host and the LMS, including enrollment calls, webhook deliveries and any API reads. For each flow, identify the direction, the ports and hostnames involved, and which side initiates the connection. Confirm firewall, DNS and proxy rules in both environments, including any egress policy on the WordPress host.
TLS certificates for both hosts
Issue valid certificates for the LMS and WordPress hostnames from a trust chain that both servers accept. If one side calls the other over HTTPS, confirm that the calling host trusts the certificate authority that signed the internal certificate. Plan renewal dates and automation, because an expired certificate can stop enrollment and webhook delivery at the same time.
Service accounts and shared secrets
Create a dedicated LMS service account for commerce-related calls, with only the permissions the integration needs. Generate the API or webhook secret outside the code repository and store it in a secret manager on both hosts. Document an owner, a rotation procedure and the steps to revoke the secret if either side is compromised.
Choosing the Commerce plugin or the Webhook Receiver for Open edX sales
The choice between the Open edX Commerce plugin and the Webhook Receiver decides which system holds the order record and which process grants or removes course access. Make this decision before any WooCommerce product is configured, because the answer determines what the WordPress store has to send, what Open edX has to accept, and who answers when a learner says they paid but cannot see the course. Before publishing this section, confirm in the official Tutor and Open edX documentation the current support status of each component, the Open edX releases each one supports, and the configuration fields the team will need to set. Start with order state and enrollment triggers. Ask where the paid, failed, pending and refunded states live, and which system is authoritative when they disagree. Then ask how a successful payment reaches the LMS and results in enrollment, and what happens on a duplicate notification, a delayed notification or a payment that completes after the learner has already left the checkout page. Refunds and cancellations need the same scrutiny. Decide whether access is revoked automatically, whether a staff member must approve it, and how the learner is told. Write these cases as test scenarios, including a purchase, a repeated delivery, a refund after enrollment and a cancellation before the course starts.
The second axis is how much custom code the team is willing to own. A Webhook Receiver usually means the organization owns the endpoint, the payload mapping, the authentication of incoming requests and the logging of every transaction, so the engineering effort and the on-call responsibility sit in-house. A maintained plugin moves part of that work to the plugin maintainers but ties the site to the plugin's supported releases and configuration model. Ask the vendor or community maintainers which Open edX releases each option supports, and whether the plugin tracks the current named release. Open edX supports only its latest named release, and the current release, Verawood, was published on 30 July 2026, with Willow and Xylon listed for December 2026 and June 2027. Each platform upgrade therefore needs a compatibility check for the sales path in a staging environment before production changes.
Maintenance also covers the WordPress and WooCommerce side. WordPress supports only its latest version, and the 7.1 series is the one actively maintained. Automatic background updates for plugins and themes apply by default only in special cases chosen through the WordPress.org API, so payment and commerce plugins will not necessarily receive updates on their own. Assign a named owner for WordPress core, WooCommerce, the payment gateway and whichever Open edX method is chosen, with a documented patch window and a test order that runs after each change. Include the Tutor and Open edX upgrade cycle in the same calendar so that a platform upgrade does not land on top of an untested commerce change. To finish the decision, write the answers to five questions: who owns the order state, what triggers enrollment, how refunds and cancellations reach the LMS, how much custom code the team will maintain, and how each option is kept working across Open edX and WordPress upgrades. Share those answers in the written scope when requesting a quote, because the effort for the chosen method, the test matrix and the upgrade support all follow from them.
Setup order for Open edX with WordPress and WooCommerce
This sequence takes an Open edX course from a test environment to a paid enrollment flow in production, with a verification at each step so that sales, enrollment and refunds are proven in staging before any learner pays. It separates the platform, the storefront and the connecting method so that a fault can be traced to one layer.
Create the Open edX test environment on Tutor
The implementation team installs Open edX with Tutor in a non-production environment inside your infrastructure, using the release you have chosen for the build. Tutor is the official Docker-based distribution, and the maintainers recommend it over bare-metal installation, so the test environment should mirror the production layout as closely as practical. Confirm the target named release with your team and check its release notes before installing. This step is done when you can sign in to the LMS and Studio, create a draft course, and see the course in the LMS admin views.
Create a sandbox WordPress and WooCommerce install
Next, the team builds a separate WordPress site with WooCommerce in a sandbox, on PHP and database versions that WordPress.org lists as recommended for the WordPress release you select. Use the latest WordPress version, since only that version receives active support, and confirm the WooCommerce version against its own compatibility notes. Keep the sandbox off any public domain and disable live payment gateways. This step is done when the storefront loads, the WooCommerce setup wizard completes, and the site shows the expected WordPress and WooCommerce versions in the admin dashboard.
Configure the chosen connection method in staging
The team connects the two systems in staging using either the Open edX Commerce plugin or the Webhook Receiver, based on the decision made in the design phase. Configure the shared secrets, the LMS and storefront URLs, and the product-to-course mapping, and record every setting in version control so that production can be built from the same definition. Confirm that the legacy e-commerce service is not part of the chosen path. This step is done when a configuration check reports both endpoints reachable and the connection test returns a successful response from each side.
Create a test course and a paid product
The team publishes a test course in Studio and creates a matching WooCommerce product that points to it, with a test price and a test sales tax setting if your jurisdiction requires one. The product mapping must use the course identifier exactly as Open edX stores it, since a mismatch is the most common cause of a purchase that never results in enrollment. Your product owner signs off on the course name, price and access terms. This step is done when the product page displays the correct course and the mapping check in the connection tool confirms that the product and course are linked.
Run a test purchase that produces an enrollment
A tester places an order with a test account, using the sandbox payment gateway, and completes checkout. The order should move to a paid or completed status in WooCommerce, the webhook or plugin should record a successful delivery, and the learner should appear as enrolled in the course in the LMS. Check each of these in order, because a failure at one point shows up as a missing record at the next. This step is done when the enrollment record exists in the LMS, the order status matches the expected paid state, and the delivery log shows a success response for that order.
Test a refund or cancellation
The tester refunds the test order in WooCommerce and cancels a second test order before fulfillment, then checks how the platform responds. The question to answer is whether the learner's enrollment is revoked, retained or flagged, and whether your policy matches that behavior. Confirm the outcome with the business owner before production, because the platform and the storefront do not always handle refunds the same way. This step is done when the refund status in WooCommerce matches the enrollment state in the LMS as the written policy requires, and the logs show the matching event on both sides.
Promote the configuration to production
Only after the earlier checks pass, the team deploys the same configuration to production from version control, with production secrets and real payment gateway settings entered separately. Repeat a small set of checks on production with a controlled test order that is refunded immediately, using a reconciled test account. Keep the staging environment available for future changes. This step is done when the production test order produces the same enrollment, status and log results as staging, and the operations owner signs off on monitoring for the new flow.
Which order, learner and enrollment fields must match across the two systems
This table pairs WooCommerce commerce records with the Open edX records they must correspond to, so the team can see where data is created, which key links them and where decisions are still open. Use it as a checklist for the design workshop, then confirm exact field names and supported mappings against the documentation for the integration method you choose.
| Commerce or LMS entity | WooCommerce side | Open edX side | Decision or check before build |
|---|---|---|---|
| Customer and learner account | Customer record created at checkout, with billing email and name | LMS user account matched by email or a linked identifier | Decide the identity key (usually a verified email) and whether a learner must already have an LMS account before buying |
| Guest checkout | Order placed with no registered WooCommerce customer | No LMS account exists at payment time | Decide whether guests are blocked, asked to register, or provisioned after payment, and who sends the activation message |
| Email change | Customer edits email in the WordPress account or at checkout | LMS email may remain unchanged, breaking the match | Define the source of truth for email and how changes propagate, with a rule for conflicting accounts |
| Product and course run | Product or variation mapped to a sellable offer | Course run identifier with start and end dates and enrollment window | Confirm the product-to-course-run mapping supports multiple runs, and how a retired run is handled |
| Mode (audit or verified) | Variation or product attribute that selects the paid option | Enrollment mode set on the enrollment record, where the platform supports it | Confirm which modes the chosen plugin or webhook flow can set and how a mode change after purchase is recorded |
| Order and line item | Order ID, line item, quantity and order status such as paid, completed or refunded | No native order object; the enrollment or event carries the reference | Decide which WooCommerce order ID is stored with the enrollment so support can trace each seat |
| Order status and enrollment state | Paid, processing, completed, cancelled or refunded status | Enrollment active or inactive, and the date it was granted | Set the rule for which status grants access and which revokes it, and whether revocation is automatic or manual |
| Refund | Refund record linked to the original order and line item | Enrollment deactivation or mode change, depending on the flow | Confirm whether refunds are pushed to the LMS automatically and how partial refunds are represented |
| Completion and certificate | Not stored in WooCommerce; order records do not change on completion | Course completion and certificate status in the LMS | Decide whether completion is reported back to WordPress and which system is authoritative for reporting |
Running WordPress as the marketing site without exposing the LMS
Run WordPress as the public marketing and catalog site on its own hostname, and keep the Open edX LMS and Studio on separate hostnames with their own access controls. The split matters because WordPress is the component most exposed to public traffic, comment spam, form abuse and a fast-moving plugin ecosystem, while the LMS holds learner records, enrollments and course content. Keeping them apart lets the marketing team publish landing pages, course descriptions and pricing on a schedule without giving WordPress accounts any path into the LMS database, Studio or staff tools. Decide early which system is the source of truth for each course listing, since a catalog copied into WordPress will drift from the LMS unless someone owns the sync.
WordPress is released under the GPLv2 or later, according to the WordPress.org license page. For your team, that means WordPress itself can be modified and redistributed under those terms, and any theme or plugin you distribute that is derived from WordPress code must be licensed compatibly. Custom code written for your own site and kept internal does not have to be published, but ask counsel to confirm how the GPL applies to any purchased commercial plugin or theme, and to any code you hand to a partner or other organization. Your Open edX code is a separate question: edx-platform is licensed under the GNU Affero General Public License version 3, so the WooCommerce bridge should be treated as an independent component with its own license review rather than assumed to share terms with either project.
The update model is where a commerce site most often breaks. Only the latest WordPress version is officially supported, although the WordPress Security Team backports fixes to older versions as a courtesy, so older sites receive critical security fixes via auto-updates. Automatic background updates were introduced in WordPress 3.7, and since WordPress 5.6 newly created sites have automatic major release updates enabled by default. Plugin and theme auto-updates are not general: by default WordPress applies them only in special cases determined by the WordPress.org API, which the security team controls to patch critical vulnerabilities. That means WooCommerce, the Open edX Commerce plugin or the Webhook Receiver, and payment gateway plugins may update on a schedule you did not choose, and a feature release can change checkout behavior even when the update is not a security fix.
Set up a staging copy of the marketing site with the same WooCommerce version, plugins, theme, payment gateway settings in test mode, and a test connection to a non-production LMS. Test checkout end to end before any production update: add a course to the cart, complete a test payment, confirm the order, confirm the enrollment appears in the LMS, and confirm the confirmation email is sent. Take a full database and file backup before each production update, and record the exact versions of WordPress, WooCommerce and every plugin so you can restore them. Confirm with your hosting provider how a rollback is performed, because restoring files without the matching database can leave orders and plugin settings inconsistent.
Decide who owns updates and who can approve a rollback. Disable plugin and theme auto-updates for the commerce components if your change process requires review, and keep core background updates on only if your team has tested that path. Monitor the WordPress security page and the release notes for WooCommerce and your gateway plugins, and schedule a recurring review so updates are not deferred until a vulnerability forces an emergency change. Ask any partner to include staging, checkout regression tests and a documented rollback procedure in the written scope, and confirm which of those items are included in the quote and which remain your responsibility.
Security controls for the checkout and enrollment path
The checkout and enrollment path crosses three systems: WordPress with WooCommerce takes the order, a webhook or plugin carries the event, and Open edX grants access. Each hop needs its own control, and the controls only hold together if the team reviews them as one path.
TLS on every hop
Encrypt each connection in the chain: browser to WordPress, WordPress to the Open edX LMS, and any call to the Commerce or webhook endpoint. Check certificate validity, renewal, and that HTTP redirects never carry order or learner data. Confirm that internal calls between services also use TLS when they cross a network segment you do not fully control.
Shared secret or signed webhook verification
Configure the receiving endpoint to reject any enrollment request that lacks a valid signature or shared secret. Store the secret outside the WordPress database and rotate it on a schedule you document. Test rejection with a deliberately wrong signature before go-live, because an endpoint that accepts unsigned requests lets anyone enroll learners.
Least-privilege service credentials
Create a dedicated Open edX service account for the commerce integration with only the permissions needed to enroll learners in the courses it sells. Do not reuse a staff or superuser account. Ask the integration's documentation which role or scope it requires, and review that account's access after each platform upgrade.
Restricting which WooCommerce events trigger enrollments
Limit enrollment to a short list of order statuses, such as payment completed, and ignore refunds, pending orders, and events for unmapped products. Map each WooCommerce product to a specific course run so that a mistyped product cannot grant access to the wrong course. Test refunds separately, since an enrollment created by a paid order may need a defined revocation path.
Separating staging and production keys
Use distinct signing secrets, API credentials, WooCommerce webhook URLs, and payment gateway modes for staging and production. Confirm that staging never points at production Open edX, and that test payments cannot enroll real learners. Keep a record of which environment each credential belongs to, and check it during release sign-off.
Logging and alerting on failed enrollments
Record every enrollment attempt with its order reference, course identifier, result, and timestamp, so that a paid order without a matching enrollment can be found and corrected. Alert on repeated failures and on spikes in rejected signatures. Agree who receives the alert and what the first response is before launch.
Keeping PII out of logs
Logs from the webhook, the plugin, and WordPress often capture full request bodies, which include names, email addresses, and billing details. Redact or hash personal fields before they are written, and set retention limits on log stores. Ask your privacy lead which fields count as personal data in your jurisdiction and test a sample log entry before go-live.
Hardening the WordPress install
Limit administrator accounts, enforce strong authentication for them, and keep an inventory of every active plugin with its owner and update source. Remove unused plugins and themes. Schedule backups of the database and uploads, and test restoring them, since the order-to-enrollment mapping lives in that data.
Payment card data stays with the processor
Configure WooCommerce so that card numbers are entered on the processor's hosted fields or redirect pages and never reach your WordPress server or Open edX. This reduces what your environment handles, but it does not settle your obligations. Confirm your PCI DSS scope with your assessor, including which systems touch card data, rather than assuming the processor covers you.
Common failures when WooCommerce orders do not become Open edX enrollments
This table lists the failures teams most often meet between a paid WooCommerce order and an Open edX enrollment, with the likely cause and a check to run for each. Use it as a starting point, since the actual cause depends on how your commerce plugin, webhook receiver and course keys are configured. The main takeaway is that most failures trace back to delivery, identity matching or version drift, and each can be tested in staging before learners are affected.
| Failure | Likely cause | Check or fix to run |
|---|---|---|
| Order is paid but no enrollment appears | Webhook not delivered, secret mismatch, or product course ID differs from the Open edX course key | Check the WooCommerce webhook delivery log, compare the shared secret on both sides, and match the course key in Studio |
| Duplicate enrollments | Webhook retried after a slow or timed-out response, and the receiver enrolls on every delivery | Confirm the receiver records each order ID and skips repeats, then send one test order twice and count enrollments |
| Learners created with different emails | Checkout email differs from the learner's Open edX account email, or the account is matched on a changed address | Compare billing email, account email and LMS record for a sample order, and decide which field is the match key |
| Refunds not reflected | Refund completes in WooCommerce, but no event reaches the LMS to unenroll or mark the order as refunded | Trigger a test refund on a sandbox order and confirm the enrollment state changes, then document the policy for completed courses |
| Plugin incompatibility after an Open edX or WordPress upgrade | Commerce plugin or webhook receiver built against an older Open edX release or WordPress version | Before upgrading either side, test plugin versions against the target release in staging and read the vendor's compatibility notes |
| Checkout broken after a WordPress plugin auto-update | Auto-updates enabled for the commerce plugin or a checkout dependency, pulling in a version not tested with the receiver | Review which plugins auto-update, pin commerce plugins to tested versions, and run a test checkout after every update window |
Questions buyers ask about Open edX with WordPress and WooCommerce
What drives the cost of Open edX with WordPress and WooCommerce?
The main cost drivers are the scope of the chosen method, the number of products and course runs, any custom mapping between WooCommerce products and Open edX course runs, the depth of testing, and the hosting and upgrade plan. A single course with one enrollment path is a much smaller piece of work than a catalog with many products, several course runs per product, and refund or enrollment rules that differ by buyer type. Custom mapping adds effort because each product must resolve to the correct course identifier and enrollment mode. Testing depth matters because every purchase path, refund and failed payment needs checking on staging before launch. Hosting and upgrade plans add recurring cost. Ask for a quote built from a written scope that lists each of these items separately.
Is the cost of WordPress and WooCommerce with Open edX a one-time or recurring expense?
Both, and the split matters for budgeting. The initial build, which covers configuration, mapping, integration and testing, is one-time work. Recurring costs include hosting for WordPress and the Open edX platform, plugin and theme updates, WordPress core updates, and Open edX upgrades when you move to a later named release. Open edX supports only the latest named release, so upgrades recur as a planned activity. WordPress officially supports only its latest version as well. Ask any partner or vendor to separate one-time build work from each recurring line in the quote so you can see what continues after launch.
How long does a course sales build on Open edX and WooCommerce take?
Duration depends on the written scope, so no general figure applies. The main factors are how many products and course runs need configuring, whether custom mapping is required, how many environments must be built and tested, and how many external parties such as identity, payment and accounting teams must be coordinated. A narrow scope with one course and standard enrollment flows takes far less time than a catalog with many products, refund rules and custom reporting. Your timeline should come from the written scope, which should list milestones, staging sign-off and the release targeted. Ask about dependencies, especially access to accounts and course identifiers, because delays usually come from waiting on those inputs more than from the build itself.
What do we need to provide before an Open edX commerce build starts?
Plan to supply access and decisions before work begins. You need accounts for the Open edX environment, WordPress, WooCommerce and any payment gateway, with roles that let the implementer configure them and test on staging. Provide the course identifiers for every course run you plan to sell, and confirm which product maps to which run. Decide your refund policy and who handles refund requests, because the code path depends on it. Decide who owns learner and buyer data, including what each system stores and for how long. Finally, name test buyers who can run full purchase, enrollment and refund paths on staging before launch.
Can an internal team set up Open edX course sales without outside help?
Yes, if the team has working knowledge of both Open edX and WordPress and a staging environment to test in. Open edX work covers the LMS, course runs and enrollment, while WooCommerce work covers products, orders, payment gateways and the connector between the two systems. Your team also needs to handle upgrades to new Open edX releases and WordPress updates, since both can affect the connection. Without a staging copy of both systems, changes reach learners and buyers directly, which is the main risk. Consider outside help if no one on the team has run Open edX in production, if the catalog is large, or if your release calendar leaves little room for testing. A written scope helps you compare the work with your own capacity.
Should we use the Open edX Commerce plugin or the Webhook Receiver?
Choose between them after confirming which option supports your target release and the purchase flow you need, because the two approaches connect WooCommerce to Open edX in different ways. Verify the current feature set, supported versions and maintenance status of each in the official documentation before deciding. Questions to answer include how each handles enrollment after payment, how it maps products to course runs, what happens when a refund is issued, and what you must operate yourself, such as an endpoint, credentials or logs. The legacy e-commerce service is deprecated, so plan new work around the current options instead. Document the decision, because it shapes testing, upgrades and who supports the integration later.
How do WordPress and plugin updates affect a connected Open edX store?
Each WordPress update, plugin update or theme change can alter the code path that sends orders into Open edX, so every update needs a test on staging first. WordPress officially supports only the latest version. Automatic background updates for plugins apply by default only in special cases chosen through the WordPress.org API, so a plugin that handles enrollment may not update itself. Plan a schedule that checks the WooCommerce version, the commerce connector and the platform requirements. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. Keep backups before each change and write a rollback plan.
What should a quote for Open edX with WooCommerce include?
A quote should follow from a written scope that names the method, products, course runs and integrations in scope. List each environment to be built, such as development, staging and production, and state who hosts each one. Name the Open edX release targeted, since the connector and upgrade work depend on it. The current named release is Verawood, so confirm whether you target it or a later release. Include the testing depth, the purchase, enrollment, refund and failed-payment paths to be tested, and the test buyers involved. Separate one-time build work from recurring hosting, plugin updates and Open edX upgrades. DeployOpen does not publish a price list, so the quote follows from this written scope.
How DeployOpen works on this
DeployOpen starts with a written scope that sets out which Open edX commerce path, WordPress role and WooCommerce product rules apply in your environment. We then build, test and document the integration inside infrastructure you control, and offer ongoing support as a retainer.
How we scope
- Confirm whether the storefront uses the Open edX Commerce plugin or the Webhook Receiver, given the legacy e-commerce service is deprecated.
- Map which course products, prices, enrollment outcomes and refund cases WooCommerce must represent and which system owns each one.
- Agree in writing the hosting boundaries, identity links, data flows and the WordPress and Open edX versions the integration targets.
How we build
- Configure the WordPress marketing site and WooCommerce checkout in your environment, with the Open edX side wired through the chosen commerce path.
- Test enrollment, payment and failure flows end to end in a staging environment that mirrors production before any live orders are taken.
- Harden WordPress and WooCommerce with a planned update policy, since the WordPress Security Team supports only the latest release.
How we hand over
- Deliver written documentation covering configuration, data flows, credentials handling, test cases and the rollback steps for each component.
- Walk your platform, WordPress and commerce owners through operations, including how plugin and core updates are reviewed and applied.
- Record open decisions and the items you must confirm with each vendor, so your team can run the integration after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, with the scope and response expectations agreed in writing.
- Plan upgrades of WordPress, WooCommerce and Open edX together, because a change in one can affect checkout or enrollment in another.
- Review plugin and integration changes against the test cases from build, so regressions are caught before they reach learners and buyers.
