Payment and Subscription Systems for EdTech: Handling Institutional Billing, Refunds, and Financial Aid

TL;DR

• EdTech billing is not SaaS billing with a different logo. You are usually running three payer types at once: consumers on cards or mandates, institutions on invoices and purchase orders, and third parties (aid programs, sponsors, employers) who pay part of a charge on their own schedule.
• Off-the-shelf billing tools handle the first payer well, the second partly, and the third poorly. That gap is where most custom work is justified.
• Design around a ledger of charges, allocations and adjustments, not around "subscriptions" and "payments". Refunds, aid returns and credit notes then become ordinary ledger entries instead of special cases.
• Regulation shapes the design: the US Return of Title IV Funds (R2T4) rules changed on July 1, 2026, and India's RBI e-mandate framework caps recurring card or UPI debits without OTP at ₹15,000 for most categories.
• Buy the payment rails and tax engine. Build the allocation logic, the refund policy engine and the reconciliation layer, because those encode your business rules.

Why EdTech billing breaks generic tools

A typical SaaS company has one buyer, one invoice and one renewal date. An EdTech platform rarely does. Consider what a mid-sized platform sells in a single quarter: monthly learner subscriptions, annual per-seat licences to schools, cohort-based course fees paid in instalments, add-on assessments, and, for credit-bearing programs, tuition partly covered by financial aid.

Each of those has a different answer to the same four questions:

1. Who owes the money? The learner, a parent, a school district, an employer, or a funding agency.
2. When is it earned? At purchase, monthly, over a term, or on completion of a milestone.
3. What happens if the learner leaves early? Prorated refund, full refund inside a cooling-off window, no refund, or a mandatory return of funds to a third party.
4. Who gets the refund? The payer of record, which is often not the learner.

Generic subscription tools model a customer, a plan and a payment method. They struggle when the person using the product is not the person paying, and when a single charge is split across payers. If you have ever exported invoices to a spreadsheet to work out who should be refunded what, you have met this limit.

The three payer models and what each demands

Consumer and parent payments

This is the closest to standard SaaS: card or bank mandate, monthly or annual plan, self-serve cancellation. The hard parts are regulatory rather than technical.

In India, the RBI's e-mandate framework requires one-time registration with additional factor authentication, a pre-debit notification at least 24 hours before each charge, and lets customers modify, pause or revoke the instruction at any time. As reported in April 2026, recurring payments without OTP are capped at ₹15,000 for everyday categories, with a higher ₹1 lakh limit for insurance, mutual funds and credit card bills. A learner plan above the cap needs an OTP on every charge, which changes conversion and churn assumptions. If you sell annual plans at higher price points, model that friction before you choose between annual prepay, instalments, or an EMI partner.

Design implications: store the mandate separately from the subscription, surface the 24-hour notice in your own UI and email (do not rely on the bank alone), and treat a failed debit as a normal state with a retry and dunning path rather than an error.

Institutional billing

Schools, colleges and training providers buy differently. They want a quote, a purchase order, an invoice with their own reference numbers, net-30 or net-60 terms, and often a single invoice covering several campuses or departments. They renew on an academic calendar rather than on the anniversary of signup.

This is where the "seat" model gets complicated. A district may buy 5,000 seats in July, add 400 in October, and expect a credit when a campus closes. Your system needs:

• Contract objects with start and end dates, committed seats, price per seat, and rules for mid-term true-ups.
• Seat snapshots at defined dates (for example, the first of each month), so that billing is based on a record you can show the customer rather than a live count that changes under them.
• Invoice-level custom fields for PO number, cost centre and department, and the ability to split one contract into several invoices.
• Credit notes as first-class documents, not negative payments.
• Approval states for credits above a threshold, since institutional credits are where revenue leaks.

If you already run a student information system, the seat and enrolment data may live there. Our guide on Student Information System (SIS) Integration covers how to bring that data in without making billing depend on a fragile sync.

Third-party and aid-funded payments

This is the least standardised payer type. In the US, federal student aid under Title IV pays the institution directly, and the rules about what must be returned when a student withdraws are strict. In other markets the equivalent might be a state scholarship, an employer reimbursement scheme, or a corporate training budget.

The common pattern is that a third party pays a portion of a charge, on its own timeline, with conditions attached. Treating that payment as "just another payment against the invoice" works until the first withdrawal, when you must work out how much goes back to whom and in what order.

Financial aid and refunds: the part that needs a ledger

