Bank Transfer, Card, or Bitcoin: How You Pay Us

How you pay a vendor is supposed to be boring. It stays boring right up until a payment method decides it isn't. A card gets declined on a risk flag, a cross-border transfer bounces, an account gets frozen with no one to appeal to.

So we rebuilt how you pay us around three rails: SEPA bank transfer, credit card via Stripe, and Bitcoin on a BTCPay server we host ourselves. Each one is there for a different customer. Here's the reasoning, without the marketing gloss.

Bank Transfer: The German B2B Default

For most of our Mittelstand customers, the answer is simply the invoice. You order, you get a proper invoice, you pay it by SEPA transfer within the payment term. No card on file, no processor sitting in the middle, no monthly surprise. This is how German B2B has always worked, and there's no reason to fight it.

The one wrinkle is the first order. A new account pays the first invoice up front. A proforma invoice, due before we provision. Once you're an existing customer, invoices move to a normal due date and you pay on your own terms. It's the boring, reliable path, and for a lot of companies it's the only one they need.

Credit Card via Stripe: For Customers Abroad

SEPA is a European convenience. If your company banks outside the single-euro-payments area, a transfer is slow and expensive, and “pay by invoice” stops being friendly. Cards solve that.

We process cards through Stripe, with 3-D Secure on by default. Visa, Mastercard, and American Express all clear. You can also store the card so recurring invoices pay themselves. The charge runs automatically on the due date, and you're not chasing a manual transfer every month for a service that renews anyway. For customers outside the EU, or anyone who just prefers a card, this is the path of least friction.

Bitcoin: A Trial Run on Our Own BTCPay Server

The third rail is the interesting one, and we'll be honest that it's a trial. Some teams' cards simply don't clear. A bank's risk model, a jurisdiction, a border. When the two normal rails fail, there should be a third that doesn't depend on any card network deciding you're allowed to pay.

What matters here is how we do it. We run our own BTCPay Server on our own network (AS215197), backed by our own Bitcoin full node. That has two consequences worth stating plainly:

• Non-custodial. No third-party payment processor sits between you and us. Payments go to our node directly; nobody in the middle can hold, freeze, or reverse them.
• Self-hosted. The whole thing runs on the same infrastructure we sell. A fair test of our own platform, and one less external dependency in the billing path.

We're calling it a trial run because that's what it is. It's live, it works end-to-end, and we're watching how customers actually use it before we make big promises about it. If it earns its keep, it stays. That's a more honest position than pretending a payment method is battle-tested on day one.

If your specific case is object storage you need to pay for in Bitcoin (backups you can't afford to lose behind a frozen account) there's a fuller write-up in S3-compatible object storage in the EU you can pay for in Bitcoin.

What This Means for Your Invoices

All three rails feed the same billing system, so the invoice logic is consistent no matter how you pay:

• First order: a proforma invoice, paid up front, in whichever rail suits you. We provision once it clears.
• Existing customer: a normal invoice with a due date. Pay by SEPA, let a stored card charge itself, or send Bitcoin. Your choice, invoice by invoice.
• Recurring services: store a card once for hands-off auto-pay, or keep paying manually. We don't force a card on file.

None of this is exotic. It's the same principle behind everything we run: keep the important paths under our own control, in a jurisdiction you can point to, and give you a way through even when the usual one is blocked. The same argument for owning your infrastructure applies to owning the way you get paid. A point we make at length in digital sovereignty in Europe: what actually matters.

Storage, compute, and connectivity should be the hard part. Paying for them shouldn't be.