Build, buy, or rent: a decision framework for payment infrastructure.

Every payments conversation eventually reaches the same fork: do we build it, buy software and run it ourselves, or rent a hosted service? Teams tend to answer by default — the engineer who volunteers builds, the vendor who called first gets rented. This guide replaces the default with a framework.

Three options, three different bets

Software vs service

Buying software means you deploy and operate it. Renting a service means the vendor operates it. The line between them is who holds the keys and who is on call.

Six criteria

1. 01

   Control

   Who holds keys, chooses networks, and decides when to upgrade? How much does that matter to your customers, counterparties, or counsel?

2. 02

   Time to first payment

   Weeks for a service, weeks for software, months for a build. Measure against your real launch date.

3. 03

   Operating burden

   Who is on call, who patches, who reconciles? Burden does not disappear; it moves.

4. 04

   Total cost

   Fees, licences, engineering time, and the reconciliation hours nobody budgets for.

5. 05

   Flexibility

   Can you add a network, change a flow, or export your data without asking permission?

6. 06

   Exit risk

   If the vendor changed terms or disappeared, how painful is leaving?

How each option scores

The ratings below are general tendencies, not verdicts. Your context can flip any row.

A scoring sheet

Weight each criterion from 1 to 5 by how much your business cannot afford to lose, then score each option from 1 to 5. Multiply, add, and compare. The exercise matters more than the number: it forces the team to say which criteria are non-negotiable.

Criterion              Weight  Build  Buy  Rent
Control                  _      _      _    _
Time to first payment    _      _      _    _
Operating burden         _      _      _    _
Total cost (2 years)     _      _      _    _
Flexibility              _      _      _    _
Exit risk                _      _      _    _
---------------------------------------------
Weighted total                  _      _    _

When each option is right

Build is right in a narrower set of cases: payments are the product itself, you have the team to maintain it for years, and no existing software fits your model. Most companies overestimate how often that is true.

The costs people forget

• Reconciliation labour. Every hour finance spends stitching records is a cost of the option you chose.
• Incident cost. A silent failure on a weekend has a price, even if it never appears on an invoice.
• Upgrade discipline. Self-hosted software only helps if patch releases are actually deployed.
• Switching cost. Adapters written to a vendor's shape have to be rewritten if you leave.

For reference, StablePay licences are one-time purchases that start at $4,800 for a single production environment and rise with the number of environments and operators. Pricing and terms live on the product page; treat any figure here as a pointer, not a quote.

A worked example, with hypothetical numbers

Numbers make trade-offs concrete, but they can also mislead. The example below is invented to show the method, not to benchmark anything. Replace every value with your own.

The shape of the curves matters more than the numbers. Renting is cheap to start and grows with volume. Owning is expensive to start and flattens. Whether they cross inside your planning horizon is the question, and the answer is sensitive to volume, so test it.

Sensitivity: which assumption moves the answer most?

Anatomy of lock-in

Lock-in is not one thing. It is a set of dependencies, and different options create different ones. Naming them lets you decide which you will accept.

Joel Spolsky's classic argument about not-invented-here ^[1] is often used to defend buying, but read closely it says something more precise: build the things that are your core competitive advantage, and buy the rest. That is a decision about differentiation, not about cost.

Hybrid approaches

The choice is not always binary. Several hybrids are worth considering.

• Rent to start, own later. Launch on a hosted service to learn real volume, and design your integration behind a thin internal interface so a later move is a swap, not a rewrite.
• Own the record, rent the edge. Keep the authoritative payment state in your own database while using a vendor for a specific rail, such as cards.
• Own for one flow. Run a self-hosted gateway for the flows where control matters, such as treasury settlement, and a hosted processor for the rest.

interface PaymentProvider {
  createIntent(input: { reference: string; amount: Money }): Promise<Intent>;
  getIntent(id: string): Promise<Intent>;
  // events are normalised into your own vocabulary at the edge
  onEvent(handler: (e: NormalisedPaymentEvent) => Promise<void>): void;
}

// Application code depends on PaymentProvider, never on a vendor SDK directly.

Write the decision down

Architecture decision records ^[2] are a lightweight way to capture why a choice was made, what alternatives were considered, and what would make you revisit it. Six months later, when someone asks why you chose this path, the record answers without an archaeology project.

Title:        Payment infrastructure: self-hosted gateway
Status:       Accepted (revisit at 12 months or 2x volume)
Context:      Reconciliation costs X hours/month; counterparties ask where keys live.
Decision:     Deploy self-hosted gateway; keep a thin PaymentProvider interface.
Alternatives: Hosted processor (rejected: opaque ledger); build (rejected: not core).
Consequences: We operate the deployment; on-call rota; patch cadence owner named.
Revisit if:   Volume halves, vendor changes terms, or ops burden exceeds N hours/month.

This framework is engineering guidance, not financial, legal, or compliance advice.