Moodle paid enrolment with PayPal and Stripe

The enrolment only happens after the gateway confirms payment, so the order of steps matters when you test and support a paid course. A learner selects a paid course and sees the fee set on the course's enrolment on payment method. When they continue, Moodle creates a payment record and hands the order to the gateway the course is configured to use. The learner completes payment on the provider's side. The gateway reports the outcome back to Moodle, and Moodle records the payment and enrols the user with the role and duration set on that enrolment instance. For each gateway, run one test order and check all three results: the payment record, the enrolment and the assigned role.

The core PayPal gateway ships with Moodle, so it needs no extra plugin and is the simplest baseline to test first. The community Stripe gateway is a separate plugin, paygw_stripe, maintained by Alex Morris. You install it, configure it and keep it current with each Moodle upgrade. Its plugin directory listing says it supports Moodle 4.1 to 5.3 and describes collecting payments through providers such as credit cards, Alipay and Sofort. Those are options the Stripe connection can offer, so the plugin's compatibility with your Moodle version is a check you make before you choose it, not a detail to resolve after go-live. Confirm both gateways' current status with your Moodle version before you commit to either.

Before you promise any payment method on a course page, confirm that your gateway account actually accepts it. Check the provider's documentation, then check your own Stripe or PayPal account for the country you operate in and the currency you charge. A plugin listing describes what the connector can offer, not what your account will accept at checkout. Test every method you plan to advertise, using the provider's sandbox or a low-value live order where that is allowed, and record which methods appeared. Ask the team writing learner-facing copy to name only the methods you have confirmed. Also record who holds the gateway credentials in Moodle and who can change them.

Plan two failure paths before go-live. The first is a payment that completes at the provider but does not return the learner to Moodle, because the browser closes or the connection drops. Confirm with your chosen gateway and Moodle version how a confirmed payment is matched to an enrolment in that case, and test it with a deliberately interrupted order. The second is an upgrade that changes Moodle's version while the community plugin lags behind. Schedule a check of plugin compatibility before each Moodle upgrade, and keep a test order in your release checklist so that a broken payment path is found in staging, not by a learner.

Moodle and the payment gateway collect the money, but neither decides how a sale is taxed. Before go-live, settle the tax questions with your organization's tax adviser and write the answers down. The first question is whether the prices you enter in the course enrolment settings include tax or exclude it, because that changes what the learner pays and what you must report. The second is which rate applies by learner location. A learner's country, and sometimes their status as a business or consumer, may change the rate or whether you must register in that jurisdiction at all. Ask the adviser to confirm the currency you charge in and how amounts are converted, since the gateway and Moodle may each record a different figure.

Next, decide who issues invoices and receipts. The options are Moodle, the gateway's own receipt, or a document produced by your accounting system. A gateway receipt is usually a proof of payment, not necessarily a tax invoice, so confirm what the adviser requires on the document, including tax shown separately and sequential numbering. Then agree how the sale is recorded in accounting: which ledger accounts receive the revenue and tax, how gateway fees and payouts are reconciled against Moodle enrolments, and how refunds and disputes appear in the books. Ask your accountant to trace one test purchase from the learner's checkout through to the ledger entry.

Refunds need the most careful planning. A refund issued in PayPal or Stripe does not automatically remove the Moodle enrolment, so a learner may keep course access after the money has gone back. Write down the revocation process before launch: who approves a refund, who removes or suspends the enrolment, whether that happens by hand or through an automated step, and what happens to grades, completion records and certificates. Also define how chargebacks and disputes are handled, since they reverse a payment without a refund request from the learner. Name an owner for each step so no one assumes another team has done it.

Test the whole path in a non-production environment before taking real payments. Run a purchase, a full refund and a simulated dispute, then check the enrolment status, the payment record in Moodle, the gateway record and the accounting entry for each. Confirm the refund and cancellation behavior of the chosen gateway and enrolment method in the exact Moodle version you run, because gateway plugins and provider APIs change over time. For example, the community Stripe gateway plugin lists support for Moodle 4.1 to 5.3 in the Moodle plugins directory, so check that range against your version and record the result as part of your go-live sign-off.

Test the full payment path before any learner sees the course for sale. A paid enrolment touches three records that can disagree: the payment record in the gateway, the payment record in Moodle, and the user's course access. Each test case below should check all three, because a purchase that succeeds at the gateway but never creates an enrolment is as much a defect as a free enrolment granted after a failed charge. Start by confirming which mode each gateway offers for testing. PayPal and Stripe both document sandbox or test environments, but the test card numbers, test account behavior, webhook or IPN delivery in test mode, and refund simulation differ, so take them from each gateway's own documentation and confirm them against your account before the first run. Run a successful purchase first, using a test account with no existing enrolment. Confirm the gateway shows a completed payment with the expected amount and currency, that Moodle's payment record is marked as paid and linked to the right course and user, and that the enrolment appears with the start and end dates configured for the paid course. Then run a failed payment and a cancelled checkout. Each should leave no active enrolment and no paid record, and the learner should see the course as still available for purchase. Run a duplicate attempt by submitting a second purchase for the same course while the first is pending, then again after it completes. Check that a learner is not charged twice for access they already hold and that Moodle does not create a second enrolment. Next, test a currency or price change. Change the course price or the currency in Moodle after one purchase has been made, then confirm that the earlier payment keeps its original amount and currency in both systems and that a new purchase uses the new values. Then issue a refund from the gateway dashboard and check whether the refund reaches Moodle. This depends on how the gateway plugin handles refund notifications, so confirm that behavior in the plugin documentation before you rely on it. If Moodle does not update automatically, record the manual step your operations team must take to revoke access. Finally, test the enrolment end date. Set a short test duration on a paid enrolment, let it expire or advance the test clock where your environment allows, and confirm that course access is removed at the configured end date and that the payment record remains intact for reporting. Keep a written test log that records the gateway transaction ID, Moodle payment ID, enrolment ID, and the observed access state for each case. Ask your gateway partner or internal reviewer to sign off that finance and support can trace any learner's payment through all three records.