Billing privacy

Today

Railgun Pro and Business are billed through Stripe. Stripe collects your email and your card at checkout; we never see the card. What we store on our side is your account record, a reference to your Stripe customer, your tier, and the dates your subscription starts, renews or lapses.

Those records live in the same database as your account. That means that today, a query can join the address that pays us to the username that uses us. We send receipts, failed-payment notices, renewal reminders and — if your subscription lapses — an offer to come back. Those emails go to the address on your account, and the fact that we can send them is the same fact as the one in the previous sentence.

We would rather write that down than describe a privacy property we have not built.

The problem with the obvious fix

The intuitive way to break that link is to store a hash of the username next to the billing email, so that no readable handle appears in the billing records. It does not work, and it is worth saying why, because the idea is common and it is wrong.

Usernames are public and there are not many of them. Anyone holding the billing table can hash every handle on Railgun and compare — a few seconds of work — and the table is de-anonymised completely. The same is true of a hashed email address. A hash only hides an input drawn from a space too large to enumerate, and a handle is not that.

Planned: a separated billing store

The design we intend to build gives billing its own system, with its own credentials, holding its own records:

• When you subscribe, a random reference is minted — 128 bits, derived from nothing about you. Not your name, not your email, not your account.
• The billing store holds that reference, your billing email, your tier, your amount, and your renewal date. It holds no username and no account id. Its operational view of you is: this reference pays $20 a month and lapses on Friday.
• Your account record holds the reference and nothing about your payment.
• Reminders, receipts and offers are sent by the billing system, which can reach your inbox without knowing which Railgun user it is writing to.

Timing is part of the design, not an afterthought. Two records written a millisecond apart are joined by their timestamps whether or not they share a key, so dates on the billing side are coarsened and no locale, country or IP is copied across. Stripe already holds that detail and does not need a second copy under our roof.

What that would and would not promise

It would mean three concrete things. A breach of the account database would expose no billing email. A breach of the billing store would expose an email with no handle attached. And ordinary work — support, analytics, debugging — would run against one side, so joining the two becomes a deliberate, auditable act instead of an incidental one.

It would not mean we cannot know. Both systems are ours. The reference sits beside your username on the account side, so anyone holding both — us, an attacker who takes both, a legal order naming both — can still join them. Separation raises the cost of that join and narrows who can perform it. It does not make it impossible, and we will not claim it does.

Further out: paying without an account

The only architecture under which we genuinely cannot identify a paying user is one where the link lives on your device instead of our infrastructure: you buy a voucher with no account attached, receive a redeemable code, and enter it in the app. Your account then records that it is paid until a date, and nothing else — no customer reference, no way back to the card.

It costs something real, which is why it is a second path rather than the only one: no automatic renewal, no self-serve billing portal, and a lost code is a lost subscription. We intend to offer it alongside the subscription, not instead of it.

What is never hidden

Your bank knows it paid us. Stripe, as our payment processor, knows your card and your email, and is subject to its own legal obligations and its own privacy policy. Card networks record the merchant. No design of ours reaches any of that. If your threat model requires that no institution can observe a payment to Railgun, the voucher path — bought and redeemed separately — is the closest we will ever get, and it is still not nothing.

Contact

Questions about any of this, including the parts that are not built yet, go to privacy@railgun.chat.