Crypto payments for EdTech, bootcamps, and online courses

An online school sells the same course to a student in Lagos, a developer in Manila, and a designer in São Paulo — and the hardest part is getting paid. Cards get declined on cross-border BINs, bank transfers arrive days late in the wrong currency, and a chargeback can claw back tuition after the cohort has already started. halfin gives education businesses a payment layer that quotes tuition in USD, collects it on the chains students already hold funds on, pays instructors and contractors anywhere, and handles refunds as a defined step instead of a dispute.

The problem: education sells globally, but gets paid locally

EdTech is one of the most border-blind businesses there is. A bootcamp's landing page reaches a hundred countries on day one, the curriculum is the same for everyone, and the price is usually set in one currency — almost always USD. Then the payment step quietly re-introduces every border the marketing erased.

A student in a country with weak card penetration cannot complete a Visa checkout. A bank wire from their region lands two or three business days later, minus correspondent-bank fees, in an amount that no longer matches the invoice. By the time finance reconciles it, the cohort has started and nobody is sure whether seat 28 actually paid. The card payments that do go through carry their own tail risk: a chargeback weeks later, after the student has consumed half the course, that the school has to contest with screenshots of login activity.

The same friction runs in the other direction. The instructors recording lessons, the teaching assistants grading projects, and the contractors building the course platform are scattered across the same map as the students — and paying them by international wire is slow, opaque, and expensive per transaction. halfin's primitives map onto both sides of that flow: collect tuition as crypto quoted in fiat, settle it, pay the people who deliver the course, convert balances when treasury needs it, and reconcile the whole thing from one API.

How halfin fits the enrollment-to-payout flow

halfin does not become the learning platform or the student CRM. It sits underneath them as the payment layer, mapping a small set of primitives onto the flow a school already runs: a student enrolls, pays, the payment confirms on-chain, the seat unlocks, instructors get paid, and finance reconciles. Each step has a named halfin product behind it rather than a spreadsheet.

Collection is fiat-anchored invoicing. You quote tuition in USD; the invoice locks a rate when the student activates it and shows them the exact amount to send in the asset and network they choose. halfin watches the chain, applies that chain's confirmation threshold with reorg-aware crediting, and sends your server an HMAC-signed webhook when the payment confirms — which is what should unlock the course, not the redirect the student sees.

On the outbound side, single payouts handle a one-off instructor or contractor payment, and mass payouts handle the recurring run — a cohort of teaching assistants, a batch of affiliate educators, a monthly contractor cycle — as one idempotent batch you approve once. Balance conversion lets you keep treasury in the asset you want regardless of what students paid in. And refunds are a first-class flow, so a student who drops in the cooling-off window gets their money back as a deliberate action, not a dispute you have to defend.

• Enrollment → a fiat-anchored invoice quotes tuition in USD and locks the rate at activation.
• Payment → student pays in USDT, USDC, BTC, or another supported asset on the network they hold.
• Confirmation → reorg-aware crediting + per-chain thresholds; a signed webhook unlocks the seat.
• Delivery → instructors, TAs, and contractors are paid via single or mass payouts.
• Treasury → balance conversion rebalances what was collected into the asset you hold.
• Reconciliation → invoices, payouts, and webhook events tie back to each student and cohort.

Where this shows up: the education payment flows that matter

These are the flows education businesses hit first. They are described here so a team can plan an integration; each is a real operating problem that maps onto a halfin primitive without inventing anything new.

International tuition payments. A degree program, a bootcamp seat, or a certification fee is priced in USD but paid from anywhere. Fiat-anchored invoicing quotes the dollar amount, the student pays the equivalent in the asset they hold — frequently USDT on Tron or Solana where fees are low and predictable — and the rate lock means the school collects what it quoted even if the market moves while the student is paying. Underpaid and overpaid invoices land in defined states your back office can act on instead of silent mismatches discovered at reconciliation.

Online-course and self-paced payments. For a catalog of self-serve courses, hosted checkout is the smallest integration: create an invoice, redirect the buyer to a halfin-hosted page, and let the signed webhook flip the purchase to paid and grant access. There is no wallet code, QR library, or per-chain confirmation watcher in your stack. A school that wants the payment page inside its own product can use self-hosted checkout against the same invoicing primitive instead.