If your platform serves credit-bearing programs in the US, you need to understand R2T4. The federal rules require an institution to calculate how much Title IV aid a withdrawing student has "earned" and return the unearned portion. Changes effective July 1, 2026 (announced by Federal Student Aid in March 2026) include:

• Institutions must document the date of determination that a student withdrew no later than 14 days after the student's last date of attendance. The calculation must still be completed within 30 days, and funds returned within 45 days.
• For clock-hour programs, scheduled hours in a later payment period do not begin to accrue until the student successfully completes the prior period.
• R2T4 freeze dates no longer apply to modular programs, simplifying the calculation.
• An institution may exempt a student from an R2T4 calculation if it returns all Title IV aid, refunds institutional charges, and treats the student as never having begun attendance, subject to documentation.

You should read the official announcement and your compliance officer's interpretation rather than rely on this summary. The point for system design is narrower: those deadlines are clocks that start from an attendance event, not from a billing event. If your billing system does not receive attendance and withdrawal events from the LMS or SIS, a person will be keeping those clocks in a spreadsheet.

Even if you are outside the US, the structure repeats. A withdrawal triggers a calculation that depends on dates, the amount of the charge already earned, and the source of each payment, and the output is a set of refunds and returns with an order of priority.

The ledger model

Instead of building "subscription", "invoice", "payment" and "refund" tables that reference each other in increasingly awkward ways, model a double-entry style ledger:

With this structure, a refund is not a special flow. It is an adjustment to a charge, which changes how much each allocation has earned, which produces disbursements in the order your policy says. The same engine then handles a parent's cooling-off refund, a district's mid-term credit and a federal aid return.

A practitioner's example: the refund waterfall

Here is the decision sequence we would design for a withdrawal, stated as a sequence of ledger operations. The values are illustrative.

Assumptions: a 15-week program, charge of 120,000 (any currency), paid 80,000 by an aid program and 40,000 by the learner; the learner withdraws at the end of week 6.

1. Record the withdrawal event with the last date of attendance, from the attendance system, not from a user clicking a button in billing.
2. Compute the earned fraction by your policy. For a simple pro-rata policy, 6/15 = 40%. A real policy may use a different rule, a minimum fee, or a cooling-off window, and it must be versioned so you can reproduce the calculation on any past date.
3. Post an adjustment reducing the earned charge to 48,000 and creating an unearned amount of 72,000.
4. Allocate the unearned amount by priority. Many funding rules return to the third party first. If the aid program has priority, 72,000 goes to it, limited to the 80,000 it paid, so the aid program receives 72,000 and the learner's 40,000 stays against the earned charge. Different rules produce different results, and the priority order must be configuration, not code.
5. Create disbursements for each recipient, with the deadline calculated from the withdrawal event.
6. Hold for approval if the amount is above a threshold or any input is missing.
7. Reconcile the disbursement against the bank or aid portal and close the case.

The valuable property is auditability. A finance or compliance reviewer can open the case and see the event, the policy version, the calculation, the allocation order and the resulting payments.

Failure modes to design against

Refunds to a closed payment method. Cards expire and mandates are revoked. Plan an alternative path (bank transfer, credit on account, or manual payout) with an owner and a deadline, rather than leaving the refund in a failed state.

Duplicate refunds. Retries on a gateway timeout can issue the refund twice. Use idempotency keys tied to the disbursement record, and make the ledger the source of truth, not the gateway.

Proration drift. If a billing tool prorates in its own way and your finance team prorates differently, month-end will not agree. Pick one proration policy, document it, and test it against edge cases such as leap years, mid-month starts and timezone boundaries.

Seat counts that change after the invoice. Use snapshots and an explicit true-up step. Without them, every dispute becomes an argument about which number was correct on which day.

Revenue recognition mismatch. Subscription and term fees are generally recognised over the service period, so the billing system and the general ledger must agree on schedules. Under ASC 606 or IFRS 15, refunds, credits and variable consideration need consistent treatment. Your accountants should define the policy; the system should make it cheap to follow.

Partial failures in multi-payer settlement. If one payer's receipt arrives and another's does not, the charge is partly paid. Make "partially allocated" a valid state with its own reports.

Dunning that ignores context. A school's accounts-payable team does not respond to a card-failure email. Institutions need a different collections workflow: statements, account-manager tasks and escalation, not automated retries.

Build, buy, or assemble

