Embedded Payments vs. Integrated Payments. What’s the Difference?

As the idea of delivering payments through software platforms has picked up steam, the options available to companies that want to create that experience have evolved rapidly to meet the demand. That means that new models and terms have arisen quickly. Keeping up with the developing space can be confusing.

Take the terms integrated payments and embedded payments. They sound similar. And they describe similar concepts. But understanding the difference between them is key to understanding the approaches to the space that are available right now.

The two terms represent different points on a continuum of software-led payments – in terms of both customer experience and the level of connectivity with the software platform.

What’s the difference between embedded payments and integrated payments?

Disconnected payments

It’s easiest to start at the disconnected end of that continuum, where software platforms and payments are two completely separate processes. At this end, as a software provider, you give your customers the specialized tools they need to run their businesses, allowing them to schedule bookings, manage field employee schedules, and the like.

Payments in this case are handled outside the software by third-party payments providers. Your customers use manual processes to reconcile their payments with their software. You might refer your customers to payments providers with whom you have a relationship and receive a referral fee in return.

Integrated payments

Integrated payments are where the idea of software-led payments begins. Payments and software are still handled by two separate providers, but their systems are communicating through APIs, and the payments can be reconciled with the software system through automation.

At the integrated level, the connection is visible to the end user. The business can accept payments through your system, but still creates an account with and receives payments support from a third-party payments provider.

This is certainly more convenient than having the systems remain separate, and it’s a better experience for the end user.

Embedded payments

But embedded payments take that useful concept even further.

Rather than connecting a software platform to an outside provider to provide payments, payment-acceptance capability is built directly into – embedded into – the software platform. This makes the connection between software and payments essentially invisible to the end user.

And instead of contracting with a separate provider to accept payments, the merchant contracts with you. You create the onboarding process and user experience that fits your customers best, and you manage the customer service, with complete visibility into the information you’ll need to solve any issues.

Another real-life example

This evolution is the latest example of using technology to bring together separate but related experiences. Similarly, you can think about how navigation has changed. When we had to rely on a road atlas to get around in a new location, the car and the map were two very different and separate pieces of the process.

With the advent of GPS systems, the process of navigating when you drove became much easier. You could opt for a third-party system that sat neatly on your dash and charged using your car’s power. It told you where to go, turn by turn, bringing navigation much closer to the process of driving. An integration that made the experience more convenient, for sure.

But then navigation became even more embedded into the driving process. Rather than being something you attach to the car, it was built into your car. A window on your dashboard displayed your map and was always available – no separate system necessary.

Back to payments. The vision for an embedded experience is often expressed with the example of rideshare companies like Uber and Lyft. Paying for the service is seamless – you finish your ride and go about your day without having to tack on the clunky experience of pulling out a card or cash at the end of the ride. Payment simply happens in the background automatically.

Why does the difference matter?

This evolution has bold implications for companies and end users alike.

Embedded payments are simpler and more efficient for the end users. The experience is uninterrupted. It requires fewer steps.

For the supplier, it means a closer relationship with their merchant customer. It enables them to avoid sending that customer elsewhere for services they need.

It also means more revenue. The more embedded the experience, the less of the revenue goes to a third-party provider. Software providers often see a 30-50% revenue share with their payments provider in an integrated model, whereas companies that own the payments process get to keep 100% of the payments proceeds and count it as topline revenue.

Embedded payments are also a first step on the way to delivering even more financial services – such as lending or insurance – through software platforms, opening up a whole world of possibilities.

So what should software companies do?

Deciding how payments will best fit into your software platform depends on a number of factors. You should consider how enabling payments acceptance relates to your strategy. You should also weigh how your approach to payments might evolve as you scale.

No matter what route you choose, resources are available to help streamline the process of adding payment capabilities to your platform.

Contact an expert at Infinicept to learn more about the different payment models, how they might fit into your strategy, and the support that is available.