Your merchants take orders and chase payment on the phone. That call is already being handed to AI. Whoever supplies the payment inside it ends up further into your merchant's operation than you are.
Who this is for. Product, partnership and technology leaders at mid-market ERPs serving manufacturing, distribution, wholesale and field service.
What it argues. You already sell payments. You sell them for the invoice and the web. The phone, where orders and collections in these verticals still happen, has never had a checkout, and it is the channel now being automated.
What it is not. Not a compliance paper. Card security matters here and it is a consequence, not the argument. This is about who owns a channel.
Every function in an ERP closed its loop except one
Collection still leaves the system and comes back as reconciliation.
Start with what you have already built, because most papers like this pretend you haven't. Plenty of ERPs in this market sell payments today. Some own a branded payments product. Some embed processing and resell it to their merchants as a revenue line. Others run an extension marketplace where gateway partners connect, or have a named partnership with an acquirer. This is a mature capability and it is not the gap.
The gap is that all of it was built for one shape of transaction: a customer who is looking at a screen. An invoice with a pay link. A portal. A checkout embedded in a web order. When the buyer is on a screen, the loop closes cleanly. The order, the payment and the ledger entry are the same event, and reconciliation is automatic because nothing ever left the system.
Now consider the order that arrives by telephone, which in distribution, wholesale, manufacturing and field service is not an edge case. It is a trade counter calling to reorder, an account customer querying an invoice and agreeing to settle part of it, a service engineer's customer paying on the doorstep. Those conversations end in money, and they are the ones your platform handles worst.
The web order, where the loop closes. Order placed, invoice raised, pay link or embedded checkout, payment captured, invoice settled in the ERP. Everything happens inside systems you control or integrate. Nothing has to be matched back to the invoice by hand.
The phone order, where the loop breaks. Customer calls, order taken, invoice raised, and then the payment leaves the system and returns later as reconciliation. Someone reads a card down the line and keys it into a terminal. Or a link is emailed and the call ends with the money still uncollected. Or it goes to a portal, an AP tool, or a person with a spreadsheet. The order lived in your platform. The payment happened somewhere else, and had to be matched back by hand.
The phone never got a checkout the conversation can use
This is not an oversight by your engineering team. It is decades of history, and every step in it was defensive rather than designed.
Cards have been accepted over the phone since the catalogue era, by the crudest available method: the customer reads the number aloud and somebody types it in. Automated phone systems became standard in call centres through the 1990s, but rarely for cards and never as a checkout. What eventually forced automation was the arrival of the card industry's security standard in 2004, which turned reading a number to a stranger into a liability. The industry's answer was keypad entry and masking, ways to stop a person hearing the digits.
Notice what that is. Every advance on this channel answered an obligation. None of them was an attempt to build a checkout. The web got a checkout. The app got a checkout. The phone got payment lines you transfer the caller to, and ways to make the existing mess safer, with a human still sitting in the middle of it.
That is why an AI voice agent can hold an entire conversation about an order and then stop dead at the payment. There is no checkout there for it to use.
The recipe is not in the gallery
209. Public Make templates across nine accounting and invoicing platforms: QuickBooks, Xero, Sage Accounting, Zoho Invoice, Zoho Books, FreshBooks, Invoice Ninja, Invoiced and GetMyInvoices. Not one records a payment against an invoice. They create invoices, email them, sync contacts and copy records between systems. None marks an invoice paid.
Every blueprint read, 9 September 2026. This describes Make's public template gallery on that date. It says nothing about the connectors available, what integrators build privately, or what any other iPaaS gallery contains.
The same gallery holds more than 8,000 templates, across more than 1,000 apps, and mid-market ERP is effectively absent from it: no Dynamics 365, Business Central, Acumatica, Sage Intacct or SAP templates at all; one NetSuite template, which downloads a file; five Odoo templates, all of them CRM lead capture. Make publishes working connectors for most of those platforms. NetSuite, SAP, Sage Intacct and Business Central all have one. The connectors exist. The recipes do not.
Read that as opportunity rather than absence. The plumbing for this category is available and nobody has published it as a recipe a merchant can turn on. There are dull explanations for part of that. Several of these connectors sit on Make's enterprise plans rather than its free tier, which makes the point rather than answering it: a connector available only on an enterprise plan is not a recipe a mid-market merchant can turn on. In the self-service tier this ground is unclaimed.
The call is being automated, with or without you
Phone work in these verticals is moving to AI voice agents: order taking, delivery queries, invoice chasing, arrears conversations. The economics are obvious and the tooling has moved far enough that putting an agent on a trade counter line is no longer a research exercise.
Which produces a very specific problem, and it lands on you.
The agent handles the whole conversation. Identifies the account, finds the order, confirms the price, agrees the terms.
It reaches the payment and cannot complete it, because the channel has no checkout.
So the voice vendor solves it. They have to. An agent that cannot finish the job is a demonstration, not a product.
They bring their own payment provider, and with it their own merchant relationship, their own reporting, and their own view of the transaction.
Your merchant now has an operational system that takes orders and money, sits in front of the customer daily, and is not yours. The invoice still lives in your ERP. The moment of sale does not.
This is the same sequence that has played out on every channel your platform has ever lost. Not a competitor arriving and beating you. Something adjacent solving an inconvenience, then expanding from the beachhead because it was already there and you were not.
Why this is not the build-versus-buy call you made last time
Most ERPs in this market have already decided, correctly, that they can build a payment link. It is a form, a redirect and a webhook. If that is the decision in your head as you read this, it is worth being explicit that it is a different decision.
Taking a card inside a live conversation means the digits must reach the gateway without reaching a person, the recording or your platform, while the call stays up and the caller stays with you. That is a capture layer, not a form. It needs a connector for each payment gateway your merchants use, and they are not all on the same gateway, which is what turns this from a sprint into a programme.
You do not need to build that any more than you built the card networks. What matters is whether the capability appears inside your platform, sold by you, or arrives beside it, sold by somebody else.
The channel, not the payments
The opportunity is not to become a payments company. It is to be the platform that lets a merchant turn its phone line into a place orders get completed, and to sell that as part of what your ERP does.
Practically, that means the payment happens inside the call, the invoice is marked paid in your system while the customer is still on the line, no member of staff handles a card number, and in many cases a merchant's existing payment provider can stay in place. That last point matters more than it sounds. Your merchants have acquiring relationships, rates and settlement arrangements they will not abandon to adopt a feature, and any approach that requires them to switch will stall in exactly the accounts you most want.
Four questions worth answering
What proportion of your merchants' orders and collections still happen on a call? Ask three of them rather than estimating.
When a customer agrees to pay during that call, what happens next? If the answer involves reading a number aloud, sending a link, or "we'll invoice you", the loop is open and the money is arriving later than it needs to.
Which of your merchants has already deployed an AI voice agent? Whoever supplied it is now one integration away from supplying their payments too.
Could your merchants adopt in-call payment without changing provider? If it requires them all to move to one provider, it is a migration project. If most can keep the provider they are already on, it is a far shorter conversation.
Run these questions with us
Those four questions are worth answering with real numbers rather than estimates.
We will go through them with your team. If the answers say there is nothing here for you, that is a useful result too.
About Shuttle
Shuttle is a payment execution layer for software platforms. It sits above the payment gateways and PSPs rather than replacing them, so a platform can offer payment inside a live call and, in many cases, a merchant's existing provider can stay in place. Voice capture works with Twilio today, and any carrier coming soon. We work with software platforms whose merchants take card payments over the phone today.
On the evidence in this paper. The template counts describe Make's public gallery on 9 September 2026, verified by reading every blueprint returned. They describe what is published, not what is possible, and not what integrators build privately.