Crypto payments for SaaS and API-first software

SaaS billing assumes a card on file that renews itself. Crypto has no card on file — a customer signs one transaction at a time, from a wallet you do not control. halfin gives you the primitives to bridge that gap: an invoice per billing cycle with a rate locked at activation, an API-first checkout your product can drive directly, signed webhooks that flip an account active the moment payment confirms, and payouts to run a developer or affiliate ecosystem on the same balance.

The problem: crypto breaks the card-on-file model

Subscription software runs on a quiet assumption: the customer enters a card once, and the processor charges it again every month without anyone touching it. The merchant's job is to react to a renewal that already happened — a success, a decline, a dunning email.

Crypto inverts that. There is no token you can charge unattended. A wallet signs a transaction at the moment the customer decides to, for the exact amount shown, on whichever chain they hold funds. You cannot reach back into the wallet next month and pull the next period's fee. Every cycle is a fresh, customer-initiated payment, and the price has to be re-stated in crypto at the rate that holds right then.

That is the real work in SaaS-meets-crypto, and it is not the checkout widget. It is the recurring path: re-quoting each cycle, locking a rate so the customer is not chasing a moving target, knowing precisely when a payment confirmed so you can extend access, and handling the cycle where the customer simply does not pay. halfin's invoicing primitive is built around that lifecycle rather than around a stored credential.

• No card on file means no unattended renewal — each cycle is a new signed payment.
• The fee must be re-quoted in crypto every period at the live rate.
• Access has to follow confirmation, not a charge attempt, so the signal is the webhook.
• A missed cycle is an expired invoice, not a declined card — your retention logic changes shape.

How halfin fits: invoice per cycle, rate locked, webhook drives access

The shape of a halfin recurring path is one invoice per billing cycle. When a period comes due, you create a fiat-anchored invoice — say USD 49 — and halfin quotes the equivalent in whatever assets you accept and locks that rate at activation. The customer has a defined window to pay before the quote expires; they are never asked to settle a number that drifted while they were reading it.

The customer pays through hosted checkout or a checkout you render yourself against the same API. halfin watches the chain, applies that chain's confirmation threshold, and credits the deposit reorg-aware. The instant the invoice resolves, your server receives an HMAC-signed webhook. Verify the signature, then extend the subscription period — that webhook, not the redirect and not a polling loop, is what should flip the account to active and set the next renewal date.

Because the amount is fiat-anchored, your pricing page stays in dollars or euros and your revenue reporting stays in fiat, while the customer settles in USDT, USDC, or a native asset. Underpaid and overpaid cycles land in defined states instead of silent mismatches, so a customer who sends slightly too little does not quietly get a full month. The whole flow maps cleanly onto the deposit, confirm, credit, reconcile sequence your finance team already thinks in.

The recurring billing path, step by step

A renewal cycle is short to describe and entirely API-driven, which is what makes it fit an API-first product. Your billing job wakes up, decides what the customer owes this period, and creates an invoice. The idempotency key is what keeps a retried job from double-billing — reuse the same key for the same cycle and a repeat call returns the existing invoice instead of issuing a second one.

From there the customer pays on a checkout surface and halfin handles the chain. Your only job is to wait for the signed webhook and act on it: extend access on a confirmed payment, and treat an expired invoice as a non-renewal your dunning flow can pick up — a reminder email, a grace period, a downgrade to a free tier, whatever your product already does for a failed card, re-pointed at an expiry event.

The request below creates one cycle's invoice against the REST API. The same call is what a cron job, a usage-rollup worker, or a self-serve upgrade button would make — there is no separate 'recurring' endpoint to learn, just the invoicing primitive called once per period, with an idempotency key scoped to the cycle so a retried job never bills twice.

• Billing job computes the amount due and creates a fiat-anchored invoice.
• An idempotency key scoped to the cycle makes the create call safe to retry.
• Customer pays via hosted or self-hosted checkout; halfin confirms on-chain.
• Signed webhook -> verify -> extend the period and schedule the next cycle.
• Expired invoice -> hand off to dunning: reminder, grace, or downgrade.

# Called once per billing cycle by your scheduler.
# The idempotency_key is scoped to the cycle, so a retried job
# returns the existing invoice instead of billing twice.
curl https://api.thehalfin.com/api/v1/invoices \
  -H "X-API-Key: $HALFIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_fiat": "49.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Subscription acct_42 2026-06",
    "idempotency_key": "sub-acct_42-2026-06"
  }'

Key use cases for SaaS teams

