The Multi-Client Payment Problem
You run a BPO or outsourced contact centre. You handle calls, chat, email, maybe AI agents, for a portfolio of clients. Some of those clients need you to collect payments on their behalf.
Here's where it gets complicated.
Client A processes through Worldpay. Client B uses Stripe. Client C has a Braintree account they negotiated rates on three years ago and aren't switching. Client D is a debt collection agency that's contractually required to use a specific processor mandated by their creditors.
Each client expects their branding on the payment experience. Each client has different compliance requirements. Each client's payments need to settle into their own merchant account.
And your agents, whether human or AI, need to handle all of this from a single interface, without seeing card data, without expanding your PCI scope, and without logging into four different payment dashboards.
This is the multi-client payment problem. It's unique to BPOs and outsourcers, and almost no payment solution is designed for it.
Why Standard Solutions Don't Work
Single-Gateway DTMF Solutions
The incumbent single-gateway DTMF providers in the contact centre space solve the PCI compliance piece well. They mask DTMF tones so agents can't hear card data. Recordings are clean. The call centre's scope is reduced.
But they're built for single-merchant environments. An insurance company with one PSP and one brand. A utility company with a direct Worldpay integration.
When a BPO tries to use these solutions across a multi-client portfolio, the problems multiply:
PSP configuration per client. Most DTMF solutions support a limited set of gateways. Each client's PSP needs separate configuration, often requiring professional services involvement.
No multi-tenant architecture. The solution isn't designed to route Client A's payments through Worldpay and Client B's through Stripe from the same agent session. You end up with separate configurations, separate dashboards, separate reporting.
Per-seat pricing is common. Many single-gateway DTMF providers charge per agent seat. For a BPO running 200 agents across 15 clients, a seat-based fee is borne entirely by the BPO, and it doesn't scale down when volume drops. A quiet month costs the same as a peak month.
No white-label. The payment experience carries the DTMF provider's branding, not your client's. For BPOs that position payment collection as a premium capability, that undermines the value proposition.
Logging Into Client Portals
Smaller call answering services often handle payments by logging into each client's Stripe dashboard or payment terminal. An agent takes a call for Client A, alt-tabs to Client A's Stripe account, processes the payment, switches back.
This is operationally fragile at any scale:
Agents need credentials for multiple payment systems
No audit trail linking the call to the transaction
Card data is visible to the agent (full PCI scope)
Training complexity multiplies with every new client
A single mis-keyed transaction goes to the wrong merchant account
Building In-House
Some enterprise BPOs consider building their own payment infrastructure. The scope is sobering: multi-PSP integration (each gateway is weeks of engineering plus ongoing maintenance), PCI DSS Level 1 certification, tokenisation vault, multi-tenant merchant management, and a compliance function to maintain it all. The build path makes sense for a payments company. BPOs are not payments companies.
What BPOs Actually Need
Strip it back to requirements:
Multi-PSP routing. Each client's payments route through their own PSP: Worldpay, Stripe, Adyen, Checkout.com, or any of the 30+ gateways their merchants might use. One integration from the BPO's side.
Multi-tenant by design. Each client is set up with its own PSP account and merchant credentials, so a payment taken for that client is paid into that client's own account. No agent decision-making. No switching on the call. Outsourced parking and enforcement operators face an analogous multi-client routing problem. See Payment Collection for Parking, Enforcement and Toll Operators.
Limited PCI scope for the BPO. Card data never enters the BPO's environment. The card is captured within a PCI DSS Level 1 certified boundary (for voice today, that runs on Twilio Pay or Telnyx <Pay>, so voice requires a Twilio or Telnyx account). Recordings stay clean. Card data stays out of the BPO's telephony and recording stack.
White-label. The payment experience (for example an SMS payment link sent mid-conversation) carries the client's branding. The BPO can position this as their own capability. The end customer sees the brand they trust.
Per-transaction pricing. Cost scales with payment volume, not headcount. Quiet months cost less. Peak months scale without renegotiating seat licences. This aligns the payment infrastructure cost with the revenue it generates.
Multi-channel. Voice (DTMF) for live calls. Payment links via SMS or email for post-call follow-up or when the caller can't use a keypad. Chat payments for digital channels. The same integration covers all of them.
The Revenue Opportunity
Most BPOs treat payment collection as a cost centre: a compliance headache they tolerate because clients demand it. That framing is wrong.
Payment collection is a premium service. Clients will pay more for a BPO that can securely capture payments during calls, because the alternative is:
Post-call payment links that some customers never complete
Customers calling back to a separate payment line
Failed collections that never convert
When your BPO can capture a payment while the customer is live on the call (with their card in hand, intent confirmed, agent guiding them through), collection rates jump. That's directly measurable value for your clients.
Payment-related calls are a routine part of contact centre volume in sectors like utilities, insurance, debt collection, telecoms, and financial services.
Payments as a Competitive Moat
Once a client's payment flows run through your infrastructure (their PSP configured, their branding applied, their reconciliation integrated), switching BPOs means rebuilding that entire payment setup elsewhere. Payment collection creates operational switching costs that message-taking and appointment-booking services don't.
How It Works in Practice
Agent-Assisted Payments (Human Agents)
Agent is on a call with a customer who needs to pay
Agent triggers "Take Payment" from the interface you build against Shuttle's APIs: your routing identifies which client this call belongs to
On Twilio, the card is captured securely via Twilio Pay, routed to the client's configured PSP
The customer enters their card details on the keypad; the digits pass from Twilio Pay to Shuttle's PCI DSS Level 1 environment and never reach the agent or the recording
The payment layer processes the transaction through the client's PSP
Agent sees confirmation: "Payment of £150.00 approved, last four digits 4242"
Shuttle ships the PCI-compliant capture, IVR and APIs plus ready-made link interfaces; the agent-side screen for your workflow is something you build, because every contact-centre setup is different. One honest caveat: full-call presence is not available today; on Twilio, returning the caller to the same agent works today when your team builds the return route in Twilio and passes a conversation ID. Works with Twilio and Telnyx today, and any carrier coming soon. The automated self-pay flow is covered in IVR Payments.
If the customer can't use their keypad, the agent sends an SMS payment link with one click. Payment links are the turnkey path: they work mid-call, and they work even with gateways that don't support voice. The link is branded to the client, and the customer completes payment on their device.
AI Agent Payments
The same model works for AI voice agents. When the AI identifies payment intent, your agent triggers the payment layer via API. The card is captured securely at the point of payment, and the AI receives a webhook confirming success or failure. You build the agent interface against Shuttle's APIs.
This is particularly relevant for BPOs scaling AI agents for debt collection, appointment payments, and renewal processing, high-volume, repeatable payment scenarios. See PCI-compliant payments for AI voice agents for the architecture.
Post-Call Payment Links
For calls where payment wasn't completed live (customer needed to check their account, wanted to discuss with a partner, or the call was informational), the agent (human or AI) triggers an SMS or email payment link. The link carries the client's branding, supports cards, digital wallets, and bank transfers, and reports back when payment is received.
PCI DSS v4.0.1: What Changed for BPOs
PCI DSS v4.0.1 (effective March 2025) tightened requirements for outsourced payment collection:
Shared responsibility is now explicit. Merchants (your clients) can't fully transfer PCI liability to you by outsourcing. But they can dramatically reduce their scope by ensuring you use a PCI-certified payment layer that keeps card data out of your environment.
Enhanced monitoring of third-party providers. Your clients are now required to monitor and assess the compliance of their service providers more rigorously.
Targeted risk analysis required.
For BPOs, the v4.0.1 changes mean that clients will increasingly ask for evidence of how card payments are handled. The BPOs that invest in compliant payment infrastructure now will win the clients whose compliance teams are asking these questions.
Comparing Approaches
Pause & Resume | DTMF Overlay (Single-Gateway) | Multi-PSP Payment Layer (Shuttle) | |
|---|---|---|---|
PCI scope | Full SAQ-D | Reduced | Reduced |
Multi-PSP | N/A | Varies by provider | 30+ PSPs |
Multi-tenant | No | Limited | Built for it |
White-label | N/A | Limited | Yes |
Pricing | N/A | Often per seat | $49 per live instance per month, plus per-transaction fees from $0.20 |
Channels | Voice only | Voice only | Voice (Twilio Pay or Telnyx <Pay>) + links + chat |
AI agent support | No | Limited | Yes (you build the agent interface) |
Implementation | Minimal | Weeks–months | Links self-serve; voice needs your build |
Best for | Small, single-client centres | Enterprise single-merchant | BPOs, multi-client outsourcers |
FAQ
How does the system know which client's PSP to use? When your agent handles a call, your CRM or CTI identifies the client. When payment is triggered, the client's PSP configuration is passed to the payment layer. This is typically automated via your workforce management or routing system, no manual selection required.
What if a client changes their PSP? The client's PSP settings are updated in the payment layer, with no re-integration. New payments go through the new gateway from that point; saved cards stay with the gateway that stored them.
Can we use this for outbound collections? Yes. Outbound calls work the same way: when a customer agrees to pay, the agent triggers payment capture via DTMF or sends a payment link. For AI-driven outbound collections, see our guide on secure payment collection for debt agencies.
What about refunds? Refunds are processed through the same payment layer, routed back through the original PSP. Agents can initiate refunds from the same interface they use for payment capture. Full audit trail included.
How does this affect our existing CCaaS platform? There is no native integration with CCaaS or AI voice platforms today. Shuttle's voice capture runs on Twilio Pay or Telnyx <Pay> today, so using it for voice means having a Twilio or Telnyx account; you keep your contact-centre platform and build the agent-side trigger against Shuttle's APIs. For Twilio users, Pay Connectors cover the Twilio path. For CCaaS operators embedding this for their BPO customers, see Embedded Payments for CCaaS.
What's the implementation timeline? Payment links are self-serve; they work mid-call and with gateways that don't support voice. Voice capture requires a Twilio or Telnyx account and building your own agent-side interface against Shuttle's APIs. Shuttle works with Twilio and Telnyx today, and any carrier coming soon.
Related Reading
Take Payments on Behalf of Your Clients - solving the multi-merchant-account problem for servicers
PCI-Compliant Payments for Contact Centres: the complete guide to contact centre payment approaches
Secure Payment Collection for Debt Agencies: PCI-compliant payments for the collections vertical
Why Most Call Answering Services Can't Take Payments: the payment gap in the call answering market
Enterprise PSP Mandates: why enterprise clients demand their own PSP
PSP-Neutral vs Single-PSP: the architectural decision for multi-PSP support
Prommt Alternatives for Platforms: comparing payment link providers for multi-merchant collection
Twilio Pay Connectors: connecting Twilio Flex to any compatible PSP for BPO payment collection
Twilio PCI Compliance: PCI scope and compliance for Twilio-based contact centres
Collect payments for every client, through each client's own compatible PSP, without touching card data.
Shuttle gives BPOs and outsourced contact centres a single integration for multi-client, multi-PSP payment collection, with white-label branding, on Shuttle's PCI DSS Level 1 environment. Voice (on Twilio Pay or Telnyx <Pay> today), links, and chat. Payment links are self-serve; voice runs on Twilio or Telnyx and you build the agent interface. Voice costs $49 per live instance per month, billed by Shuttle, plus from $0.20 per transaction, falling with volume. On Twilio, the per-transaction fee is billed through your Twilio account. On Telnyx, Shuttle bills it.
Book a Demo | See Voice Checkout
