1. The architecture is the control
Most of what protects you is not a feature; it is what Blockra is unable to do.
- We hold no crypto. Deposit addresses are derived from an extended public key you supply. An xpub derives and watches; it cannot sign. On save we reject any extended key containing a private component. A total compromise of Blockra does not let anyone move your coins.
- We hold no card data. Card number and security code are entered into fields hosted by Stripe inside the checkout page and go straight to Stripe. We store brand, last four, funding type, expiry and wallet — never a number that could be charged.
- We hold no Stripe credentials. Card payments run through your own Stripe account via Connect; we store its identifier and nothing else.
- We hold no bank account numbers. Bank details for a Blockra subscription, and for a payer using the bank option at your checkout, are entered on pages hosted by GoCardless and by the bank itself. We store a mandate or payment reference, the bank name and the last few digits — never anything that could be used to move money. A merchant's GoCardless access token is encrypted at rest and used only to act on that merchant's own account.
- We hold no recovery phrases. The optional Blockra Wallet generates its phrase in your browser, encrypts it with your password (scrypt, then AES-256-GCM) and keeps it in that browser's storage. It is never transmitted. Moving a wallet to your phone happens inside a QR code — the encrypted payload is in the image, so no server holds it even briefly.
2. Account security
- Passwords are handled by Supabase Auth and stored as bcrypt hashes. We never see them in plain text.
- Two-factor authentication (TOTP, RFC 6238) is available on every account, with one-time backup codes.
- New-device verification. Signing in from a device we have not seen sends a one-time code to your email. The device identifier is a random value your browser generates, which we store only as a SHA-256 hash — it is not a browser fingerprint derived from your headers, which could be forged by replaying them.
- One-time codes are stored hashed and expire quickly, with attempt limits.
- Sensitive actions — creating an API key, changing a password — require re-authentication.
3. API and integration security
- API keys are stored as a SHA-256 hash plus the first eight characters. The full key is shown once. Keys carry scopes, so a read-only key cannot create anything, and can be given an expiry.
- Rate limiting is per account and per plan, with
X-RateLimit-Limit,-Remainingand-Reseton every response. - Webhooks are signed with HMAC-SHA256 over the timestamp and the raw body (
X-Blockra-Signature: t=…,v1=…). Verify against the raw bytes, in constant time, before parsing. - Outbound webhook requests are guarded. Destinations must be HTTPS and public; private, loopback, link-local and reserved addresses are refused both when the endpoint is saved and again at delivery time, and redirects are never followed. This stops a webhook URL being used to reach inside our infrastructure.
- Public identifiers only. Responses expose prefixed public ids (
pay_…,cs_…); internal database identifiers are stripped on the way out.
4. Platform
- TLS in transit everywhere; encryption at rest at the database and hosting layer.
- Row-level security on the database, so a query for one account cannot return another's rows.
- Secrets are held as environment configuration, never in the repository.
- Server-verified payment completion: a payment is marked settled by our own check against the chain, against Stripe, or against a signed GoCardless webhook — never on the say-so of the browser. A bank payment stays pending, and digital goods are withheld, until the money is confirmed.
- Confirmation thresholds per chain before a payment is treated as final — two on Bitcoin, four on Litecoin, twelve on Ethereum, twenty on Tron.
5. What we do not do
Stated plainly so you can plan around it:
- No SOC 2, ISO 27001 or PCI DSS certification of our own. Card data is handled by Stripe, which is PCI DSS Level 1; the scope reduction is real, but it is Stripe's certification, not ours.
- No sanctions or chain-analysis screening of deposit addresses today.
- No identity, age or fraud checks on your customers.
- No bug-bounty programme yet. We still want the report — see below.
- No uptime guarantee. See the Terms of Service.
6. Your side of it
- Turn on two-factor authentication.
- Scope API keys to what they need and give them an expiry; rotate them if a key may have leaked.
- Verify webhook signatures. An unverified endpoint will accept anything anyone posts to it.
- Check your extended public keys before you take a payment. A wrong xpub sends money to a wallet you do not control and nobody can undo it.
- Write your wallet recovery phrase down, offline. It is the only copy.
7. Reporting a vulnerability
Email support@blockra.io with enough detail to reproduce the issue — the endpoint or page, the steps, and what you were able to achieve. A proof of concept helps.
We ask that you:
- give us a reasonable chance to fix it before publishing;
- do not access, modify or retain data belonging to anyone else;
- do not run denial-of-service, spam, or social-engineering attacks against us, our staff or our users;
- use only your own test accounts.
In return we will acknowledge your report, keep you updated on the fix, and credit you if you would like to be named. We will not pursue legal action for good-faith research that follows the above.
8. If something goes wrong
If a breach affects personal data we hold, we will notify the supervisory authority where required and tell affected merchants without undue delay, with what we know at the time and updates as we learn more. Where Blockra is your processor, notification obligations to your own customers are covered by the Data Processing Agreement.
9. Changes
This Policy is updated as the service changes. The "last updated" date at the top reflects the current version.