Payment as a Feature vs Payment as a Product

I posted something on LinkedIn this week about an idea I’ve been thinking about quite a bit lately: the difference between payment as a feature and payment as a product. I thought I’d share the longer version here because, the more I think about it, the more it connects to how my own understanding of product has changed over the last few months.

It’s been a little over seven months of working in payments, first as a Product Designer and now, more recently, as an acting Product Manager. Before this, most of my product experience was around supply chain and business software. In those products, I often thought about product in terms of the features we were building: what should the user be able to do, what should the workflow look like, and how do we make the experience better?

Working around payments has made me look at that differently.

I’m beginning to realise that a product can have a lot of payment functionality without necessarily treating payment as a product. You can build checkout, refunds, transaction history and dashboards and still be thinking about payment mainly as a feature that sits inside a bigger product.

The distinction, at least from what I’m learning, seems to be more about responsibility than functionality.

A payment feature helps your product accept money. A payment product has to think about what happens to that money throughout its journey: from when the payment is initiated, to when it is authorised, processed, confirmed, reconciled and settled. And importantly, it has to account for what happens when something goes wrong.

That last part has probably changed my thinking the most.

A successful payment is only one possible outcome. What happens when a transaction fails? What happens when the customer says they were charged but the merchant can’t see the payment? What happens when settlement doesn’t match expectations, or a payment rail goes down?

These aren’t just things around the product that someone needs to deal with later. They are part of the payment experience itself.

It also gets interesting when you look at the payment ecosystem. A merchant is building a payment experience for its customer. A payment provider is building a payment product for the merchant. Underneath that, payment rails provide the infrastructure that makes the whole thing possible.

Each layer has a different idea of what “payment working” means.

An API can return a successful response, for example, while the business is still asking very basic questions: Did the money actually move? When will it settle? What happens if it doesn’t?

That’s why I’m starting to think that merchants don’t necessarily care about things like “payment orchestration” in themselves. They care about a much simpler outcome: my customer paid me, and I know exactly what happened afterwards.

The more I learn about payments, the more I’m convinced that this is where the difference between a payment feature and a payment product becomes clearer.

It isn’t just about getting the payment through.

It is about taking responsibility for everything that happens around it.

And maybe that is also why the usual “build versus buy” question doesn’t quite capture the problem. You can buy the infrastructure. You can outsource the processing. You can use someone else’s rails.

But can you outsource responsibility for the experience your customer has?

I’m still thinking through that question, but seven months into working in payments, it’s one of the ideas that has changed how I think about product the most.