The job: give tuition back without losing the thread
Refunds are a normal part of running an education business. A student changes their mind in the first week, a corporate sponsor pulls a seat, two people on the same team accidentally pay for the same cohort, or a learner is moved to a later intake and the original payment has to come back. None of these are disputes — the student is not accusing you of fraud — but each one is money leaving your balance, and each one has to be explainable later.
The reason this needs care on a crypto rail is finality. The confirmed on-chain payment that made tuition collection attractive in the first place — no reversal window, no months-long chargeback risk after the cohort has started — is the same property that means there is no protocol-level undo when you want to give the money back. You send a new transaction, to a destination you trust, for an amount you can justify, and you have to be able to map it back to the enrolment it relates to.
Teams that do this by hand hit the obvious failure modes. Someone pastes a wallet address from a support email and transposes a character. Two staff members both action the same withdrawal request and the student is paid twice. A refund goes out with no link to the invoice, and at month-end finance is looking at an outbound transfer nobody can tie to a sale. halfin's refunds product removes those failure modes by anchoring the refund to the tuition invoice the student already paid.
A student refund is bound to the original tuition invoice
The defining property of a halfin refund is its anchor: it references the completed invoice the student paid. That single link is what separates a tuition refund from a generic payout. The original invoice already records who paid, how much in fiat terms, in which asset, and on which network — so the refund inherits that context instead of asking an operator to re-key it from memory under time pressure.
Because the invoice was fiat-anchored, the amount you reason about is the dollar figure the student was billed, not a token quantity you have to reconstruct. A student refund can return the whole paid amount or part of it, which covers the everyday education cases below. Network fees and on-chain rates still apply to the outbound transaction, so what the student receives reflects the cost of actually sending tuition back across the chain.
Anchoring the refund to the invoice also closes the reconciliation gap before it opens. Finance does not see an unexplained outbound transfer; they see a refund that points at the tuition invoice for a specific student and cohort, which they can open and tie back to the enrolment. The audit trail runs cleanly from the sale to the return.
| Why the student left | What they paid | Refund against the invoice |
|---|---|---|
| Dropped in the cooling-off window | Full tuition for a cohort that has not started | Return the full paid amount to the student |
| Withdrew partway through | Full tuition, several modules already delivered | Return part of the paid amount per your withdrawal policy |
| Duplicate enrolment | Two payments for the same seat | Refund the duplicate against its own invoice |
| Moved to a later intake | Paid for an intake they can no longer attend | Refund the original invoice; bill the new intake separately |
A refund is a deliberate action, not a dispute you defend
The contrast that matters for education is with the card world. On cards, a student who wants their money back can open a chargeback weeks after consuming half the course, and the school is dragged into a dispute it has to contest with screenshots of login activity and proof of access. The bank decides, and the merchant carries the reversal risk on every enrolment until the dispute window closes.
On halfin there is no inbound dispute to defend, because there is no card network to reverse the payment. When a student is owed tuition back, the school initiates the return on its own terms: an operator with the right permission creates a refund against the paid invoice, confirms the amount and the destination, and approves it. The school decides the policy — full refund inside the cooling-off window, prorated after a cutoff, nothing once a certificate is issued — and the refund enforces that decision as an explicit step rather than an external party imposing one.
That deliberate human gate is the control. It is where someone verifies the withdrawal request is genuine, the amount matches your policy for how far into the course the student got, and the destination is the student you expect. A refund is not auto-fired from a raw support message, which is exactly what stops a forged or mistaken request from quietly draining a balance.
- A student refund is initiated and approved by an operator — never auto-fired from a raw withdrawal request.
- Your withdrawal policy (full / prorated / none) is enforced as a deliberate amount, not dictated by a card network.
- Permission to move funds is scoped, so a read-only reporting key or your enrolment integration cannot trigger a refund.
- Each refund is logged with actor, amount, destination, and the tuition invoice it refunds.
- There is no inbound chargeback to contest, so the school is not carrying a reversal window on every seat.
How a withdrawal becomes a recorded refund
The operating flow keeps the enrolment system and the payment system on either side of a clean line. Your platform owns who the student is, which cohort they were in, and whether your policy entitles them to money back. halfin owns the payment record and the controlled return. The two meet at the invoice.
When a student withdraws, your team confirms eligibility in your own systems, then an operator creates a refund against that student's tuition invoice in halfin — full or partial, according to how far into the course they got. The refund is approved, the outbound transaction is sent, and the refund is recorded against the original invoice. Because the original payment confirmed via a signed invoice.paid webhook, the entitlement your platform granted at enrolment is something you can now revoke against a payment you know is real, on a refund you can point to.
Keeping the two records distinct is what makes the books honest. A refund reduces the tuition revenue tied to that enrolment; it is not a generic outflow. When the same student re-enrols in a later intake, that is a fresh invoice and a fresh payment — not an adjustment to the refunded one — so each cohort's revenue stays accurate.
- Your platform confirms the student is eligible for a refund under your withdrawal policy.
- An operator creates a refund against that student's tuition invoice — full or partial.
- The operator approves it; halfin sends the outbound transaction and records it against the original invoice.
- You revoke the course entitlement your platform granted, against a payment and a refund you can both point to.
- A re-enrolment later is a new invoice, not an edit to the refunded one — cohort revenue stays clean.
Where student refunds sit next to your other money movements
A refund is one specific kind of outbound payment, and it shares plumbing with the rest of the pay side an education business runs. If you already pay instructors and contractors through payouts, a refund is the same class of action with a tighter contract: it must point at a paid tuition invoice and return value against it. Knowing which primitive fits keeps your records readable.
Use a refund when you are returning tuition to a student who paid you on a specific invoice. Use a single payout when you are paying a destination with no originating invoice — an instructor fee, a guest-lecturer payment, a scholarship disbursement. Use a mass payout when you are fanning many such payments out at once, like a cohort of teaching assistants. Refunds reduce the revenue tied to a sale; payouts are operating outflows that were never student revenue to begin with.
The settlement asset is handled from the invoice, not from memory. If the student paid tuition in USDT on Tron and your treasury has since moved some balance into another asset through conversion, the refund still reasons from the original invoice — the asset and network the student used to pay are part of that record, which is the context a refund needs to send tuition back the way it came.