Written for teams building ERP, practice management, property management and field service software. Shuttle, September 2026.
The call goes perfectly right up until the money. Your new voice agent books the appointment, checks the calendar, confirms the address, and then tells the caller to go somewhere else to pay. Or it will, the day you turn it on.
If you build software where orders, appointments and reservations arrive by phone, that gap is going to reach you sooner than your roadmap assumes, and it will not arrive labelled as a payments problem. It will arrive as a complaint that the new AI agent does not finish the job.
We build the payment layer underneath software platforms, so we see the end of that call often. It is the part nobody scopes.
The phone never stopped taking orders
A patient rings the practice to move an appointment. A guest rings the hotel because the website says nothing about whether the dog can come. A site manager rings the distributor because the part is urgent and the web catalogue is wrong about stock.
Your software holds the appointment, the reservation, the order. It has never held the payment for any of them. Somebody keys the card into a terminal, or takes it at the counter later, or sends an invoice and waits. Then somebody opens your product and marks the order paid, so the record agrees with money that arrived somewhere else.
That workaround has lasted for years for a plain reason. A phone call needed a person, people cost money, and businesses spent a long time pushing customers to a web page instead. Phone orders stayed a trickle, and a trickle can be tidied up by hand.
AI removed the reason the phone stayed small
An AI agent can answer every call, at any hour, and the cost of the next call is close to the cost of the last one. Calls that used to ring out get answered. Calls that used to end with "can you try us tomorrow" end with a booking.
So the trickle stops being a trickle. And your platform is the thing increasing it, because the voice agent your customers keep asking you for is a machine for turning phone calls into orders your product cannot take the money for.
And those calls all end at the same place. The agent has the order, and the payment has to happen somewhere your software is not.
The handoff is a product problem, not a payments problem
You already know the options, because your customers are using them right now.
Send a payment link and hope it gets opened. Take the booking and get the card on arrival. Transfer the call to a person so they can do the part the AI could not. Every one of those is your software saying out loud that it cannot finish what it started.
The cost of that does not show up where you would look for it. Nobody cancels a subscription over this. The customer stays, the data keeps syncing, the seats keep renewing. What moves is the moment the sale actually completes, and with it the payment, the record of who bought, and the data the reports in your product are built from.
Go and look at the orders in your own system that somebody marked as paid by hand. That is the phone, quietly taking business out of your software, in an amount nobody has measured because nothing in the product raises a flag about it.
Every other place an order gets taken is already inside your platform
The shop counter got a card reader wired into the same product that held the catalogue. Marketplace and social orders got pulled into the same order list as everything else. Your platform did that work already, because a business that does not own the moment of payment does not stay the centre of anything for long.
The phone is the one place that never came inside. Not because nobody noticed it. Because taking a card inside a conversation needed a trained person at one end, and a compliance programme most software companies had no reason to start.
The person on that call is turning into software. That part of the problem is going away. The rest of it has not moved.
Which is why this is not a sprint
The hard part was never the talking. The hard part starts the moment a card number exists anywhere near your infrastructure. The moment card data enters your own systems, your product, your logs, your call recordings, it is in scope. So is everyone who supports any of it. An AI on the call that transcribes and keeps what it hears makes that harder rather than easier.
The one that gets scoped last: every customer on your platform already has a payment provider, with their own rates, their own contract, and usually a finance team that chose it. You cannot put all of them through one of yours. Whatever you build has to let each of them keep what they have, per customer, from the first line of the design. That is not something you bolt on afterwards.
What finishing the call actually means
Built, bought or partnered, the test is the same.
The payment completes inside the call. No trip to a screen at the moment the customer is most willing to pay.
The card never reaches your product, your logs, or the model on the call. That limits your scope and your customers'. It does not remove a business's own duty to check its own compliance, and nothing does.
Each customer keeps their own payment provider.
The order lands back in your product already paid, with the customer attached, so nobody marks it paid by hand afterwards.
The last of those is the one that decides whether the phone belongs to your product or to somebody else's. A platform that takes the money but does not record the order has added a payment feature. A platform where the phone order lands like every other order has done for the phone what the card reader did for the shop counter.
Where we come into it
We built the payment side of this, so here it is, briefly. Shuttle is a payment layer for software platforms, AI agents and merchants. Platforms use it to take the payment inside a call, whether a person or an AI agent is running the conversation, with each of their customers on their own payment provider, where that provider supports payment in a call. It works with Twilio today, and any carrier coming soon. The result comes back through our API, and your product records the order as paid. We hold PCI DSS Level 1 ourselves, so platforms don't have to build and certify a Level 1 payment system of their own. Your own compliance duty doesn't go away. Its scope gets smaller, because the card never enters your systems.
That is the whole pitch, and you can ignore it.
The decision underneath it is the same either way, and most platforms have not made it. Not making it is not neutral: your customers are wiring that part up themselves at the moment, and once it works for them, they stop asking you for it. Your roadmap almost certainly has a voice agent on it. Check whether it has the rest of the call.
If you run a platform and this is on your roadmap, reply to the email that sent you here, or write to nick@shuttleglobal.com.
Security and compliance detail: docs.shuttleglobal.com/docs/org-security