Crypto payments for high-risk merchants

A business labelled high-risk by card acquirers lives with three recurring problems: applications get declined, settlements get held back in a rolling reserve, and an account can be terminated with little notice. A confirmed crypto payment does not pass through an acquirer, so none of those levers apply. You accept the payment directly on-chain, it settles under the chain's confirmation rules, and there is no issuer or acquirer in the loop to reverse it, hold it, or close you out. What you still own — and what halfin onboarding expects you to own — is your own KYB and AML process.

What 'high-risk' actually costs a merchant

'High-risk' is an acquirer's label, not a description of the business. It gets applied to whole categories — adult goods, certain digital services, supplements, ticketing, anything with elevated chargeback rates or unfamiliar to the underwriter — regardless of how the individual merchant operates. Once the label is attached, the payment terms change in ways that have nothing to do with whether customers actually pay.

The concrete costs are predictable. Applications get declined outright, so the business cannot take cards at all on some platforms. Where an account is granted, the acquirer holds a rolling reserve — a slice of every settlement parked for months against future disputes — which starves working capital. And the relationship is fragile: a spike in chargebacks, a policy change at the acquirer, or a reassessment of the category can freeze funds or terminate the account, sometimes with the held reserve released slowly afterwards.

None of this is a verdict on the merchant. It is the acquirer managing its own exposure, and the merchant absorbs the consequences. A second rail that does not run through an acquirer removes that single point of failure — not as a way to dodge obligations, but so a legitimate business is not one underwriting decision away from losing the ability to get paid.

Why a confirmed crypto payment sidesteps the acquirer levers

A card payment is a chain of intermediaries: the customer's issuer, the card network, and your acquirer. Each one can say no, hold money, or reverse a settlement after the fact. The reserve, the decline, and the chargeback are all things those intermediaries do; they exist because the money moves through them.

A crypto payment through halfin does not take that path. The customer sends funds on-chain to an address tied to your invoice, halfin watches the network, waits for that chain's confirmation threshold, and credits the payment in a reorg-aware way. There is no issuer to charge back, no acquirer to impose a reserve, and no underwriting committee that can terminate the rail underneath you. Once a payment is credited under the chain's rules, it has settled.

That changes which risks you carry. You are no longer exposed to the rolling reserve or the surprise account closure. You do take on the responsibility that comes with final settlement: a confirmed payment cannot be force-reversed, so returns and goodwill are deliberate refunds you choose to issue against the original invoice, and counterparty screening becomes your job rather than the acquirer's. That trade — control and finality in exchange for owning your own controls — is the whole reason high-risk merchants look at crypto first.

• No acquirer underwriting in the path, so there is no decline that blocks acceptance.
• No rolling reserve withholding a slice of every settlement for months.
• No issuer-initiated chargeback reversing a payment after fulfilment.
• No acquirer relationship that can be terminated, freezing or closing the rail.
• Reorg-aware crediting at the per-chain confirmation threshold means a credited payment has actually settled.

Card holds versus crypto settlement, side by side

The difference is structural, not a matter of degree. The table maps the moments where a high-risk card merchant typically loses control against how the same moment behaves on a crypto rail.

Compliance is a process you run at onboarding, not a status you buy

Sidestepping the acquirer does not sidestep responsibility. A high-risk merchant still has to know who it is dealing with, and halfin is built on the assumption that you run that process yourself. Onboarding to a halfin merchant account involves KYB — verifying the business behind the account — and the platform operates with AML awareness as an ongoing process, not a certificate.

halfin is payment infrastructure: it collects payments, executes payouts, keeps payment records, and exposes every state change through dashboard data and signed webhooks. It does not take over your customer onboarding, your counterparty screening, your tax handling, or any approvals required for the specific goods or services you sell. The travel rule — the idea that certain transfers carry information about the parties — is a concept to design around, not a licence halfin holds or grants. halfin is not 'regulated' or 'licensed' as a status, and nothing on this page is legal advice; treat your own obligations as a question for your own counsel.

The practical pattern for a high-risk segment is to keep your own controls as the source of truth and let halfin be the rail and the audit trail. Keep your own customer KYC, your own wallet and counterparty screening, and a clear record of which order each invoice and payout belongs to. The signed webhook and the dashboard give you the evidence; the decisions about who you serve and what you sell stay with you.

• KYB at onboarding verifies the business behind the merchant account.
• AML awareness is an ongoing process, never a status halfin grants you.
• Travel rule is an educational concept to design flows around, not a certification.
• Keep your own KYC, screening, and per-order records as your source of truth.
• Nothing here is legal advice — your obligations are a question for your own counsel.

How the rail looks in practice

The integration is the same one any e-commerce merchant uses; being high-risk does not change the mechanics. You create an invoice anchored to the order total in the fiat currency your catalogue already uses, and the rate locks when the invoice activates so a moving market cannot turn the sale into an underpayment. You redirect the customer to hosted checkout, where they pick a network they already hold funds on and pay against a fixed amount, address, and QR.

Your server learns the outcome from one HMAC-signed webhook. Verify the signature before you act on it, then mark the order paid and release fulfilment — the customer's redirect back to your success page is for their eyes, the webhook is for your database. Because settlement is final, your record of invoices and payouts is also your dispute file: if a counterparty ever questions a payment, you have the on-chain settlement and the matching order rather than an acquirer's case-management portal.

The minimal create call below anchors the order in fiat; the customer settles in the crypto asset they choose on the hosted checkout page returned in the response. The full request and response schema lives in the docs.

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": "89.00",
    "fiat_currency": "USD",
    "idempotency_key": "order-90417"
  }'

# Anchor the order in fiat; the customer settles in the crypto asset
# they pick on the hosted checkout page returned in the response.
# Redirect them there, then verify the signed invoice webhook before
# releasing the order. Full schema at docs.thehalfin.com.

Networks a high-risk customer can pay with

Customers pay on a rail they already hold funds on, chosen from the networks you enable. Stablecoins are the common case because the dollar value does not move between checkout and confirmation, which matters when working capital is already tight from years of reserves. Every option below is a real on-chain gate — there is no placeholder network that quietly does nothing.