Who pays
The operator of a platform we host — a business or an individual educator with a signed agreement. Never a member of the public, and never a student.
Billing for the platforms we operate
Billing and card collection for hosted software platforms.
We invoice the operators of the platforms we host, and collect the fee by card on this domain.
- Currency
- LKR
- Card data held
- None
- Statement descriptor
- LMSPAY
lmspay.online/i/inv_2f7c9a41
Invoice 2026-10
Issued 1 October 2026 · due 8 November 2026
- Billed to
- Horizon Institute (Pvt) Ltd
- Description
- Platform fee — October 2026
- Period
- 2026-10
- Reference
- period_2026_10
- Amount due
- LKR 45,000.00
Pay LKR 45,000.00 by card
Card details are entered on our payment provider’s secure page and are never sent to LMS Pay. The charge appears on your statement as LMSPAY.
- Who is chargedOur contracted customers only
- Card detailsEntered on the gateway, never here
- What settles an invoiceA signed server-to-server callback
- NotificationsSigned, retried, and inspectable
An in-house service, not a marketplace
We build and operate learning management platforms. LMS Pay bills the operators of those platforms for their use of our software, and collects that fee by card. We are the merchant, and the only people charged here are our own contracted customers. We never process a payment on behalf of a third party, and there is no public checkout — an invoice exists only because we issued it to a named customer.
What we sell
A software fee, for a stated period, under a signed agreement
Each customer runs their own installation, on their own domain. What is charged here is the fee for that software — never anything a student buys.
What is charged
A software fee for a stated billing period, agreed in advance in writing. The amount, the period and the reference appear on the checkout page before payment.
What they receive
Continued operation of their platform for the period billed, plus a receipt and a paid invoice record they can retrieve at any time.
Who is on the other end
One named customer, invoiced by us
There is no public checkout. A payment page exists because we issued an invoice to a named customer.
- Not a marketplace and not a payment facilitator — we never process a payment on behalf of a third party.
- Students and members of the public are never charged here. They pay their own educator, inside that educator’s own platform, under a separate arrangement that does not touch this service.
- One currency, LKR. One fee type: a software fee for a stated billing period.
- Credentials are issued by us in the operator console. There is no self-service signup.
How a payment happens
Five steps, and only one of them can settle an invoice
The money moves because the gateway said so — in a message we verified, for an amount we checked against the invoice.
- 1
The platform requests an invoice
The customer’s platform reaches the end of a billing period and asks us for an invoice over an authenticated API, using its own period id as the reference.
- 2
We return a checkout link
The customer sees the amount, the period and the reference before anything is charged. Arriving at the page charges nothing.
- 3
The card is entered on the gateway’s page
Card details are entered on the payment provider’s hosted page. They never reach our servers, our logs or our database.
- 4
The gateway confirms, server to server
The provider tells us the result directly. Only that message marks the invoice paid — the customer’s return to this site does not.
- 5
The platform is notified, and can also ask
We send a signed notification to the customer’s platform, retried on failure and inspectable in our console. The platform can also poll the invoice, which is the authoritative answer.
lmspay.online/console/invoices
Invoices
Last 30 days| Platform | Reference | Amount | Status |
|---|---|---|---|
| Horizon Institute | period_2026_10 | LKR 45,000.00 | PAID |
| Lakmal Physics | period_2026_10 | LKR 22,500.00 | PAID |
| Nuwara Academy | period_2026_10 | LKR 38,000.00 | OPEN |
Webhook deliveries
Retried 9 times over ~24h- DELIVERED
invoice.paid → Horizon Institute
1 attempt · HTTP 200
- PENDING
invoice.paid → Lakmal Physics
3 attempts · HTTP 502 · next 04:18
Card data
We do not collect, transmit or store card numbers
Payment is completed on the provider’s hosted page. We hold the invoice, the amount, their reference and the outcome — nothing that could be used to make a further charge.
Held by usInvoice, amount, currency, period, the gateway’s reference, the outcome
Never held by usCard number, expiry, CVV, cardholder authentication data
For the integrating platform
Three endpoints and one webhook
Our platforms integrate through @lmspay/sdk. This is the whole of the billing side.
import { LmsPay } from '@lmspay/sdk';
const pay = new LmsPay({
baseUrl: process.env.LMSPAY_URL, // https://lmspay.online
apiKey: process.env.LMSPAY_API_KEY, // issued per platform, stored hashed by us
});
// At the end of a billing period, the platform asks for an invoice.
const invoice = await pay.invoices.create({
externalRef: period.id, // the platform's own id for the period
periodKey: period.key, // '2026-10'
amountMinor: period.feeAmountMinor, // 4500000 = LKR 45,000.00
currency: 'LKR',
description: `Platform fee — ${period.key}`,
});
// Send the operator here. Nothing is charged until they act.
return invoice.checkoutUrl;A retry cannot bill twice
The reference is unique per platform in our database, so a repeated create returns the invoice that already exists. That is a constraint, not caller discipline — the caller is an automated job on a machine that reboots.
The webhook is not the authority
Notifications are signed with the timestamp inside the signed material, so an old capture stops verifying. The status endpoint remains the source of truth, and our documentation says so.
Everything this service does, in the order it does it
The whole chain, in order — and the single message that is allowed to mark an invoice paid.