Told the Moment It Settles
A signed POST to your server the instant a payment changes state, retried for six hours if you are not there to take it. Verify one HMAC and stop polling for good.
Get StartedOne checkout, and it takes major card brands, quick checkout methods and buy now, pay later — with nothing else to integrate.
Features
Signed With Your Secret
An HMAC over the timestamp and the raw body. Recompute it with the secret only you and we hold, and you know the event is ours and has not been altered on the way.
Retried Until You Take It
Six attempts over six hours. A minute, five, thirty, two hours, six. Your deploy can overrun and your webhook still arrives without anyone chasing it.
Stop polling in three steps
There is no queue to run and no subscription to negotiate. Give us a URL, pick what you care about, and check one signature at the other end.
01. Point
Give us a URL. An HTTPS endpoint on a public host. Blockra hands back a signing secret at the same time — that is the whole of the setup.
02. Pick
Subscribe to what you act on. Most integrations want the completed event and nothing else. Take confirming if you show a pending state, expired if you release stock.
03. Verify
One comparison, then trust it. Hash the raw body with your secret and compare in constant time. Do it before parsing — a JSON round-trip changes the bytes you signed.
Card payouts land in your own Stripe account. Coins land at addresses derived from a key we have never held. Blockra is the part in the middle — it builds the checkout, watches the chain and tells you when the money arrived, and at no point is the money ours to hold, freeze or lose.
There is no balance page here because there is no balance of yours on our side.
The parts that matter at 3am
Delivering a webhook once when everything is up is easy. What decides whether you trust it is what happens when something is not.
Learn moreEach delivery keeps its attempt count, the status your server last returned and the error if there was one — so a webhook that did not arrive is a question with an answer rather than an argument between two teams.
A retry can land after your first attempt quietly succeeded. Every delivery names the payment and the state it reached, so a handler that keys off that pair does the work once and shrugs at the rest.
A webhook URL is an outbound request from our infrastructure, so private, loopback and link-local destinations are refused when you save the endpoint rather than discovered later.
- HMAC-SHA256 over t.body
- Constant-time comparison
- Ten-second delivery timeout
- Private destinations refused
The signature covers the timestamp and the raw body together, which is what stops an old delivery being replayed at you later. Check it against the bytes you received, not the object you parsed.
The same event, whichever rail was used
A card charge and a Bitcoin payment produce the identical envelope. You write one handler, not one per payment method.
One shape to parse
Every delivery is a type, a created timestamp and the payment object as the API would have returned it. A card payment and a coin payment carry the same fields — the coin names itself in `asset`, a card leaves it null — so one handler covers both and always will.
- type, created and data.object
- One event set, not one per rail
- Same fields for cards and for coins
HTTPS Only
Public hosts, checked when you save the endpoint.
Many Endpoints
Fan the same event out to more than one place.
Backoff Schedule
1m, 5m, 30m, 2h, 6h — then it stops.
Per-Event Opt-In
Subscribe only to what you actually handle.
Start Taking Payments
Cards and crypto in one checkout, settling straight to accounts and wallets you control. No platform fees, and nothing to deploy.
Get Started