The recurring path is the spine, but SaaS businesses reach for halfin across a handful of related jobs that share the same balance and event stream.

Crypto subscription payments are the baseline — a flat monthly or annual plan billed as one fiat-anchored invoice per period, with access extended on the confirmation webhook. Recurring crypto billing covers the operational layer around that: re-quoting, rate lock, the expiry window, and turning a non-payment into a dunning event your product already understands.

API-first checkout suits products where billing is a backend concern, not a hosted page — you create invoices programmatically and either redirect to hosted checkout or render a self-hosted checkout inside your own UI against the same API. Usage-based pricing in crypto fits metered and consumption products: tally the period's usage, then issue one invoice for the total once the period closes. Global SaaS payments are the reason many teams start here at all — a customer in a market where cards fail or settle slowly can still pay in USDT or USDC on a chain they already use, with your prices stated in fiat.

Developer payouts run the other direction on the same balance: pay plugin authors, API resellers, revenue-share partners, and affiliates with single payouts for one-off settlements and idempotent batch payouts for a whole payout run. SaaS compliance sits underneath all of it — KYB onboarding and AML-aware operation as process, covered in the next section.

• Crypto subscription payments — flat plans billed one invoice per cycle.
• Recurring crypto billing — re-quote, rate lock, expiry, and dunning handling.
• API-first checkout — programmatic invoices, hosted or self-hosted surface.
• Usage-based pricing in crypto — one invoice for the metered period total.
• Global SaaS payments — fiat-stated prices settled in USDT/USDC worldwide.
• Developer payouts — single and batch payouts to your partner ecosystem.
• SaaS compliance — KYB onboarding and AML awareness as operating process.

Running a developer and partner ecosystem on the same balance

Most SaaS companies that take crypto eventually pay in crypto too. An app marketplace owes plugin authors a revenue share. An API platform pays out to resellers. A growth program owes affiliates a commission. These payments come from the same funds your subscriptions collected, so it is natural to run them off the same halfin balance rather than a separate rail.

For a single settlement — paying one partner, refunding a wallet — a single payout goes to one destination after your own approval step. For a whole payout run at the end of a month, a mass payout sends an idempotent batch: submit the batch once, and a retry after a network blip will not pay anyone twice, because the batch is keyed. Your approval, payee list, and wallet validation stay inside your systems; halfin executes the approved instruction and reports the result through signed webhooks you reconcile against.

Sitting between collection and payout is balance conversion. The assets you collect are rarely the exact assets you want to hold or pay out in. Automatic and manual conversion let you rebalance treasury — consolidate into a stablecoin before a payout run, or hold a target mix — without moving funds off-platform. Collect, convert, pay out, and reconcile all reference the same balance and the same event stream.

Compliance: KYB onboarding and AML awareness as process

halfin onboards merchants through KYB — know-your-business checks that establish who the business is before it can accept payments or send payouts. That is a process, not a certificate the merchant inherits, and it does not replace any obligations your software business carries in its own markets.

Operating awareness around AML and the travel rule is part of running a payment surface responsibly, and halfin treats both as process and educational context rather than a status anyone holds. Where your product serves end customers, identity, suitability, and any market-specific approvals remain your responsibility — halfin gives you payment records, signed events, and audit context to support your own controls, not a substitute for them.

The practical division is the same one a careful finance team would draw: keep customer identity and account decisions inside your stack as the source of record, screen counterparties and wallets before accepting or paying, and keep every invoice, payout, and webhook attached to an account ID so reconciliation and any review have a clean trail. halfin makes no regulatory or license claim, and you should not infer one — the platform is payment infrastructure.

• KYB onboarding establishes the business before it transacts — a process, not a credential.
• AML awareness and the travel rule are operating context, never a certification.
• Customer identity, suitability, and market approvals stay your responsibility.
• Signed events and audit context support your controls; they do not replace them.

Where this leads next

The cleanest place to start is the invoicing primitive, because the recurring path is just that primitive called once per cycle with a rate lock. From there, decide on a checkout surface: hosted checkout for the smallest integration, or self-hosted checkout when the payment UI must live inside your product on your own domain.

Wire the webhook before you wire anything else that grants access — it is the only authoritative signal that a cycle was paid, and verifying its signature is the line between extending a subscription correctly and extending it on a forged request. Once collection works, the payout and balance-conversion primitives are there when your developer ecosystem or treasury needs them. The recurring integration is just that invoicing primitive called once per cycle, the signed webhook driving access, and payouts running the developer ecosystem on the same balance.