Security

Railbed is built so that the most valuable things are never in our hands. Card details go to a licensed provider, not to us. Funds go to the merchant's own wallet, not to a balance we hold. This page describes the protections around what we do handle, and how to report a problem if you find one.

Non-custodial by design

Railbed never holds, pools or controls merchant or buyer funds. Each payment is delivered as USDC to a wallet the merchant controls, and the fees are split off along the way by our payment infrastructure partner. There is no Railbed treasury of customer money, so there is no pool of funds for an attacker to target. Merchants are responsible for the security of their own wallets and keys, and the terms of service explain what that involves.

Card data

Buyers enter their card details on the on-ramp provider's page, never on a Railbed page. Card numbers, expiry dates and security codes do not pass through Railbed's servers, and we do not store them. The providers that charge cards are PCI-compliant payment businesses that operate under their own licences.

Transport

Every Railbed host serves traffic over HTTPS only, with HTTP Strict Transport Security and TLS 1.2 or newer. Plain HTTP requests are redirected before any data is exchanged.

Accounts and sessions

• Passwords are hashed with PBKDF2-SHA256 and a per-user salt. We do not store passwords in a form that can be read back.
• The dashboard session cookie is HttpOnly, Secure and SameSite=Lax, so scripts on a page cannot read it and other sites cannot send it.
• Dashboard actions that change something are protected against cross-site request forgery.
• Sign-in, sign-up, checkout starts and the API are rate limited to slow down credential stuffing and abuse.

API keys

API keys are shown once, when they are created, and stored only as SHA-256 hashes. If a key is lost, it cannot be recovered; the merchant creates a new one and revokes the old one. Keys should be kept on the merchant's servers and never placed in client-side code, mobile apps or public repositories.

Webhooks

Every webhook Railbed sends to a merchant is signed with HMAC-SHA256 using the endpoint's signing secret. The signature covers a timestamp as well as the body, and is delivered in the Railbed-Signature header in the form t=…,v1=…. Merchants can verify the signature before trusting a notification and reject deliveries whose timestamp is too old, which prevents replay. Endpoints should treat unsigned or badly signed requests as noise.

Payment notifications

Railbed marks a payment as paid only after it verifies that the money arrived: normally from a notification sent by our payment infrastructure partner, whose RSA signature is checked against the partner's published key, and otherwise from Railbed's own status check with the partner. Notifications that fail verification are ignored, and any payment whose amount or destination doesn't match what was agreed is held for the merchant's review rather than marked paid. Merchant webhooks and success redirects follow from that verified state, not from anything the buyer's browser reports.

Infrastructure

Railbed runs on Cloudflare, which provides the network edge, DDoS protection, request screening and the databases behind the service. We keep the parts of the system that know about payment infrastructure small and separate, so a change in one place does not spread. We do not currently hold third-party certifications such as SOC 2 or ISO 27001, and we do not claim to.

Reporting a vulnerability

If you believe you have found a security issue in Railbed, please tell us before telling anyone else. Write to security@railbed.io with:

• the steps to reproduce the issue
• the host and URL involved
• what you were able to access or affect
• any tooling or account you used

We will acknowledge your report, keep you updated as we investigate, and tell you when the issue is fixed. We do not run a paid bug bounty programme.

We ask researchers to:

• not access, change or delete data that belongs to other users
• not degrade the service, for example through load testing or denial of service
• not use social engineering, phishing or physical attacks against DeepWork, its staff, merchants or providers
• give us a reasonable amount of time to fix the issue before publishing anything about it

We will not pursue legal action against researchers who act in good faith and within these rules. The same details are published in machine-readable form at https://railbed.io/.well-known/security.txt.