Payments Patterns: Elements of Reusable Money Software

Laying the foundations for a builder-centric catalog of payment methods

What’s the most underrated software book? It’s Gang of Four’s Design Patterns.

It carries the most powerful mindset of all. That there are things about software that we can repeat—a meta-level of software development. And we can repeat those things because they work.

Patterns are to software what software is to the world.

Your payments systems could benefit from noticing the regularities you encounter when you build it. In fact, many industry veterans have already realized that payment methods can be catalogued.

For example, Sophia Goldberg has a talk where she describes a “non-card taxonomy”: Bank-based (like ACH), Delayed payments (like BNPL), Wallets (like store credits), and Cash (like… cash).

This perspective is business-oriented. It’s useful for users and for those who talk to those users. But this perspective is irrelevant for builders of money software.

How is separating ACH from BNPL helpful for engineers? How is integrating with FedNow and Klarna different?

This taxonomy provides no answers. It’s valuable for users, but pointless for builders.

Instead, payments engineers must approach existing and future payment methods from a new perspective. One that’s tech-based. So that they can group payment methods in ways that make the process of implementing integrations easier.

Such a set of payment patterns is needed. This is The Payments Engineer Playbook, and this week, we’re learning a new taxonomy of payment methods.

One that’s builders-centric.