The Payment Problem Every Food Ordering Platform Hits
Whether you're building a voice AI ordering system, a chatbot that takes orders via WhatsApp, a delivery marketplace, or a ghost kitchen management platform — you hit the same wall once you have more than a handful of restaurant clients:
Every restaurant uses a different payment processor.
Restaurant A is on Toast. Restaurant B uses Square. Restaurant C has a Worldpay merchant account. Restaurant D processes through Stripe. Restaurant E is on Clover with Fiserv.
If your platform processes all orders through your own Stripe account, you're adding fees on top of what restaurants already pay their existing processor. The restaurant pays twice — once for your platform's Stripe fees, and again when reconciling against their POS settlement.
If you try to integrate with each restaurant's processor directly, you're building and maintaining 5, 10, 15 separate PSP integrations — each with different APIs, different webhook formats, different error codes, and different settlement timelines.
Neither approach scales. The first creates merchant friction. The second creates engineering debt that never stops growing.
Who This Affects
Voice AI Ordering Platforms
Companies like SoundHound, ConverseNow, Kea, Loman, VOICEplug, Checkmate, and Tarro are automating phone orders for restaurants. They handle the order. They struggle with the payment.
Most fall back to SMS payment links (breaking the voice experience) or route orders to the POS for pay-at-pickup (losing the prepayment guarantee). The payment capture problem is covered in detail in How Voice AI Ordering Platforms Handle Payments.
Chatbot and Messaging Ordering
Platforms that let customers order via WhatsApp, Instagram DMs, Facebook Messenger, or SMS. The order happens in the chat. Payment needs to happen there too — typically via a payment link sent in the conversation.
The link needs to process through the restaurant's PSP, not the chatbot platform's Stripe account. And the link needs to be branded appropriately — the customer should see the restaurant's name, not a generic checkout.
Delivery and Marketplace Platforms
Online ordering platforms (beyond the major aggregators like Uber Eats and DoorDash) that serve independent restaurants, regional chains, or specific cuisines. These platforms collect payment from the diner and settle with the restaurant — but each restaurant's settlement requirements differ.
Some want funds in their Toast account. Some want bank deposits via their Worldpay settlement. Some want separate settlement for delivery vs pickup orders.
Ghost Kitchen and Virtual Brand Operators
A ghost kitchen runs 5 virtual brands from one physical location. Each brand may have its own:
Merchant account (different legal entities or tax structures)
PSP (different processors per brand or per delivery partner)
Settlement requirements (different bank accounts, different settlement frequencies)
Processing all brands through one account creates accounting complexity, tax issues, and reconciliation headaches. Multi-brand operators need sub-merchant routing — each brand treated as a separate merchant within the platform.
Restaurant Management Platforms
Software that manages operations across multiple restaurants — POS systems, kitchen display systems, reservation platforms, inventory management. When these platforms add payment capabilities (payment links for phone orders, online ordering, or invoice payments), they need the payment to work with whatever processor each restaurant already uses.
What Food Ordering Platforms Need From Payment Infrastructure
Multi-PSP Routing
The platform integrates once. Each restaurant is configured with its existing payment processor. When a customer pays — whether by voice, chat, payment link, or embedded checkout — the transaction routes to that restaurant's PSP.
Adding a new PSP (because a new restaurant client uses a processor you haven't supported before) is a configuration change, not an engineering project. See PSP-neutral vs single-PSP architecture for the detailed trade-off.
Payment Capture Across Channels
Food orders come through multiple channels:
**Phone** — still the dominant channel for independent restaurants. Needs PCI-compliant voice payment capture or a payment link sent mid-call.
Web and app — embedded checkout on the platform's ordering page or the restaurant's own website.
Messaging — WhatsApp, SMS, Instagram DMs, Facebook Messenger. Needs payment links that work in-chat.
**AI agents** — voice bots and chat agents that handle orders autonomously need to trigger payment capture mid-conversation.
All channels should route through the same PSP configuration. A card captured over the phone should reconcile in the same system as an online order. The restaurant shouldn't need to check two dashboards.
Merchant Onboarding at Scale
Onboarding 50 restaurants per month means 50 merchant setups — each potentially with a different PSP, different settlement account, different branding requirements. Manual onboarding doesn't scale.
White-label onboarding flows — branded as your platform, not as a third-party payment provider — let restaurants connect their existing PSP credentials, configure their settlement preferences, and go live in minutes rather than days.
Sub-Merchant and Multi-Brand Support
Ghost kitchens, franchise groups, and multi-location operators need payments routed at the brand or location level — not aggregated into one account.
A ghost kitchen with 5 brands needs each brand's payments settled separately. A franchise with 200 locations needs per-location PSP configuration. The platform needs group-level reporting across all brands and locations, while each entity maintains its own payment identity.
Platform Revenue Model
Payment infrastructure shouldn't just be a cost. Platforms that route payments through a payment layer can earn revenue share on every transaction — turning the payment flow into a revenue line alongside subscription fees and order commissions.
For a platform processing 100,000 orders per month at an average of £15, even a small per-transaction margin adds up. See how platforms monetise payments for the full commercial model.
The Build vs Buy Decision
What building looks like
A food ordering platform that builds payment infrastructure in-house faces:
Multiple PSP integrations. Toast, Square, Stripe, Worldpay, Adyen — each is a separate API integration with different data models, webhook formats, and authentication mechanisms. Supporting 5 PSPs means 5 codebases to build and maintain.
PCI compliance. Any platform that handles card data — whether through a web checkout form, a voice channel, or a payment link — has PCI DSS obligations. The scope depends on architecture, but for platforms handling voice card capture, PCI compliance is a major infrastructure and audit commitment.
Merchant onboarding. Building a white-label onboarding flow that connects restaurants to their existing PSP, validates credentials, and configures settlement is product work that doesn't generate revenue directly.
Ongoing maintenance. PSP APIs change. PCI standards evolve (4.0.1 is now enforced). Payment methods expand (Apple Pay, Google Pay, Pay by Bank). Each update requires engineering attention.
The typical timeline: 6-12 months to build a basic multi-PSP integration, with 2-4 engineers permanently allocated to maintenance. That's engineering capacity not spent on ordering AI, menu management, or restaurant experience — the things that differentiate your platform.
For more on this trade-off, see how to get payments off your product roadmap.
What buying looks like
A payment layer provides multi-PSP routing, payment capture across channels (voice, web, links, chat), merchant onboarding, and PCI compliance through a single API integration.
The platform integrates once. The payment layer handles PSP connectivity, PCI scope, and settlement routing. Each restaurant uses its existing processor. The platform earns revenue share on transactions.
Integration timeline: 2-4 weeks. Ongoing maintenance: zero dedicated payment engineers — updates to PSPs, PCI compliance, and payment methods are handled by the payment layer.
Payment Methods for Food Ordering
Beyond standard card payments, food ordering platforms increasingly need:
Apple Pay and Google Pay. Mobile wallet payments have the highest conversion rates on mobile — and most food orders happen on phones. Wallet payments should be available on payment links, embedded checkout, and in-app flows.
Pay by Bank (Open Banking). For higher-value orders (catering, large group orders, B2B food ordering), Pay by Bank offers lower fees than card processing and instant settlement. Particularly relevant for business catering platforms and wholesale food ordering.
Cash on delivery tracking. In some markets and for some restaurant types, cash remains common. The payment platform needs to track cash orders alongside digital payments for accurate reporting and reconciliation — even though it doesn't process the cash transaction.
Split payments. Group orders where multiple people pay their share. The platform needs to generate multiple payment requests for a single order, each processed independently.
FAQ
Do we need to be PCI compliant if we use a payment layer?
If the payment layer handles all card capture (web checkout, voice, payment links), your platform never touches card data. Your PCI scope stays at the minimum level — typically SAQ A or equivalent. The payment layer carries PCI DSS Level 1 certification for all channels.
What about tips and service charges?
Tips can be added to the payment amount before processing (customer adds tip on the payment page) or processed as a separate transaction. Service charges and delivery fees are included in the order total. The payment layer processes the full amount and the platform handles the split in its settlement logic.
Can we still use Stripe for restaurants that don't have their own PSP?
Yes. A PSP-neutral architecture doesn't mean you stop using Stripe. It means Stripe becomes one of several available processors. Restaurants with existing PSP relationships use theirs. Restaurants without one can default to Stripe (or whichever processor the platform prefers). The platform configures the default — it's not a choice the restaurant needs to make.
How does this work with existing POS integrations?
The payment layer handles payment processing — it doesn't replace the POS integration. The voice AI or ordering platform still pushes orders to the POS (Toast, Square, Clover) for kitchen display and fulfilment. Payment is handled separately, through the restaurant's configured PSP. The POS shows the order; the payment layer handles the money.
What about marketplace-model platforms where the platform is the merchant?
Some food platforms operate as the merchant of record — collecting payment from the customer and settling with restaurants. In this model, the platform processes through its own PSP account. A payment layer supports both models: marketplace (platform is merchant) and agency (restaurant is merchant), often within the same platform for different restaurant segments.
Related Reading
How Voice AI Ordering Platforms Handle Payments — the specific payment challenges for voice AI in food ordering
Voice Payments: The Complete Guide — PCI-compliant payment capture over voice channels
Chat Agent Payments — payment capture in messaging and chat channels
PSP-Neutral vs Single-PSP — why food platforms need multi-PSP flexibility
How Platforms Monetise Payments — the revenue model for embedding payments
Embedded Payments Without Becoming a PayFac — adding payments without the regulatory burden
Gateway vs Orchestrator vs PayFac vs Payment Layer — the four categories of payment infrastructure
How to Get Payments Off Your Product Roadmap — reclaim engineering capacity for your core product
Building a food ordering, voice AI, or restaurant platform?
Shuttle gives food platforms multi-PSP routing, voice payment capture, payment links, and embedded checkout through a single integration. Each restaurant uses their existing processor. Your platform earns revenue share. PCI DSS Level 1 compliance included.