Why self-hosted payment software still wins.

Most teams do not start with a desire to run payment software. They start with a checkout that works, a vendor that answers Slack, and a promise that settlement is someone else's problem. That arrangement holds until the first weekend a webhook disappears and treasury cannot say what is owed.

This essay is about that weekend — what it tells you, when it arrives, and why we built StablePay as software you deploy rather than a service we run. It is not an argument against hosted processors. We tell teams to buy one all the time. It is an argument for noticing the moment the trade flips.

The Sunday problem

Every treasury team we have worked with can describe the same scene. It is a weekend. A counterparty says a payment was sent. The application says nothing arrived. The vendor dashboard shows a status that could mean either. Someone opens a ticket, and the ticket is answered on Monday.

Nothing in that scene is a bug. The processor did what it was designed to do. The problem is structural: the record of what happened lives on a system you cannot inspect, and the person who can explain it is not on call for you.

At low volume that is a fine trade. You are paying someone to carry the operational burden, including the burden of being wrong at 2am. The trade changes when the cost of not knowing exceeds the cost of knowing.

What ownership actually means

"Self-hosted" is often argued as a philosophy. It is more useful as a checklist of concrete operating questions:

The last row of that table is the one people underestimate. A vendor is a dependency with its own incentives. That is fine — until it is a dependency inside your settlement path.

When the trade flips

In our experience the flip is not a company size. It is one of four moments, and teams usually recognise them only in hindsight.

1. The reconciliation moment. Finance is spending real hours stitching an export to an application log to a wallet. The manual work is the invoice for not owning the record.
2. The constraint moment. A customer, regulator, or counterparty asks where keys live, or who can move funds. "A vendor, under a contract" stops being a complete answer.
3. The behaviour moment. The processor changes a webhook, a limit, or a fee, and your roadmap is now someone else's Tuesday.
4. The incident moment. A payment that looks confirmed on-chain is silent in the application and nobody on your side can prove which is right.

Vellum Markets hit the first and fourth at once. Settlement lived across a hosted processor, three wallets, and a nightly export nobody trusted after a missed webhook. Treasury could not answer, on a Sunday, what was owed, what was confirmed, and what was still in flight.

We stopped renting a processor and started running a system we could explain to our own engineers.

— Mira Adel, Head of Treasury, Vellum Markets

The honest cost of owning it

Self-hosting is not free, and any vendor who tells you otherwise is selling something. What changes is where the cost sits.

Costs that move onto you

• Running the deployment: Docker, PostgreSQL, backups, and upgrades.
• RPC providers and node reliability for the networks you enable.
• On-call. Someone on your side must be able to read the dashboard at 2am.
• Keeping current: patch releases only help if you apply them.

Costs that go away

• Per-transaction fees to a processor whose margin is your volume.
• The reconciliation work created by a ledger you cannot query.
• Adapter code that exists only to bridge a vendor's shape to yours.
• The negotiation whenever the vendor changes a term.

Compare both lines

Do not compare a vendor's fee with zero. Compare the fee plus reconciliation hours against the operating cost of a deployment your team already knows how to run.

What a fair self-hosted product owes you

Owning infrastructure is only a good deal if the software makes it tractable. We hold StablePay to a short list, and we would hold anyone else's to it too:

• A clear boundary. The studio is not in the path of funds. No hidden hosted signer, no "we can hold this for you" mode.
• A documented event contract. Signed, versioned webhooks and a replay path, so a missed delivery is recoverable rather than a mystery.
• A queryable record. Payment state in a database you run, plus an operator dashboard for tracking, confirmation, and settlement.
• Honest scope. Networks and tokens are limited to what is implemented and tested. Anything not shipped is marked planned.
• A handover. Runbooks for the ugly cases, not just an install guide.

How a cutover actually went

Ownership sounds like a big-bang migration. It was not. Vellum's route was deliberately boring, and the steps generalise.

1. 01

   Map how money already moves

   Which invoices exist, how traders pay, and who is allowed to mark something settled. Written down before any code.

2. 02

   Write the non-goals in the same document

   No custody, no new bank relationship, no rewrite of the trading engine. The non-goals kept the scope honest.

3. 03

   Deploy beside the marketplace

   StablePay ran inside Vellum's existing VPC as software they operate — not as a service they rent.

4. 04

   Wire payment intents to the order service

   The host application stayed in control of customer accounts; the gateway recorded payment state, retries, and exceptions.

5. 05

   Replace the nightly export with signed webhooks

   Confirmation policy was made explicit per network, and the operator dashboard replaced the three-tool lookup.

6. 06

   Hand over with a runbook

   Including the 2am case: a payment that looks confirmed on-chain and silent in the app.

A total-cost model you can copy

Most build-versus-rent arguments fail because each side counts different costs. A hosted vendor counts its fee. An engineer counts the build. Finance counts neither and asks why reconciliation takes three days. A useful model puts every cost on one sheet and assigns each to a named owner.