A fair question is whether you should build any of this. The answer is usually "assemble", with a clear line between what you buy and what you own.

A rough decision rule: if one payer pays one charge on one schedule, buy a billing product and configure it. If one charge has multiple payers, conditions and clawbacks, the billing product will become the bottleneck, and a thin custom ledger and policy engine on top of a payment provider is cheaper over three years than workarounds.

A cost and timeline sketch, with assumptions

These figures depend heavily on scope and team, so treat them as a way to structure the conversation rather than a quote.

Assumptions: one payment provider, one ERP or accounting system, two payer types beyond the consumer (institutions and one aid or sponsor channel), one currency and one tax regime to start, no custom mobile work.

• Discovery and policy mapping (2-3 weeks): document every charge type, refund rule, payer, and the exact meaning of "earned". This is the cheapest and most valuable phase, and the one most often skipped.
• Ledger and allocation core (4-6 weeks): data model, charge and allocation APIs, adjustment engine, versioned policy configuration.
• Integrations (4-8 weeks): payment provider, ERP, SIS/LMS events, email and notification. This phase takes the longest where source systems are older. See our work on API development and integration for how we approach it.
• Institutional workflows (3-5 weeks): contracts, seat snapshots, invoices with PO fields, credit notes with approvals.
• Reconciliation and reporting (3-4 weeks): match gateway payouts, bank lines and aid disbursements; exception queue; finance dashboards.
• Parallel run (4-8 weeks): run the new system alongside the old one for at least one billing cycle, compare outputs, and fix differences before cutover.

A first release covering one payer type end to end is realistic in a few months. A full programme covering multiple payer types and markets takes longer, and the parallel run should not be shortened to hit a date.

Reconciliation: where the project is won or lost

Most billing projects focus on creating charges and collecting money. Finance teams spend their time on the other side: explaining why the bank balance does not match the ledger.

Build reconciliation as a feature from the start:

• Three-way match: ledger receipts, PSP settlement reports, and bank statement lines.
• Fee handling: gateway fees and chargebacks must post to the ledger, otherwise every settlement is short by a small and unexplained amount.
• Exception queue: unmatched items assigned to a person, with age and reason.
• Immutable history: corrections are new entries, never edits.

Our post on reconciliation automation for payment platforms goes deeper on the matching logic.

Data protection and security

Billing systems hold personal and financial data about learners, and sometimes minors. Keep card data with the PSP and use tokenisation so your own systems stay out of the heaviest PCI scope. Limit who can see aid and financial details, log every access and every manual override, and set retention periods that match your legal obligations. Where the learner is a minor, the payer is often a parent, so your data model must keep the learner and the payer as separate people.

Implementation sequence that reduces risk

1. Write the refund and aid policies in plain language and have finance and compliance sign them. Code comes after.
2. Build the ledger and adjustment engine with test cases from real past withdrawals.
3. Connect events from the SIS or LMS for enrolment, attendance and withdrawal.
4. Add consumer subscriptions on the payment provider, mapped into the ledger.
5. Add institutional contracts and invoices.
6. Add third-party allocations and disbursements.
7. Run in parallel, then cut over one segment at a time, starting with the segment with the simplest rules.

Conclusion

EdTech billing is hard because the business is hard: multiple payers, academic calendars, regulated money and learners who change their minds. The most reliable approach is to buy the commodity parts, such as payment rails, tax and the general ledger, and to own the layer that encodes your rules for allocation, refunds and reconciliation. Start with the policy, model the ledger carefully, connect attendance and enrolment events, and prove the design with a parallel run before you retire the old process. If your platform is growing into institutional and aid-funded sales, our overview of EdTech software development shows where billing sits alongside the rest of the stack, and our custom software development team can help you decide what to build and what to buy.

Next step

If your team is hitting the limits of an off-the-shelf billing tool, or planning institutional and aid-funded sales, a 30-minute call can map your hardest refund scenario to a build, buy or assemble decision. Book a 30-minute call

Sources

• Federal Student Aid, Implementation of Return of Title IV Funds (R2T4) regulations effective July 1, 2026
• Federal Student Aid, FSA Handbook: General Requirements for Withdrawals and the Return of Title IV Funds
• BusinessToday, RBI caps recurring payments at ₹15,000 without OTP under new e-mandate framework
• Solvimon, ASC 606 for usage-based and AI-native businesses

This article is general information, not legal, tax or accounting advice. Cost and timeline figures are illustrative assumptions.