For anyone building the software that takes orders by phone, document or booking. Shuttle, September 2026.
The order goes through perfectly right up until the money. Your new AI agent takes it, checks the details, works out what happens next, and then tells the customer to go somewhere else to pay. Or it will, the day you turn it on.
If your software takes orders from customers, this gap is going to reach you sooner than your roadmap assumes, whatever shape those orders arrive in. A call to the counter. A load booked at short notice. A document that turns into an order in your system with no payment attached to it.
It will not arrive labelled as a payments problem. It shows up as a complaint that the new AI never finishes the job.
We build the payment layer underneath software platforms, so we see the end of those orders often. It is the part nobody scopes.
The orders that never went through a web page
A site manager calls the distributor because the part is urgent and the catalogue is wrong about what is in stock. A shipper calls to move a load today, having never shipped with this carrier before. A customer approves a quote over the phone, and the shop will not cut metal until the deposit is in. The business changes. The shape of the call does not.
Your software holds the order, the load, the job. It has never held the payment for any of them. Somebody keys the card into a virtual terminal in another browser tab, or takes it at the counter when the customer collects, or raises the 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, and in this part of the market for a better reason than most. Orders here were mostly settled before they came in. A credit account with terms. A rate agreed months ago. A repeat job on terms already agreed. In all of those the money is already arranged, and the order only has to be billed.
What was left over was a small pile. The buyer with no account. The spot load from a shipper nobody has credit checked. The one-off job that needs a deposit before material is ordered. Small enough to tidy up by hand, so it was.
AI removed the reason the pile 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 at the parts desk get answered. Calls that used to end with "try us in the morning" end with an order on the system.
So the pile stops being small. And it will not grow evenly. You would expect the new calls to skew toward callers with nothing arranged in advance, since they would have been the likeliest to hang up and try somewhere else. The first-time buyer. The spot load. The job from a name nobody recognises.
Your platform is the thing growing that pile, because the AI your customers keep asking you for is a machine for turning enquiries into orders your product cannot take the money for.
And they all end at the same place. The order exists, 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 before the pick list goes out. Take the order and get the card later, when the customer collects or the truck arrives. Hand the call to somebody on the desk 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 numbers 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, with a reference typed in off a gateway screen your product never saw. That is business completing outside 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 moving inside the platform
The counter got a card reader wired into the same product that holds the inventory record. The orders that used to arrive by fax, then by email, then as a PDF attachment, now get read and turned into real orders in the same list as everything else. Field trucks carry card readers, so the money can be taken at the door on the job your software dispatched.
That work is already happening everywhere else for a plain reason. When the money moves outside the product, the record of it moves outside too, and the customer ends up opening something else to find out what really happened.
The conversation 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.
If you already turned documents and emails into orders without a person reading them, the phone is what is left. That is the part this is about.
Which is why this is not a sprint
The conversation is not the difficult part. The difficulty 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. Most of them have had it a long time and will not move it to suit a software release. 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. Take a live call as the hard version of it, because that is the one where the customer is waiting and the product has nothing to offer.
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 order 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 order lands like every other order, paid and ready to pick or schedule, has done for the conversation what the card reader did for the 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 AI taking orders somewhere on it. Check whether anything on it takes the money.
If your product takes orders 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