Loading…
Writing
Notes on payment systems, device software, transaction uncertainty, platform design, and the emerging role of AI in commerce. I write from the questions that appear in real operating conditions.
Retry-safe means idempotency-key aware. Reversal-safe means preserving the original approval alongside the reversal. Neither is the default.
Every payment platform ends up with a connector abstraction. The design choices that make one durable, and the ones that guarantee it will be rewritten in 18 months.
Reconciliation gets treated as a nightly batch afterthought. Elevating it to a first-class service changes what the rest of the platform can guarantee.
Every payment API documents idempotency keys. Every payment platform gets some of the details wrong. A pattern guide.
Event sourcing is often oversold. For a payment transaction platform, though, its properties align well — with some carve-outs.
Full reversals are well-covered in most integrations. Partial reversals are where the design assumptions leak.
One database can serve both operational and reporting queries — until it can't. Where the split should go and how to build it.
Sharding a database is often the wrong first move. When it isn't, the choice of shard key is the decision you can't undo.
Settlement batching sounds like accounting. It's actually a distributed systems problem with financial-grade correctness requirements.
Cross-region failover for a payment platform has different constraints from a general web application. What the design has to preserve.