Fill it in for a two-year horizon rather than one. Licence and build costs are front-loaded; per-transaction fees are not. The crossover point — where cumulative hosted cost passes cumulative self-hosted cost — is the number that should drive the conversation. Below it, renting is rational. Above it, you are subsidising someone else's margin.

HOSTED (24 months)
  fees            = monthly_volume * fee_rate * 24
  reconciliation  = finance_hours_per_month * hourly_cost * 24
  integration     = one_off_adapter_cost
  TOTAL_H         = fees + reconciliation + integration

SELF-HOSTED (24 months)
  licence         = one_off_licence
  infrastructure  = monthly_infra * 24
  operations      = ops_hours_per_month * hourly_cost * 24
  reconciliation  = (finance_hours_per_month * 0.4) * hourly_cost * 24
  integration     = one_off_gateway_integration
  TOTAL_S         = licence + infrastructure + operations + reconciliation + integration

CROSSOVER month = first month where cumulative(TOTAL_H) > cumulative(TOTAL_S)

Be honest about the 0.4

The reconciliation multiplier in the sheet above is an assumption, not a measurement. Estimate it from your own last three month-ends: how many finance hours were spent proving that records agree, and how many of those would disappear if the payment record were a database you could query?

The risk register: what you take on when you own it

Ownership transfers risk as well as cost. A vendor absorbs some of it contractually; a self-hosted deployment absorbs it operationally. Naming the risks is not an argument against self-hosting — it is what makes the decision defensible to a board, an auditor, or a counterparty.

Notice that every mitigation is dull. That is the point. Self-hosted payment software is safe to operate for the same reasons any production system is: boring discipline applied consistently. The twelve-factor methodology ^[2] — config in the environment, backing services as attached resources, logs as event streams — is a good baseline for the deployment itself.

Migrating without a big bang

The fear that stops most teams is the cutover: the week where money flows through a system that has never carried real load. The answer is the same pattern used to replace any legacy component — the strangler fig ^[1]. Route a small, well-understood slice of traffic to the new path, prove it, then widen.

1. 01

   Shadow mode

   Deploy the gateway beside the existing flow. Create matching intents but let the old system remain authoritative. Compare what each records. The goal is not payments, it is agreement.

2. 02

   Choose a slice

   Pick the smallest slice that is still real: one product line, one token, a capped amount. Real money, low stakes.

3. 03

   Run a full reconciliation cycle in parallel

   Close a period from both records. Investigate every difference until you can explain it.

4. 04

   Move volume in steps

   Raise limits deliberately. Keep the old path warm for rollback until a full month-end has closed cleanly.

5. 05

   Retire the adapter

   Remove vendor-specific code, cancel the contract, and archive the exports. Only then is the migration finished.

Vellum's cutover followed this shape and reached a first live payment in seventeen days. The lesson was less about speed than about sequencing: agreement before authority.

Regulatory and counterparty posture, honestly

Self-hosting changes who holds keys and runs infrastructure. It does not change your regulatory obligations, and it does not make you compliant by default. Two things are worth saying plainly.

• We are not your counsel. StablePay is payment gateway software. The studio does not provide legal, tax, or compliance advice, and it is not a custodian or a bank. Whether your operating model meets your obligations is a question for your own advisers.
• Ownership makes the answers easier to give. When a counterparty, auditor, or regulator asks where keys live, who can move funds, and how a payment was approved, a self-hosted deployment lets you answer from your own records instead of forwarding a vendor's PDF.

Signals that it is time to revisit the decision

When you should still buy a processor

We say this plainly because it builds more trust than any feature list:

• You process low volume and nobody on the team wants to be the payment on-call.
• You need fiat card acceptance, chargeback handling, or a compliance posture a vendor already carries.
• Your differentiator is not payments, and a settlement incident would be inconvenient rather than existential.

StablePay is stablecoin payment gateway software. It is not a hosted processor, a custodian, or a bank, and it does not provide legal or compliance services. If those are what you need, a hosted provider is the honest answer.

A short decision test

Answer these without looking at a dashboard. If you cannot, you are close to the flip.

1. Right now, what is owed, what is confirmed, and what is in flight?
2. Who on your team could replay a missed payment event, and how?
3. Where do the signing keys live, and who can move funds?
4. If the vendor changed a webhook next quarter, how much of your roadmap moves?

Frequently asked questions

Is self-hosted cheaper?

Not at low volume. The licence and operating burden are real. It tends to win when volume is high enough that per-transaction margin exceeds operating cost, or when the cost of not knowing — reconciliation labour, incident exposure — is already large.

Do we need a dedicated payments team?

No, but you need a named owner and a rota. In practice that is an existing platform or infrastructure engineer with a runbook, not a new department.

What if the studio disappears?

You keep the deployment and the data, and the software keeps running. Patch releases stop, so plan for that in your risk register. This is exactly why the boundary matters: you are not depending on us to move funds.

Closing

The catalog is not a sermon against hosted services. It is a product for the moment ownership becomes cheaper than rental — usually later than the pitch deck, and earlier than the incident report. If you are reading this because a Sunday has already happened, the product page is the next stop.