How to Add Embedded Payments to Your Education Platform
.png)
Schools increasingly want to take payments inside the systems they already use: fee billing in the MIS, trips and clubs in the booking system, lunches in the catering app. For the platforms behind those systems, embedded payments has moved from "nice to have" to something schools ask about in the first demo.
The question we hear most from product teams isn't whether to add payments. It's what's actually involved. Here's a practical walk-through.
What "embedded payments" actually means
Embedded payments means parents pay inside your product, rather than being sent off to a separate site or platform. The payment experience looks and feels like the rest of your platform, while a payments partner handles what happens after someone presses pay.
It's different from bolting on a payment gateway. A gateway takes the payment. An embedded payments partner also handles everything around it: onboarding schools, moving the money, reconciling it and supporting it.
Step 1: Decide where payments sit in your product
Start with the parent journey, not the technology. Where in your product does money change hands? A fee bill, a trip consent form, a club booking, a lunch top-up?
Then decide how it should look. Some platforms want payments fully white labelled. Others prefer co-branding, because schools and parents that already use esenda elsewhere find a familiar name reassuring. Neither is wrong, and the choice can differ by product.
Step 2: Map how your schools are structured
Schools aren't one simple customer. A trust or group might be several separately registered schools, and each legal entity may need to be verified before it can take a payment.
You'll also want to know where the money should land (which bank account, for which school) and how schools want it reported. Estates income, for example, may need to be kept separate. Getting this right up front saves a lot of untangling later.
