Cross-border education payments: collect tuition and pay instructors abroad

A school based in one country teaches students in forty others and pays instructors in a dozen more. Money has to come in from everywhere and go back out to everywhere, and the bank rails in between charge a toll, a delay, and a currency conversion at every hop. halfin collapses that into one flow: tuition arrives as a fiat-anchored invoice the student pays from whatever wallet they already hold, and instructors abroad get paid from the same balance as one mass payout — both sides denominated against the dollar figure the school plans in.

The shape of the problem: money crosses borders twice

A cross-border education business has two payment flows that both cross borders, in opposite directions, and the friction compounds. Inbound, students in countries with thin card coverage, capital controls, or unstable local currencies struggle to pay a USD-priced course — the card declines, or the international wire lands days late minus correspondent-bank fees, in an amount that no longer matches the invoice. Outbound, the instructors who record the lessons and the teaching assistants who grade the work sit in that same scattered map, and paying each of them by individual international wire is the slowest, most expensive line item in the operation.

Run the two flows through traditional banking and you maintain a relationship per region on the way in and a wire per payee on the way out, reconciling across currencies the whole time. The school is effectively a small FX desk that did not ask to be one. The cross-border case is the hard one — collection and payout are both international — so the rest of this page is about how a single rail handles both directions without the school standing up a treasury operation.

halfin's answer is to keep one anchor currency and one settlement layer. The student pays the crypto equivalent of a USD figure; the school holds a balance; instructors abroad are paid from that balance as a reviewed batch. Borders stop being a per-transaction tax and become a property of the addresses involved, nothing more.

Inbound: collect tuition globally with fiat-anchored invoices

Collection is fiat-anchored invoicing. You price the course in USD — your catalog, your revenue reporting, and your refund amounts all stay in dollars — and create an invoice with that fiat amount. halfin computes the payable asset amount from the live rate, locks it when the student activates the invoice, and shows them a concrete number to send in the asset and network they hold. For a student in a country where stablecoins are easier to get than dollars, that frequently means USDT on Tron or Solana, where fees are low and predictable.

The rate lock is what makes this collectable across a slow cross-border payment. Between the moment a student in another time zone opens the invoice and the moment the transaction confirms, the market can move; the lock means the school collects the USD figure it quoted regardless. halfin credits the payment with reorg-aware confirmation under each chain's threshold and sends an HMAC-signed webhook when it confirms — verify the signature, then grant the student their seat. Underpaid and overpaid invoices land in defined states your back office can act on, instead of becoming unmatched deposits discovered at month-end.

A minimal create call is one authenticated POST. The amount is a string — monetary values are strings end to end — and the currency is the fiat anchor, never the crypto code. The response shape is defined at docs.thehalfin.com; the point is that one call gives you a payable invoice tied to the dollar figure you billed.

curl -X POST https://api.thehalfin.com/api/v1/invoices \
  -H "X-API-Key: $HALFIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_fiat": "1200.00",
    "fiat_currency": "USD",
    "description": "Spring cohort — full tuition",
    "idempotency_key": "00000000-0000-4000-8000-000000000010"
  }'

# halfin locks the rate at activation, pins the payable asset amount, and
# sends a signed invoice.paid webhook on confirmation. Verify the HMAC
# signature before granting access. See docs.thehalfin.com for the schema.

Outbound: pay instructors abroad with mass payouts

The people who deliver a cross-border course are themselves cross-border: a subject-matter expert recording video in one country, a cohort of teaching assistants grading projects in several others, mentors holding office hours wherever they live. Paying each one by international wire is exactly the friction the school just removed on the inbound side — so halfin removes it on the outbound side the same way.

Mass payouts move the recurring run as one reviewed batch. A mass payout is a fan-out over the single-payout API: you submit a list of lines, each line carrying a currency, an amount, a destination address, and its own idempotency_key, and you approve the batch once. The per-line idempotency key is the load-bearing property for cross-border payroll — if a payout run is retried after a network timeout, each line settles exactly once, never twice. For a one-off — a guest lecturer, a single course-design fee — single payouts cover the same path without the batch.

Because collection and payout share one balance, one dashboard, and one API, finance closes the loop in a single place: tuition came in against these invoices, instructor and TA payments went out in these batches, and balance conversion rebalanced the treasury in between. Each payout carries audit context tying a wallet payment back to the payee and the cohort.

• One mass payout = a list of lines fanned out over POST /api/v1/payouts, approved once.
• Each line: currency, amount, destination, and its own idempotency_key.
• A retried batch settles each line exactly once — safe to re-submit after a timeout.
• Single payouts cover one-off instructor or contractor payments with operator review.
• Every payout carries audit context linking the payment to the payee and cohort.

One settlement layer instead of a bank relationship per region

The reason to put both flows on the same rail is reconciliation. With banking, the inbound side and the outbound side live in different systems, different currencies, and different statements, and tying a student's tuition to the instructors who taught that cohort is manual archaeology. With halfin, both sides are the same primitive surface — invoices in, payouts out, conversion in between — so the school operates one settlement layer regardless of where the student or the instructor sits.

The table maps each step of the cross-border flow to the halfin primitive behind it. Each one is a standard halfin product — invoicing, mass payouts, balance conversion — arranged here for the specific case where both ends are international.

Where the assets actually settle

Cross-border students reach for whatever they already hold, and that is usually a stablecoin on a low-fee chain. A USD-priced invoice paid in USDC or USDT is a dollar-denominated payment, so the rate lock barely has to move and the amount feels intuitive on both ends. On the payout side you pay instructors in the assets and networks they can receive — frequently the same stablecoins. The matrix below is the real supported surface halfin runs gates on; an invoice or a payout draws from it, not from a longer aspirational list.

Compliance: a process boundary, not a license

Moving money across borders in both directions 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 stays responsible for its own student onboarding, its program or institutional approvals, and any 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 across borders; they are processes, not certifications halfin holds on a school's behalf. The practical pattern is to keep student identity and instructor-eligibility decisions inside the school's own systems, and let halfin handle the payment instruction, screening, and the invoice, payout, and webhook records finance reconciles.

• KYB onboarding verifies the education business as a merchant — not the school's accreditation.
• Keep student identity and instructor eligibility inside your own platform.
• AML and travel-rule awareness shape cross-border screening as a process, never a certification.
• Attach invoice and payout records to each student, cohort, instructor, and contractor for audit.