Developer platform

Build on the commerce layer already inside Moodle.

Extend catalogue, order, enrolment, subscription, and storefront workflows without operating a separate bridge. ModernCommerce follows Moodle's native component, capability, event, task, privacy, and external-function conventions.

Start locally Read the architecture

Current source contract: ModernCommerce 2.1.6 · Moodle 5.2 · PHP 8.3+

db/events.phpyour add-on

<?php

$observers = [
    [
        'eventname' =>
            '\local_moderncommerce\event\order_paid',
        'callback' =>
            '\local_yourplugin\observer::order_paid',
    ],
];

React to a domain event. Keep order and entitlement writes inside ModernCommerce services.

156external functions

12domain event classes

17scheduled tasks

36Moodle capabilities

81database tables

Audited directly from db/services.php, classes/event, db/tasks.php, db/access.php, and db/install.xml in release 2.1.6.

Choose a starting point

Go from evaluation to a tested extension.

Each path leads to the detailed, source-audited documentation rather than duplicating contracts on a marketing page.

Install safely

Confirm Moodle and PHP requirements, install Composer dependencies, upgrade Moodle, and verify cron.

Installation guide →

Understand ownership

Learn which records belong to Moodle and which belong to catalogue, transaction, access, and engagement services.

Architecture guide →

Integrate by contract

Use capability-checked external functions and domain events instead of bypassing business rules with table writes.

Services and events →

Operate and verify

Seed development data, run audits, validate documentation and strings, and exercise Moodle cron.

CLI reference →

System boundary

One Moodle application. Clear ownership.

ModernCommerce adds commercial state without duplicating Moodle's learning records or identity system.

Explore the data model

Learning system

Moodle core

Users, courses, roles, contexts, enrolments, completion, grades, files, messaging, privacy, and cron.

Commerce domain

ModernCommerce

Products, prices, carts, orders, payments, invoices, entitlements, keys, subscriptions, storefront, and reporting.

External boundary

Merchant-owned providers

Stripe, PayPal, Paystack, and Flutterwave receive payment data and return callbacks or signed webhooks.

Transaction invariant

A gateway success screen is not fulfilment. Verified payment state, order transition, entitlement creation, and Moodle enrolment must agree.

Extension contracts

Extend the platform at stable boundaries.

Moodle recommends events for inter-plugin communication. ModernCommerce also exposes external functions, scheduled tasks, capability contracts, and optional add-on detection.

EVENTS

React to domain changes

Observe order_paid, order_status_changed, and subscription lifecycle events. Treat the installed release's event class as the payload authority and regression-test every upgrade.

Review all 12 events

FUNCTIONS

Use validated application services

The 156 declarations in db/services.php power shipped AJAX applications. They define read/write intent, login policy, and capability requirements; they are not an unauthenticated, general-purpose public REST API.

Review function groups

ADD-ONS

Keep optional components independent

An add-on should own its tables, configuration, services, tasks, privacy declarations, and business rules. Gate integrations when the component or required capability is absent.

Read the add-on contract

TASKS

Design for asynchronous work

Renewals, expiry, access synchronization, notifications, abandoned-cart recovery, and reports depend on Moodle cron. Production cron should run every minute.

Review scheduled work

Local workflow

Install, seed, exercise, verify.

Use a disposable Moodle environment and sandbox gateway accounts. Never seed or reset demonstration commerce data in production.

InstallMoodle 5.2, PHP 8.3+, HTTPS for live gateway work, and Composer dependencies.

InitializeRun Moodle upgrade, install safe defaults, and keep cron active.

ExerciseCreate a product, complete a sandbox purchase, and confirm order, payment, entitlement, enrolment, and invoice state.

ValidateRun project checks and test both the presence and absence of optional add-ons.

Moodle root

# Install the plugin dependencies
composer install --working-dir=local/moderncommerce

# Register the plugin and run background work
php admin/cli/upgrade.php --non-interactive
php admin/cli/cron.php

# Development or staging only
php local/moderncommerce/cli/demo_data.php --install-defaults
php local/moderncommerce/cli/demo_data.php --audit

# Source-quality checks
composer --working-dir=local/moderncommerce run mc:docs-check
composer --working-dir=local/moderncommerce run mc:string-audit
composer --working-dir=local/moderncommerce run mc:check-fast

Source map

Know which file answers the question.

Executable metadata outranks old README files or screenshots.

Source	Authority
`version.php`	Release, maturity, Moodle requirement, and supported Moodle branch.
`composer.json`	PHP requirement, package dependencies, autoloading, and project checks.
`db/services.php`	External-function classes, access intent, AJAX policy, and capabilities.
`db/access.php`	Capability definitions and role archetype defaults.
`db/events.php`	Internal event observers and their processing priority.
`db/tasks.php`	Scheduled task classes and default schedules.
`db/install.xml`	Install-time database schema, keys, indexes, and field types.
`lang/en/local_moderncommerce.php`	User-facing terminology and configuration help text.

Engineering guardrails

Protect payment and learner state.

Validate parameters, context, login state, and Moodle capabilities on every callable boundary.
Verify gateway signatures and record callbacks through the payment and webhook ledgers.
Use services or events; do not update order, payment, entitlement, or subscription tables directly.
Declare privacy metadata and external transfers for every add-on that stores personal data.
Test install, upgrade, cron, retries, and optional-component absence before production release.

Privacy and security Payment operations

Platform references

Built on Moodle's documented contracts.

Use ModernCommerce documentation for product-specific behavior and Moodle's versioned developer documentation for the underlying platform APIs.

Moodle 5.2 API guidesAccess, events, privacy, tasks, enrolment, files, and more →External function definitionsParameters, returns, validation, context, and capabilities →Scheduled tasksTask classes, declarations, schedules, cron, and debugging →

Start with a working transaction

Install it. Trace it. Then extend it.

Complete a sandbox purchase before designing an integration so you can see the order, payment, enrolment, invoice, and event lifecycle together.

Open the quick start Explore services and events