Payouts to instructors and contractors. The people who build and teach the course are paid through single payouts for one-off work and mass payouts for the recurring run. Batches are idempotent — re-submitting the same payout run does not double-pay — which matters when a payroll cycle gets retried after a timeout. Each payout carries audit context so finance can tie a wallet payment back to the contractor and the cohort.

Scholarship and stipend disbursement. A school disbursing scholarship funds, stipends, or grant money to students across borders is running a payout problem, not a collection problem. Mass payouts move a list of approved disbursements as one reviewed batch, with the same idempotency and audit trail as contractor payroll, so a finance team can disburse to a cohort of recipients without a stack of individual international wires.

Student refunds. A student who withdraws in a cooling-off window, or a duplicate enrollment, is a refund — handled as a deliberate, recorded action against the original payment rather than a chargeback the school has to contest. Because refunds are a defined product step, finance sees the money returned, the record attached to the original invoice, and the student's account reflecting it.

Cross-border education at large. Pulling these together, a school operating across many countries gets one settlement layer instead of a different bank relationship per region. Collection, payouts, conversion, and refunds run through the same API and the same dashboard, and the reconciliation story is consistent regardless of where the student or instructor sits.

Tuition collection without the chargeback tail

The single biggest reason education businesses look at crypto rails is finality. A confirmed on-chain payment is not a card authorization that can be reversed weeks later — once an invoice confirms under its chain's threshold, the tuition is collected. For a course that delivers value immediately and continuously, removing the reversal window changes the revenue model: the school is not carrying weeks of chargeback risk on every enrollment.

Fiat-anchoring is what makes that usable for an education business that thinks in dollars. The course costs what it costs in USD; the student pays the crypto equivalent at a rate locked when they activate the invoice. The school's catalog price, its revenue reporting, and its refund amounts all stay in the currency it already plans in, while the rail underneath collects whatever asset and network the student finds easiest.

Stablecoins do most of the work here. A student paying USD-priced tuition in USDC or USDT is sending a dollar-denominated asset, so the rate lock barely has to move and the amounts feel intuitive on both sides. The table below shows where stablecoins are available across the chains halfin runs real gates on.

Paying the people who build and teach the course

Education businesses run on a distributed bench: subject-matter experts recording video, teaching assistants reviewing assignments, mentors holding office hours, and contractors maintaining the platform. They are usually spread across the same set of countries the students come from, and paying them by international wire is the slowest, most expensive part of the operation per transaction.

Single payouts cover the one-off case — a guest lecturer, a one-time course-design fee — with operator review and an audit record before the payment leaves. Mass payouts cover the recurring case: an entire cohort of TAs, a batch of affiliate educators, or a monthly contractor cycle submitted as one idempotent batch. Idempotency is the load-bearing property here — if a payout run is retried after a network timeout, the batch is keyed so it settles once, not twice.

Because the same dashboard and API hold both collection and payout records, a finance team closes the loop in one place: tuition came in against these invoices, instructor and contractor payments went out in these batches, and balance conversion rebalanced the treasury in between. Every record carries enough context to tie a payment back to a student, an instructor, or a cohort.

Compliance: a process boundary, not a license

Accepting cross-border payments for education does not remove the school's own obligations — it sharpens where they sit. halfin's role is the payment rail: collect tuition, execute payouts, screen the payment counterparty, and keep the records. The school remains responsible for its own student onboarding, its institutional or program approvals, and any regulatory requirements specific to where it operates and what it teaches.

Onboarding to halfin runs through KYB — know-your-business verification of the merchant, not a status the school can claim toward its own accreditation. AML awareness and the travel rule are operating concepts that shape how payments are screened and recorded; they are processes, not certifications halfin holds on a school's behalf. The practical pattern is to keep student identity and program eligibility decisions inside the school's own systems, and let halfin handle the payment instruction, screening, and the invoice, payout, and webhook records that finance reconciles.

The clean separation is what keeps this maintainable: the school owns who the student is and whether they qualify; halfin owns whether the payment confirmed, where it came from, and where the payout went. Each side keeps its own system of record and the two reconcile through signed events.

• KYB onboarding verifies the education business as a merchant — it is not the school's accreditation.
• Keep student identity and program eligibility inside your own platform and CRM.
• AML and travel-rule awareness shape screening and records as a process, never as a certification.
• Attach invoice, payout, and webhook records to each student, cohort, and contractor for audit.
• Treat halfin as the payment system of record; treat your platform as the enrollment system of record.