Selling online courses from a self-hosted platform: why payments change the build
If you must take payment for courses on infrastructure you control, the first decision is which path you are taking. Moodle's Enrolment on payment method with PayPal included as a standard gateway is the simplest paid route, because the enrolment, the payment and the course access sit inside one platform. Open edX and storefronts such as WooCommerce need more integration work: you choose a gateway, connect it to the learner account or order flow, reconcile payments with enrolments, and test refunds and failed charges end to end before launch. Treat that integration as scope in its own right, not as a checkout widget added at the end.
Taking payment changes more than the checkout page. It changes where learner data, order records, invoices and refund histories are kept, who can read them, how long they are retained and how you evidence all of that to an auditor. It also changes your PCI DSS scope. The key distinction is whether the payment provider hosts the card fields and collects card data directly from the learner's browser, so your servers only receive a token or a payment reference, or whether card data passes through your own servers. The first pattern keeps your environment much further out of scope. The second brings most of your infrastructure, logging and staff access into assessment. Confirm with your acquirer and a qualified assessor which pattern your design uses before you choose a gateway.
Moodle documentation states that other payment gateways come from the plugins directory and are used at the site's own risk. Before installing any third-party gateway, check its maintainer, its update history against your Moodle version, whether it stores or forwards card data, and who will patch it after launch. Name the owner of each gateway plugin in your operating model, and ask any implementation partner to show how gateway updates are tested on a staging copy of your site before they reach production.
Which requirements a paid course platform must meet
This table compares the requirements a paid course platform must meet, the source behind each one, and what it changes in the build. Read each row as a decision point: confirm the requirement early, because payment handling, tax rules and accessibility deadlines shape hosting, theming and the supplier contract. Tax and invoicing rules vary by jurisdiction, so confirm them with your own tax and legal advisers.
| Requirement | What it asks for | Source and build impact |
|---|---|---|
| Payment gateway and card data handling | Choose a gateway for Enrolment on payment, and decide whether card data touches your servers or stays with the provider | Moodle documentation includes PayPal as standard and treats other gateways from the plugins directory as the site's own risk. PCI DSS, referred to by title, sets the scope: redirect or hosted fields usually reduce it, while handling raw card data widens it |
| Storefront connection | If a WooCommerce or other storefront sells access, the sale and the Moodle enrolment must stay in sync | Confirm the connector, its maintenance status and how failed payments return to the LMS. Test refunds and cancellations end to end before launch |
| Tax and invoicing | Calculate tax by buyer location, issue compliant invoices and keep records for the period your advisers specify | Not supplied as a fact here. Confirm rules with your tax and legal advisers, then check whether the gateway, storefront or a plugin can produce the required invoice fields |
| Coupons and discounts | Support promo codes, group pricing and limited-use offers without granting access outside the rules | Confirm whether the gateway, storefront or LMS enforces usage limits, expiry and stacking rules. Test each discount type against enrolment records |
| Refunds and cancellations | Define when a learner can refund, and whether access is revoked, kept or partly kept after refund | Set the policy before build. The payment record, the enrolment status and the invoice must all reflect the same outcome |
| Learner access tied to purchase | Grant access on payment confirmation and remove or limit it when the purchase is reversed or expires | Moodle's Enrolment on payment method is the core mechanism. Test duration-based access, cohort dates and manual enrolment overrides |
| Platform upgrade cadence | Keep the LMS and payment plugins on supported versions, since plugin gateways may lag core releases | Moodle 5.3 has security support until 1 October 2029 and is the next LTS. Moodle 5.1 security support ends 19 April 2027, so plan the move from that version. Confirm plugin compatibility before each upgrade |
| Accessibility for government customers | Meet WCAG 2.1 Level AA for web content and mobile apps where the ADA Title II rule applies to state and local government | The ADA.gov rule sets compliance dates of 26 April 2027 for entities with 50,000 or more people and 26 April 2028 for smaller entities and special districts. Checkout pages and course content both fall in scope, so test them |
Which platforms fit paid courses and why
Paid course sales on a self-hosted platform usually start with the learning platform itself, then add a storefront or gateway that handles money. The cards below separate the options by who owns checkout, how far the catalog logic goes, and which licence and supported release line you would be building on.
Moodle with enrolment on payment
Moodle includes PayPal as a standard payment gateway, and paid access is set up through the Enrolment on payment method, so a course can be sold without adding a storefront. Moodle's code is GPL-3.0, and Moodle 5.3 is the current LTS release with security support until 1 October 2029. Confirm the PayPal account terms, fees and tax handling with PayPal and your finance team before launch. Moodle 5.3 requires PHP 8.3 or later and PostgreSQL 17, MySQL 8.4, MariaDB 11.4 or SQL Server 2019, and upgrades must start from Moodle 4.4 or later.
Moodle with plugin payment gateways
Gateways beyond PayPal come from the Moodle plugins directory, and Moodle's documentation says you run them at your own risk. This route suits teams that need a local processor, regional payment methods or a different fee structure. Each plugin is a separate supply chain item, so check its maintenance status, its compatibility with your exact Moodle version and whether its vendor has confirmed the integration. Payment handling changes your PCI DSS scope, so ask any gateway vendor for its responsibility matrix before selecting it.
Open edX with a commerce integration
Open edX is licensed under AGPL-3.0 and is built for large course catalogs, with Studio for authoring and the LMS for learners. Selling courses requires an ecommerce integration layer added to the platform, which means more custom configuration than Moodle's built-in enrolment on payment. Open edX states that only the latest named release is supported, and Verawood is the current release. Tutor, the official Docker-based distribution, is the usual production route, and the maintainers recommend a service provider or Tutor over bare-metal installs. Confirm the commerce connector and its supported version with its maintainers before committing.
WooCommerce storefront connected to the LMS
WooCommerce is GPL v2 or later and can sell access to courses on a WordPress storefront while the learning content stays on Moodle or Open edX. The storefront then sends an enrolment or access request to the LMS, which must be built and tested. WooCommerce 11.2.1 was published on October 9, 2026, and it recommends PHP 8.3 or greater, MySQL 8.0 or MariaDB 10.6 or later, and HTTPS. Its REST API under the wc/v3 namespace is a common integration point, but the LMS connector is custom or vendor-supplied, so confirm it with that vendor. Keep order data on High-Performance Order Storage tables and budget for testing of tax, refunds and coupon rules.
Dedicated ecommerce platform for complex catalogs
When bundles, subscriptions, multi-currency pricing, memberships or complex tax rules outgrow the LMS, a dedicated commerce platform can own the catalog and checkout while the LMS handles delivery. Options include Magento Open Source (OSL-3.0), Saleor (BSD-3-Clause), Medusa (MIT, with an Enterprise Edition license for some materials) and Sylius (MIT). The trade-off is a second system to host, secure and keep in sync with enrolments, refunds and access revocation. Define which system is the source of truth for purchases before design starts. Confirm each connector with the platform's maintainers, since none of these is supplied here as a ready-made LMS integration.
How card payments reach the platform: three paths and their PCI DSS scope
In a hosted payment page redirect, the learner leaves the course site or storefront, enters card details on a page run by the payment provider, and returns with a result. The platform never receives the card number, so storing, processing and transmitting card data sits mainly with the provider. Moodle's payment gateways documentation explains how gateways connect to the Enrolment on payment method, but confirm each gateway's exact redirect and return flow for your version.
- Who handles card data: The provider's page collects and stores card details. Your platform receives a payment result and a transaction reference.
- Scope effect: This is usually the smallest in-house footprint because the course site stays out of the card data path. The redirect and return pages still run in your environment and must be kept under change control.
- What the platform stores: The order record, the enrolment linked to that order, the transaction ID and status, and the invoice data needed for tax and refunds.
- Failure handling: Plan for learners who abandon the redirect or return with a pending status, so enrolments are neither granted by mistake nor lost.
- Gateway choice: Non-core gateways come from the plugins directory and run at the site's own risk. Confirm the plugin is maintained for your Moodle version before committing.
Ask a qualified assessor whether your redirect and return flow keeps the course site outside card data scope in your setup.
With gateway JavaScript tokenization, the payment form sits inside the course site or storefront, but the card fields are rendered by the provider's script within elements the provider hosts. The script returns a token, a stand-in for the card, and your server charges with that token. Card numbers are meant to bypass your servers, but the page that loads the script is still your code, so its templates, themes and third-party scripts still shape the risk.
- Who handles card data: The provider's script and hosted fields capture card data. Your server only handles tokens and references.
- Scope effect: This can reduce what your servers touch, but the checkout page, its theme, and every script it loads stay in scope and are a common source of change risk.
- Script control: Limit which scripts load on checkout pages, including theme and plugin scripts, and review them after every platform or plugin upgrade.
- What the platform stores: The order, enrolment, invoice and the provider's token or transaction reference. The full card number and sensitive authentication data should never be stored.
- Integration method: Gateway modules and storefront payment extensions implement tokenization differently, so request the integration method and data flow in writing before you select one.
Ask your assessor to review the checkout page, every script it loads and the theme that renders it before deciding whether this path reduces scope for your setup.
In this path, the card number is typed into a form your platform renders and is sent to your own application or payment service before it reaches the provider. It gives the most control over the flow and the data, but it also brings the widest scope, because every system that receives, processes, stores or transmits card data is generally in scope. It is seldom needed for course sales and should be chosen only with a clear business reason and assessed controls.
- Who handles card data: Your application, its hosts and the people who administer them, plus the provider once data leaves your servers.
- Scope effect: This is the broadest. Application servers, databases, logs, backups, administrative access and the network segments connecting them are generally brought into scope.
- Logging restrictions: Card numbers and sensitive authentication data must not appear in Moodle or Open edX logs, WooCommerce order notes, database dumps, error reports or debug output.
- What the platform stores: The order, enrolment, invoice and a transaction reference. Any retained card data must be justified, protected and minimized.
- Ongoing evidence: Expect continuing work on access reviews, patch records, vulnerability management and change control for payment code, all of which assessors will ask to see.
Before choosing this path, ask a qualified assessor to list every system in scope and to confirm whether a tokenized path would meet the business need with less exposure.
Connecting a WooCommerce storefront to course access
A WordPress storefront belongs in front of the learning platform only when you sell from a brand site or a catalog that WordPress already runs. In that design, WooCommerce takes the order, collects payment through a gateway, and hands a paid order to Moodle or Open edX, which then creates the enrolment. Four things must stay in step between the two systems: orders, enrolments, refunds and tax lines. If a refund is issued in WooCommerce but the learner keeps access in the LMS, or a tax line on the invoice does not match the price charged in the course, you have a reconciliation problem that no one notices until a customer complains. Before you build, decide which system is the system of record for each of the four, and write that down. WooCommerce is licensed under GPL version 2 or later, so the plugin itself carries no license fee, but the connector between WooCommerce and your LMS is custom or third-party work that you will need to license, build and maintain.
Plan the platform baseline first. WooCommerce 11.2.1 was published on October 9, 2026, and its server requirements recommend PHP 8.3 or greater, MySQL 8.0 or later (or MariaDB 10.6 or later), a WordPress memory limit of 256 MB or more, and HTTPS. Legacy environments may still run PHP 7.4 or MySQL 5.6, but both are end of life and should not carry payments. Confirm these versions with your hosting team before the storefront is provisioned. On new installations, High-Performance Order Storage is enabled by default and keeps orders in dedicated tables such as wc_orders and wc_orders_meta. Ask your integration partner whether the connector reads orders through the WooCommerce REST API under the wc/v3 namespace, which authenticates over HTTPS with API keys or OAuth 1.0a, and whether it uses the same tables or the API. Those choices determine how the connector behaves during upgrades.
Treat the storefront as part of your payment scope. Once WordPress receives card details or redirects a learner to a payment page, its hosting, plugins, theme and administrator accounts become part of the environment assessed against PCI DSS, so keep the number of plugins small and patched, restrict who can reach WooCommerce administration, and log changes to payment settings. Confirm with your acquirer or qualified assessor which integration model you use, because a hosted payment page and an embedded form put very different duties on the storefront. Also confirm how the connector authenticates to the LMS, how it stores the API credentials, and how a failed enrolment is retried and reported. A test plan should cover a paid order, a partial refund, a coupon, a tax-exempt buyer and a learner who buys the same course twice.
Rollout from test payments to first paid cohort
This sequence moves a paid course offer from agreed payment and tax rules to a controlled first cohort, with each phase producing a signed-off artifact before the next one starts. It keeps finance, counsel, security and the platform team working from the same record.
Confirm the payment and tax model
Finance and counsel agree in writing who sells the course, which entity collects payment, how sales tax or VAT applies to each learner location, what invoices must show, and how refunds are booked. The platform team attends to confirm what the LMS can record. The output is a one-page payment and tax model that names the merchant of record and lists every product, price and currency in scope.
Select the gateway and storefront path
The team chooses between Moodle's Enrolment on payment method with PayPal, which is included in core, and a plugin gateway from the plugins directory, which the site owner must assess and support at its own risk. If a WooCommerce storefront sits in front of the course site, the team confirms the integration method and the WooCommerce version it will run. The output is a short decision record that names the gateway, the storefront and the owner of each plugin update.
Configure sandbox payments and enrolment
Engineers connect the chosen gateway to its sandbox or test environment, create a paid course and configure the Enrolment on payment method with price, currency and enrolment duration. They run test purchases with several test accounts and confirm that access is granted only after payment succeeds and is revoked as configured. The output is a test log that records each scenario, its result and the defect ticket for any failure.
Test refunds, coupons and invoice numbering
QA and finance staff run full and partial refunds, check how access changes after a refund, apply coupons with usage limits and expiry dates, and confirm that invoice numbers are sequential with no gaps across test runs and retries. They also check that the tax lines on each invoice match the model from the first step. The output is a signed reconciliation sheet that finance accepts before any live transaction is enabled.
Review the card data path for PCI DSS scope
Security staff map every system that receives, stores, transmits or could affect card data, including the course site, the storefront, plugins, logs and backups. The team confirms whether the gateway hosts the card entry page so that card data never touches the platform servers, and documents the result as the basis for the PCI DSS scope decision with the acquirer or assessor. The output is a scope diagram, a list of in-scope components and the evidence of the review, reviewed before go-live.
Confirm the upgrade calendar before launch
The platform owner records the running Moodle or Open edX release and compares it with the published support dates. For Moodle, Moodle 5.3 has security support until 1 October 2029, while Moodle 5.1 has security support until 19 April 2027. For Open edX, only the latest named release is supported, and Verawood is the current release with Willow planned for December 2026. The output is a dated upgrade calendar with an owner and a test window for each release change.
Run a staged launch to a small cohort
The team opens enrolment to a limited, named group of learners with live payments, watches the order, enrolment and invoice records daily, and checks support tickets for payment failures. Only after this cohort completes its first purchase cycle, with no unexplained access or billing errors, does the team widen sales. The output is a launch review with the defects found, the fixes made and a go or no-go decision for general sales.
Evidence a payments auditor or finance team will ask for
This table lists the evidence a payments assessor or finance team typically requests for a paid course sale, the component that produces each item, and who prepares it. Read it as a checklist to agree on before launch, since missing records are harder to recreate later. DeployOpen prepares systems, controls and evidence for assessment, but auditors and certification bodies issue the opinions and attestations.
| Evidence item | Produced by | What the reviewer checks |
|---|---|---|
| Gateway configuration and contracts | Moodle payment gateway settings, PayPal or plugin gateway agreements | Which gateway handles card entry, merchant agreements in force, and who holds the account |
| Network diagram of the card data path | Architecture documentation maintained by DeployOpen and your team | Whether card data touches the Moodle server, the storefront or only the provider's hosted pages |
| PCI DSS scope statement | Written scope document reviewed with your assessor | Which systems store, process or transmit account data and which are out of scope |
| Change records for plugins and storefront updates | Version control, change tickets and staging test notes | Who approved each plugin or WooCommerce update and whether it was tested before production |
| Order-to-enrolment reconciliation logs | Moodle enrolment on payment records matched against gateway transaction reports | That every paid order produced exactly one enrolment and every transaction has a matching order |
| Invoice and tax records | Moodle or storefront invoicing, tax configuration and accounting export | Tax rates applied by location, invoice numbering continuity and totals matching the ledger |
| Refund audit trail | Gateway refund records linked to Moodle enrolment suspension or removal | Who authorized each refund, when access ended and that the amount matches the original payment |
| Patch and version records against supported releases | Upgrade logs for Moodle, PHP, the database and WooCommerce | Running a Moodle release with active security support, and dated patch history for each component |
What buyers ask before selling courses on their own platform
How much does it cost to sell courses on a self-hosted Moodle platform?
The cost is set by who is paid for what, not by a list price. Expect separate line items for platform setup, hosting and operations, payment and storefront configuration, theming, tax and invoicing rules, and ongoing upgrades. Setup is largely one-time work, while hosting, payment gateway fees, plugin licences and upgrade work recur every year. Costs rise with the number of payment gateways, the number of storefront integrations and the volume of courses and learners. Ask every partner for a written scope that lists each of these items separately, with the assumptions behind them, so you can compare quotes on the same basis. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that scope.
How long does it take to set up paid course enrolment?
Duration depends on how much of the commerce chain is new work. A Moodle site that only needs the PayPal gateway in core, with enrolment on payment configured for a few courses, is a much smaller job than a site that must connect a WooCommerce storefront, add tax rules, issue invoices and pass a payment security review. The main drivers are the number of courses and price points, the storefront you already run, your tax and invoicing rules, the review cycle for payment controls, and whether the team can supply test accounts and sign-off in time. Ask the partner for a timeline tied to written milestones, and confirm which items depend on your finance, legal and security teams.
What must our finance, tax, legal and integration teams supply?
Most delays come from missing decisions rather than missing software. Finance must define price books, currencies, refund rules and who approves manual adjustments. Tax owners must confirm which tax rates, exemptions and invoice fields apply to each buyer location. Legal must review terms of sale, refund wording, consumer rights notices and data processing terms with your payment provider. An integration owner, usually someone in engineering or platform operations, must own the Moodle upgrade path, the storefront connection, credentials and monitoring. Name these owners before the scope is signed, because the partner cannot make these decisions for you.
Can our own team configure the Moodle PayPal gateway?
Often yes, for a small catalogue with simple prices. Moodle documentation states that PayPal is included as standard among its payment gateways, and payment gateways are used with the Enrolment on payment method when learners purchase access to a course. Configuration still needs a PayPal business account, correct credentials, a tested purchase flow, and a rule for how refunds and failed payments are handled. Your team should confirm whether it has the skills to test that flow end to end and to maintain it after each Moodle upgrade. If the team cannot do this in-house, a fixed-scope engagement can cover configuration, testing and handover.
How are coupons and invoices handled when selling courses?
Coupons and invoices depend on where the sale is recorded. In a Moodle enrolment on payment flow, discount logic and invoice output must be checked against your tax and accounting rules, because a gateway purchase may not produce the invoice format your finance team needs. In a WooCommerce storefront, coupons and order records sit in the commerce layer, and WooCommerce stores orders in dedicated tables when High-Performance Order Storage is enabled, which affects how reports and exports are built. Ask the partner to show how a discounted, taxed purchase appears in the learner record, the order record and the accounting export.
What changes when the payment gateway is a plugin from the directory?
A directory plugin changes who owns the risk. Moodle documentation states that other gateways come from the plugins directory at the site's own risk, so the code, its support status and its compatibility with each Moodle release become your responsibility. Before approving one, confirm its maintenance history, its compatibility with your Moodle version and its handling of card data. Plan for testing after every core upgrade, because a plugin that works on one release can break on the next. Your payment and security review should also state whether the plugin ever receives card details, since that determines how much of your environment falls within PCI DSS scope.
Does handling payments change our PCI DSS scope?
Yes, the way payments are handled determines how much of your environment falls within PCI DSS scope. A gateway that redirects buyers to a hosted payment page usually keeps card data off your servers, which narrows the scope. A plugin or custom form that receives card numbers brings the Moodle server, its database, its logs and its administrators into scope. Ask your payment provider and assessor to confirm the integration pattern in writing before build starts. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations, and an independent assessor must make the scope determination.
Questions to ask a partner before paid enrolment goes live
Start with the merchant contract, because it decides almost everything else. Ask the partner which payment gateway they propose for Moodle's Enrolment on payment method, who signs the merchant agreement (your organization or the partner), and whose name appears on the payout account and chargeback notices. Moodle documentation states that PayPal is included as standard, while other gateways come from the plugins directory and are used at the site's own risk, so ask who will own the plugin's maintenance and vulnerability response. Ask for a written answer on card data: does the browser post card details directly to the gateway's hosted page, or does any Moodle or WooCommerce code receive them? That single answer determines how much of your environment falls within PCI DSS scope, and it should be confirmed with your acquiring bank and a qualified assessor before build starts.
Next, test the commerce path, not just the checkout. Ask how orders are reconciled with enrolments: which event creates the enrolment, what happens when a payment is pending, failed, refunded or disputed, and whether a WooCommerce order, if one is used as the storefront, is linked to the Moodle user and course through a stored identifier. Ask how the partner vets directory plugins before installation, including the source of the code, the release history, the last security fix, and whether the plugin has been tested against the Moodle version you will run. Ask which version they target. Moodle 5.3 is the current long-term support release with security fixes until October 1, 2029, and requires PHP 8.3 or later and PostgreSQL 17, while Moodle 5.1 has security support until April 19, 2027. For Open edX, ask how they will handle Verawood, since the project supports only its latest named release and Willow is listed for December 2026. Finally, ask who processes refunds, who applies tax and invoice changes, who runs each upgrade after launch, and what it costs to keep the payment plugin current, all in writing and in the fixed scope.
