International tuition payments in crypto, quoted in USD or EUR

A school sets tuition at 4,200 USD. A student in Lagos, another in Manila, and a third in Buenos Aires all want to enroll, and all three hit the same wall: a card that declines on a cross-border BIN, a bank wire that lands three days late minus correspondent fees, or a transfer that arrives in the wrong amount because the rate moved in transit. halfin lets the school keep tuition quoted in USD or EUR while the student pays the equivalent in an asset they already hold — USDT, USDC, or BTC — and the rate locks the moment the invoice activates, so the figure the school books is the figure it set.

The problem: one tuition price, a different payment rail per country

Tuition is a single number set in one currency — almost always USD or EUR for an international program. Everything downstream of that number is supposed to be mechanical: the student pays it, finance records it, the seat unlocks. In practice the payment step quietly re-prices the tuition and re-introduces every border the catalog ignored.

Cards are the first failure point. A student in a country with thin card penetration cannot complete a Visa or Mastercard checkout at all, and the ones who can carry a reversal tail — a chargeback weeks later, after the term has started and the student has consumed half the material, that the school contests with login logs and attendance records. Bank wires are the fallback, and they are slow, opaque, and arrive net of correspondent-bank fees in an amount that no longer matches the invoice. By the time finance reconciles a wire, the cohort has begun and nobody is certain whether a given seat is actually paid.

The deeper issue is currency drift. When a student in a volatile-currency region converts to dollars through their bank, the amount that lands depends on when the conversion cleared, not on what the school quoted. Tuition set at 4,200 USD becomes 4,150 here and 4,260 there, and finance spends month-end reconciling differences that were never supposed to exist. The school needs the booked figure to hold regardless of how — or from where — the student paid.

How fiat-anchored invoicing holds the number

halfin's invoicing primitive is built around exactly this: a tuition figure that does not drift. The school creates an invoice anchored to a fiat amount — the USD or EUR price it set — and halfin computes the payable crypto amount from the live rate and pins it for the life of that invoice. The student sees a concrete instruction ("pay 4,200.00 USDC" for a stablecoin, or the BTC equivalent for Bitcoin), pays it on the network they hold funds on, and the school books the fiat figure it started with.

The rate locks at activation, not at creation. When the student opens the invoice and it goes live, halfin freezes the conversion and stamps an expiry. If the student pays inside that window, the amount they were shown settles to the quoted tuition exactly. If the window lapses, the invoice expires rather than silently re-pricing against a stale rate — the school decides whether to re-issue at the current rate. That single property is what makes crypto usable for an institution that thinks in dollars: the market can move while the student is paying, and the school still collects what it quoted.

Underpayments and overpayments are handled as defined states instead of silent mismatches. A student who pays a slightly stale quote, or whose exchange skimmed a withdrawal fee, lands the invoice in an underpaid state with the shortfall recorded — finance can request a top-up or settle partially under the school's own policy. An overpayment is recorded against the same invoice so the excess is visible and accountable. Crediting is reorg-aware and waits for each chain's confirmation threshold, so the amount the school sees as settled is an amount that actually held on-chain.

• Create the invoice in USD or EUR — the tuition figure you set is the source of truth.
• halfin pins the payable crypto amount at activation and stamps a payment window.
• Student pays in USDT, USDC, BTC, or another supported asset on the network they hold.
• Reorg-aware crediting and per-chain thresholds confirm the payment before it counts.
• Underpaid / overpaid land in defined states your back office can act on, not silent gaps.

Why stablecoins do most of the work for tuition

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 — 4,200 USD is 4,200 USDC. For a student in a region with a volatile local currency, a stablecoin is often the asset they already use to hold value, which removes the bank-conversion step that introduced the drift in the first place.

Network choice matters for tuition because a four-figure payment is sensitive to fees and confirmation time. Students gravitate to the networks where stablecoins are cheap and predictable to move — frequently USDT on Tron or Solana, or USDC on Solana or Base. The table below is the real surface halfin runs gates on; an invoice draws from this, not from a longer aspirational list. Bitcoin remains available for students who hold BTC and prefer to pay from it, settled against the same fiat anchor.

Collecting tuition without the chargeback tail

The reversal risk on cards is not a rounding error for a school — it is structural. A degree program or bootcamp delivers value continuously from day one, so a chargeback filed in week six claws back tuition the student has already consumed, and the school is left contesting it with evidence of attendance. A confirmed on-chain payment removes that window entirely: once an invoice crosses its chain's confirmation threshold, the tuition is collected and is not an authorization that can be reversed later.

That finality changes the revenue model rather than just the checkout. A school running on card rails carries weeks of reversal exposure on every enrollment and budgets for a baseline of disputes. On crypto rails the school is not holding that liability — and when a student genuinely needs their money back, it runs through refunds as a deliberate, recorded action against the original payment, not a dispute the school has to defend.

Refunds belong inside the same flow as collection. A student who withdraws inside a cooling-off window, or a duplicate enrollment, is refunded against the original invoice so finance sees the money returned, the record attached to the invoice it came from, and the student's account reflecting it. The school sets its own refund policy; halfin makes the mechanics a clean step instead of a reversal it absorbs.

Wiring it into enrollment

Tuition collection is spec-first REST, so the enrollment flow stays in the school's own platform and halfin sits underneath it. The school creates a fiat-anchored invoice with one authenticated call, presents it through hosted checkout (or renders it in its own enrollment UI with self-hosted checkout), and waits for the signed webhook — not the browser redirect — to unlock the seat.

The create call below quotes tuition in USD; the amount is a string because monetary values are strings end to end, never floats. The idempotency key means a retried request never creates a duplicate invoice for the same enrollment — which matters when a student double-clicks or the enrollment service retries after a timeout. The full response schema, the asset and network options, and the webhook envelope are defined at docs.thehalfin.com.

• Create the invoice anchored to the USD or EUR tuition figure with one authenticated call.
• Present it via hosted checkout, or render it yourself with self-hosted checkout.
• Listen for invoice.paid — verify the HMAC signature, then unlock the seat.
• Reconcile each paid invoice back to the student and cohort against the original fiat amount.

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": "4200.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Spring cohort tuition — student #4042",
    "idempotency_key": "00000000-0000-4000-8000-000000000042"
  }'

# halfin locks the rate when the student activates the invoice, pins the
# payable asset amount, and sends an HMAC-signed invoice.paid webhook when the
# payment confirms on-chain. Verify the signature before unlocking the seat.
# Full request and response schema: docs.thehalfin.com.

Where the school's responsibility starts and stops

Accepting cross-border tuition does not move the school's own obligations onto halfin — it sharpens the boundary. halfin's role is the payment rail: it collects the tuition, screens the payment counterparty, applies confirmations, and keeps the invoice, refund, and webhook records. The school keeps its own student onboarding, its program eligibility decisions, and whatever institutional or regulatory requirements apply where it operates and what it teaches.

Onboarding to halfin runs through KYB — verification of the education business as a merchant. That is not a status the school can claim toward its own accreditation, and it is not student KYC. 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 maintainable pattern is to keep student identity and eligibility inside the school's own systems and let halfin own whether the payment confirmed, where it came from, and what was refunded — two systems of record that reconcile through signed events.

• halfin verifies the school as a merchant through KYB — it is not accreditation or student KYC.
• Keep student identity and program eligibility decisions inside your own platform.
• AML and travel-rule awareness shape screening and records as a process, never a license.
• halfin owns whether tuition confirmed and was refunded; your platform owns who the student is.