Limitless Wealth
Writing

Things we had to work out the hard way.

Written down so we stop rediscovering them. Payments infrastructure, regulated data, testing discipline, and systems that outlive the people who wrote them.

Payments architecture
01

Why your merchant ID was withdrawn

Aggregation, the tightening of scheme enforcement, and the three structures acquirers will actually accept, with what each one costs.

02

When you need payment orchestration

Not a scale problem, a risk problem. Four of the five triggers are about something going wrong. Build, buy, and the cheap version first.

03

Network tokens and who owns your cards

Better authorisation rates and cards that survive reissue. Whether they also free you from your gateway depends on whose name is on the Token Requestor ID.

04

Why your ledger and your PSP disagree

Six structural reasons they diverge, why a balance column fails at the first chargeback, and reconciliation that still gets read after a fortnight.

06

The open banking access gap

Open banking was meant to give merchants a cheaper alternative to cards. Below a certain volume it mostly has not, and the reason is arithmetic.

Regulated and sensitive data
Testing and agents
10

How we build Rails applications

Our working standard, published. Enforced conventions rather than documented ones, per-layer coverage, deterministic data, migrations checked before merge.

Systems
In preparation
  • ProcurementReading a payment provider quote
  • PaymentsDirect debit is not a card payment
  • CommerceStock is a ledger too
  • CommerceQuote to cash: the states nobody models
  • TaxSales tax across regions
  • EngineeringIdempotency, and the requests you will receive twice
  • EngineeringZero-downtime migrations in practice