Your customer runs a transaction on Tuesday. On Thursday, they want to know whether the payment cleared and when the money lands in their account.
Where do they go?
Send them to a separate portal with its own login and its own interface, and you have taught them who actually holds the answers. It is not you. That gap between accepting a payment and explaining it is the next real opportunity in embedded payment reporting, and most platforms have not closed it.
When Did Embedded Payments Stop at the Checkout Box?
The first wave of embedded payments solved acceptance. Drop in a checkout, take a card, move on. It worked, and it worked well enough that payment acceptance is now table stakes rather than a differentiator.
Everything downstream stayed with the processor: transaction lookup, deposit timing, reconciliation. All of it lived in a portal your customer had to be told about, trained on and reminded of. Your support team has reset passwords for a system you do not control. Your engineers have answered questions about money your product never sees. The payment motion became part of your product. The money never did.
Meanwhile, the software platforms winning in their verticals stopped treating their customers as software users and started treating them as businesses with money to manage. McKinsey research published in January 2026 tracks how leading platforms have expanded from transaction acceptance into accounts payable and receivable automation, invoicing, tax management, payroll and finance-grade reporting. It values the market for small and medium business financial management services in the United States at $120 billion, well beyond what traditional transaction income generates, and its conclusion is direct: back-office services increase customer lifetime value and loyalty.
That finding covers back-office financial services broadly rather than reporting specifically. Reporting is simply the piece of it sitting closest to the payment you already process, which makes it the cheapest place to start and the first thing your customer notices when it is missing.
Payment visibility is part of running a business.
What the Reporting Gap Costs You
Sending customers elsewhere for answers is not a neutral choice. It costs you in three specific ways.
- Support volume you did not create. Your team fields questions about settlement timing, batch totals and missing deposits, then relays them to a processor. You absorb the ticket without owning the answer. Pull your average time to resolution on payment-specific tickets and see what that queue actually costs you
- A product experience that breaks at the seam. Every handoff to an external portal reminds your customer that your platform is one tool among several, not the system of record. Think about the last time one of your own purchases jumped to a differently branded tab, and how quickly you wondered whether something had gone wrong
- A payments relationship credited to someone else. When customers log into a processor portal to check their money, they associate the payments experience with that brand. Come renewal season, that turns payments into a reason to shop competitors instead of a reason to stay
The third cost is the one worth sitting with, because it compounds quietly. Payments is the most frequent interaction your customer has with money inside your category, and whoever renders that interaction earns the credit for it. If the answer to “did I get paid” arrives on someone else’s screen, your platform becomes the place work happens and their processor becomes the place money happens. Those are not equal positions. A platform where work happens is replaceable by a competitor with a similar feature set. A platform where money happens is a system a business does not casually move. Every quarter you leave reporting outside your product, you are building that equity in someone else’s brand, using your own customers to do it.
The demand signal is not subtle. Research from S&P Global Market Intelligence 451 Research found that half of small and medium businesses say their organization would run more efficiently if financial services were better integrated with their business software. That is half your customer base telling you the gaps between the tools they already use are costing them time.
The upside is harder to measure directly, but the direction is consistent. In a PYMNTS Intelligence study of U.S. marketplace executives, 64% reported that embedded finance tools reduced churn and 51% said those tools opened new revenue streams. That research covers embedded finance broadly and a marketplace audience rather than vertical software, so read it as directional rather than a forecast for your own numbers. What it establishes is that moving financial experiences inside the platform tends to move retention and revenue together.
What a Complete Payment Experience Looks Like
A complete embedded payments experience answers three questions inside your product, in your branding, without a redirect:
- What did my customer pay, and did it go through
- When was it processed
- When does the money arrive
That means three capabilities working together: payment acceptance, transaction history and deposit reporting. Acceptance alone gets you a checkout. Add transaction history and your customer can research a charge, confirm a refund and answer a dispute from one of their own customers without leaving your platform. Add deposit reporting and they can forecast cash flow, reconcile their bank statement and stop calling you to ask where their money is. For a customer running a clinic, a contracting business or a property portfolio, that visibility is not a reporting feature. It is the difference between trusting your platform with their money and merely processing through it.
To show what embedded payment reporting looks like in practice, I built a working sample: a fictitious veterinary platform called Fennec, with all three components integrated.
Here is what that took. The install was two packages, nmi-pay-react for the payment component and nmi-reporting-react for transaction history and deposit history. Around them sat a standard Vite, React and TypeScript scaffold with a small Express development server.
Two things needed wiring. The first was a single theme file mapped into NMI’s Appearance API, which let every component pick up the host application’s colors, corner radii and type without any per-component styling. The second was a minimal backend so the private API key never reaches the browser, tokenizing on the client and charging on the server.
The components were not the slow part. Total project time ran about three and a half hours from first commit to working demo, including dry runs and iteration, and roughly 90 minutes of that was hands-on work. What took longest was the branding and theming pass to make the result presentable, matching layout, spacing and interaction states. Integrating the payments components themselves moved quickly.
Here is how a pet owner pays Cedar Hollow Animal Hospital for a wellness visit inside Fennec.
The practice sees that payment in their own Fennec portal, with no second login and no handoff.
They track deposits the same way, without leaving the Fennec experience.
You Don’t Have to Build It All at Once
The reason more platforms have not closed the reporting gap is rarely that they disagree with the argument. It is that payments infrastructure is a large commitment, and reporting infrastructure means data pipelines, settlement logic and a user interface nobody on your roadmap has budgeted for. The way through is to stop treating it as one decision. A modular payments architecture lets you start with hosted, no-code acceptance to prove demand, move to drop-in components when you want branded control, then graduate to full application programming interface (API) access when your requirements outgrow anything prebuilt. You can start with a single component and add the others as the revenue justifies it, which lets you match investment to evidence rather than committing engineering quarters to a bet you have not validated.
That is what our Embeddable Component Suite is built for. It gives you three low-code, drop-in components covering payments, transaction history and deposit history. A single appearance configuration styles all three, so they look like part of your product rather than a bolted-on frame. Your developers can install a component, customize the look and feel, then start testing in a free sandbox before anyone signs a contract. Our documentation is built to be read by AI coding agents as well as people, and a new Integrations MCP (Model Context Protocol) lets a coding agent build and test against your sandbox directly.
Most software platforms do not lack the ambition to own payments. They lack the time, the engineering capacity and the payments expertise to build all of it themselves. A single component closes more of that gap than most teams expect.
Own the Whole Payment Experience, Not Just the Checkout
What happens after acceptance is still an open question in most software products, and it is the part your customers think about every day. Close that gap and you reduce your team’s support load, strengthen your customer relationship and earn a share of the payment revenue already flowing through your platform. Leave it open and you keep sending your best customers somewhere else to answer their most important question.
The Embeddable Component Suite is available now through our integration portal, alongside developer documentation, a free sandbox, use case guides and interactive pricing. Start building at nmi.com/dev-experience.
