Shipping Payments Products That Actually Go Live

In payments, the lifecycle is the product

A payment isn't a transaction; it's a lifecycle. A SEPA Direct Debit has mandates, presentations, reversals, refunds, and R-transactions. SWIFT has its own series of MT103, MT202, MT202COV messages, each with rules about what happens when something goes wrong. When I built the full SEPA solution and later the SWIFT GPI offerings, the product wasn't the success case, it was every event and exception across the lifecycle, modelled correctly.

If you design only for the green path, you ship a demo. If you design for the whole lifecycle, you ship something a bank can actually run.

Roll-outs are where the real requirements show up

Launching payments end-to-end in the UK, Europe and Asia in a SaaS model taught me that the most important requirements are the ones nobody writes down until go-live. Geographic domestic schemes, BACS and CHAPS quirks, clearing windows, message format variations, these surface during implementation, not discovery.

That's why I stay close through delivery. The PM who hands off after the spec misses the part where the product is really decided. I'd rather be in the room when a message fails validation at 11pm than read about it in a defect report the next morning.

Migration is a feature, not an afterthought

One of the roll-outs I led involved migrating a digital channel product in Asia with more than 6 TB of data and 2 million users. Migration is where ambitious products quietly die. Nobody celebrates a data migration, but get it wrong and none of the elegant features matter, because customers can't see their own balances.

So I treat migration as a first-class part of the product: reconciled, rehearsed, and reversible. The boring discipline of getting data across cleanly is what lets the exciting part go live at all.

What I carry into every launch

Build for the full lifecycle, not the demo. Expect the real requirements to appear at implementation. Treat migration and exceptions as core features, not chores. And stay with the product until it's actually running in production, because in payments, "it works in the sandbox" and "it's live" are two very different sentences. Being a finisher is just refusing to confuse them.