Build your own self-custodial crypto acceptance infrastructure.
hedles is the rail underneath your cashier. Build a gateway on it, or drop it into the one you already run. Your brand on the front, your merchants’ keys on the back, nobody in the middle. Including us.
Illustrative activity with simulated counters and events.
The rail behind your crypto payment gateway.
hedles is not a gateway and does not want to be one. It is the acceptance layer a gateway is built on: address issuance, chain monitoring, payouts, swaps and a payfac account hierarchy, exposed as one API. Build your own front end on it, or put it behind the cashier you already have.
Fully white labelled. Your brand.
hedles has no front end, no logo in your checkout and no name on your merchant’s statement. You run the gateway. You set the pricing. You own the relationship. We are the engine room, and engine rooms do not need signage.
Don’t take on custody. The merchant holds the keys.
Funds never land in a hedles account, a pooled wallet or an omnibus you do not control. Each merchant signs its own payouts with its own credential, so there is nothing for us to freeze, lend out or lose. You get the economics of a gateway without the liability of a custodian.
Stay out of the money flow. On-chain splits settle every payment atomically.
Your fee is written into the payment itself, not reconciled afterwards. One transaction, every party paid, settled on chain in the same block. No float, no end-of-month sweep, no spreadsheet proving who is owed what.
Onboard merchants and sub-merchants.
Full payfac hierarchy out of the box. Create a merchant, create its sub-merchants, set the fee rules at any level. Each account gets its own addresses, its own keys and its own reporting, and you see all of it from one tier above.
All chains. All coins.
24 chains, from the EVM estate through Solana, Bitcoin, Litecoin, Bitcoin Cash, Dogecoin, Zcash, TRON and XRPL. Native assets, ERC-20, TRC-20, SPL, XRPL issued tokens and UTXO. Accept whatever your payers hold and settle in whatever your merchant wants.
How it works
Your merchant claims its wallet.
A passkey or a P-256 API key, held by the merchant. hedles never sees the private material.
You issue addresses.
One persistent address per customer, per asset, per network, or rotate per payment. Your policy, set per merchant. On memo chains like XRPL, one address and a destination tag per customer.
We watch the chain.
Deposits are detected, driven through confirmation and pushed to your webhook. payin.pending, then payin.confirmed. HMAC-SHA256 signed, idempotent, retried with backoff.
The merchant signs its own payouts.
The API returns the unsigned work, your integration stamps it with the merchant’s credential, and it broadcasts. Preflight simulation catches the revert, the gas shortfall and the missing destination tag before anything leaves the wallet.
Built to be audited, not trusted.
One REST API, versioned. Tier-scoped reads, so a merchant sees its own row and you see your whole book. Fixed roles: admin, ops, reader, collector. Webhooks signed and idempotent. Payout states you can reconcile against: pending, prepared, ready, signed, broadcast, settled, failed. Swaps quoted by RFQ and executed against a signature you provide, so asset conversion never requires custody either.
POST /v1/payins
Authorization: Bearer <session>
{
"chain": "base",
"asset": "USDC",
"amount": "250000000",
"reference": "order-1042"
}payin.confirmed
X-Hedles-Signature: t=1791892800,v1=…
{
"event": "payin.confirmed",
"data": {
"payinId": "019a03ba-7420-7000-8000-000000000001",
"chain": "base",
"asset": "USDC",
"txHash": "0x5fd0000000000000000000000000000000000000000000000000000000000000",
"blockNumber": 52000000,
"confirmations": 12,
"fromAddress": null
}
}Questions we get asked first
“If we hold no custody, who carries the compliance burden?”
You do, and that is the point. You set the KYT policy, you see every address, you decide what to accept. We do not sit between you and your regulator with our own terms of service. Self-custody makes you more auditable, not less.
“What happens to our merchants if hedles disappears?”
The keys are already theirs. The addresses are already derived. A hedles outage stops new address issuance and our monitoring; it does not strand a single coin. Nobody needs our permission to move their own money.
“We have been de-risked before. Why is this different?”
Because there is no account to close. A bank can exit you, a custodian can freeze you and a gateway can reprice you, because all three hold your balance. We hold nothing. There is no lever to pull.
“We already run a gateway. Where does hedles sit?”
Underneath it. hedles is a rail, not a front end, so it does not compete with your cashier, your PSP routing or your existing checkout. You keep what you have built and swap out the part that holds the money. For most platforms that is the only part they wanted to replace.
Build the gateway. Keep the custody.
Read the API reference, or send us the shape of your flow and we will tell you plainly whether hedles fits.