Take Payments on Behalf of Your Clients: Solving the Multi-Merchant-Account Problem
Quick answer: if your business collects payments that belong to your clients, you need each payment to settle into that client's own merchant account, not yours. A single gateway account can't do that. The clean solution is one payment system that holds a separate merchant account (MID) connection per client and routes every transaction to the right one. Shuttle does this across phone, payment links and API, with your clients keeping their own gateway relationships.
There's a class of business that operates like a software platform without ever using the word. Medical and dental billing services. Revenue cycle management (RCM) firms. Collections servicers. Statement printers and AR outsourcers. Call answering services that take payments for the practices and firms they answer for. Property managers collecting rent for dozens of landlords.
The pattern is the same in every case: you collect money that belongs to someone else. Fifty clients means fifty businesses whose money passes through your operation, and each of them expects their money to land in their bank account, under their name, reconciled against their ledger.
Most payment tools are built for a business collecting its own money. The moment you collect for clients, those tools stop fitting. This guide explains why, what the two workable models are, and how to run payments for every client through one system without becoming a money handler yourself.
Why one merchant account doesn't work
A merchant account (and its MID, the merchant identifier the card networks use) is tied to one legal entity. Payments processed on it settle to that entity's bank account, and the card statement descriptor shows that entity's name.
Run all your clients' payments through your own single account and three problems arrive quickly:
The money lands in the wrong place. Everything settles to you. Now you're disbursing client funds from your own account, which creates trust-accounting obligations, timing risk and a reconciliation burden that grows with every client.
You look like the merchant. Cardholders see your name, not the dental practice or the landlord they think they paid. Confused cardholders dispute charges, and the chargebacks are yours.
Your acquirer notices. Processing other businesses' payments through your own merchant account is, from the acquirer's point of view, unregistered aggregation. It breaches most merchant agreements and can get the account shut down.
So the volume has to run on each client's own merchant account. The question is how you do that operationally when you have one team, one phone system and fifty MIDs.
Two ways to route money to clients
There are two workable models, and the difference matters more than any feature comparison.
Route to each client's own merchant account | Become the merchant of record | |
|---|---|---|
Where funds settle | Directly to each client's bank, from their own MID | To you (or your provider), then disbursed to clients |
Whose PSP relationship | The client keeps their own gateway and acquirer | Yours; clients depend on your processing setup |
Statement descriptor | The client's name | Yours or your provider's |
Your regulatory position | Service provider | Money handler, with the obligations that follow |
Chargebacks and liability | Sit with the client's account | Concentrate on you |
Merchant-of-record aggregation is a legitimate model, but it turns you into a payments business: funds flow, disbursement schedules, KYC on every client, and liability concentrated in your entity. Most billing services, servicers and agencies don't want any of that. They want to be paid for the service they already provide, with the money going straight to the client.
Routing to each client's own merchant account keeps the roles clean. The client keeps their gateway relationship and their settlement. You keep one operation and one system. Nobody's money sits in your accounts.
That's the model Shuttle is built around: each client connects their own merchant account or gateway credentials once, and every payment your team takes is routed to the right client automatically. One integration on your side, however many MIDs on theirs. Shuttle works with 40+ payment gateways, so it fits the accounts your clients already have rather than forcing anyone to switch. Voice capture works on many of those gateways; payment links cover the rest.
The phone is the compliance trap
For most of these businesses the highest-volume channel is the phone. A patient calls the billing line. A debtor answers an outbound call. A tenant rings about rent. And a common way teams handle it today is also the riskiest: the agent asks for the card number and types it into a virtual terminal.
The moment your staff hear or see card numbers, your whole operation is inside PCI DSS scope. Your phone system, your call recordings, your agents' screens, your training and vetting processes all become part of the compliance surface. For a servicer handling payments for fifty clients, that's fifty clients' worth of card data risk concentrated in one room.
There are two ways to keep card data out of your environment while keeping the phone channel:
IVR self-payment ("press 1 to pay"). The caller pays through an automated flow, entering card details on the keypad. No agent involved, no card data in your environment. This suits high-volume, low-exception collections like patient balances and rent.
Agent-assisted secure capture. The agent stays on the line while the caller enters their card number on the keypad. The digits go to the payment gateway, not to the agent, whose screen shows only masked progress. The conversation continues; the card number never enters your phone system or recordings.
And because real calls fail in predictable ways, the failure modes need answers too. Call drops mid-payment: send a payment link by SMS or email so the caller finishes on their phone. Caller has no card to hand: take a bank payment on the same call instead. Caller wants to pay later: schedule the link. Each of these is a recovery path for a payment that would otherwise be lost.
Shuttle's Voice Checkout covers both phone patterns, with payment links as the fallback channel, and the same per-client routing applies everywhere: the IVR payment, the agent-assisted payment and the link payment all settle to the right client's merchant account. Card details are tokenised with the gateway itself; Shuttle holds no card vault of its own. For teams on Twilio, note that Shuttle is Twilio's chosen provider to enable Twilio Pay for many payment gateways.
Who this fits
Medical and dental billing services (and RCM firms)
You collect patient balances on behalf of practices. Each practice has its own merchant account, and payments must reconcile against the practice management or RCM system per client. Phone volume is high and PCI exposure is the operational headache: agents on patient calls all day, taking cards. Per-client routing plus agent-assisted capture fits this shape directly, and IVR self-pay absorbs the routine balance payments so agents handle exceptions. See the full guide to payment solutions for medical billing companies and RCM firms.
Collections servicers and debt agencies
Agencies collect on behalf of creditors, and creditors mandate where their money goes. One creditor requires their Worldpay account, another uses Stripe, a third names their acquiring bank in the contract. Per-client MID routing is not a nice-to-have here; it's a contractual requirement. See the full guide to secure payment collection for debt agencies.
Call answering and virtual reception services
You answer for hundreds of small firms, and callers increasingly expect to pay in the same call: the booking deposit, the outstanding invoice, the consultation fee. Taking a card verbally on behalf of a client is the same PCI trap plus the same settlement problem. Routing by client, with the receptionist using agent-assisted capture, turns payment-taking into a service line you can charge for. More in our piece on payments for call answering services.
Statement printers and AR outsourcers
You already produce the invoice, the statement or the dunning letter. Adding "pay now" (a link on the e-statement, an IVR number on the printed letter) closes the loop, but only if each payment settles to the issuing client's account. Per-client routing lets one print-and-post operation carry payment collection for every client on the file.
Property managers and lettings agencies
Rent belongs to the landlord. Client-money rules in most markets require it to be handled accordingly. Routing each tenant payment to the right landlord's account, rather than pooling and disbursing, keeps the agency out of the money chain. See payment links for property management.
Why these businesses can go live fast
A software platform that embeds payments has to wait for its downstream merchants to adopt. You don't. The call volume is already in your building, the client MIDs already exist, and every payment your team takes today is a payment you could route properly tomorrow. That's why these businesses can go live fast: the volume is theirs to move.
The practical path: talk to us about your client mix and channels. If you want to explore the technical side first, docs.shuttleglobal.com covers the APIs, IVR and agent-assisted flows, and sandbox accounts are available for testing before any real client MID is connected. When it works, connect the first client's account and move their volume; then it's repetition, not integration.
Take payments on behalf of clients: FAQ
Can I take payments for multiple clients through one system?
Yes. The requirement is per-client merchant account routing: each client connects their own merchant account or gateway credentials, and the system routes every payment to the right one. Your team works in one place; the money settles to each client directly.
Do my clients need their own merchant accounts?
In the routing model, yes, and that's the point: their money settles under their name, and they keep their own gateway relationship. Clients that don't yet have an account can set one up with one of the gateways Shuttle supports. The alternative (processing everything on your account) makes you an aggregator, which most merchant agreements prohibit.
How do billing services take patient payments by phone without breaking PCI?
Two patterns: IVR self-payment, where the patient pays through an automated keypad flow with no agent involved, or agent-assisted capture, where the agent stays on the line while the patient keys in the card number and the digits go straight to the gateway. In both, card data never enters your phone system, recordings or screens, which keeps those systems out of PCI DSS scope and cuts your own validation burden to a minimum.
What's the difference between routing to client merchant accounts and being a merchant of record?
Merchant of record means the funds flow through you: you settle, you disburse, you carry the chargebacks and the compliance obligations of a money handler. Routing means each payment settles directly to the client's own merchant account and you never touch the funds. For servicers, routing keeps your business a service business.
Can each client use a different payment gateway?
Yes. One client on Stripe, another on Worldpay, a third on their bank's acquiring service, provided it's one of the 40+ gateways Shuttle supports. Each connects the account they have. Shuttle supports 40+ gateways, so per-client routing doesn't require standardising your clients onto one provider.
How fast can we go live?
There's no downstream adoption to wait for: the phone volume is already yours. Test the IVR and agent-assisted flows against a sandbox account first, then connect the first client's merchant account. From there, adding clients is configuration, not a new project.
Related reading
Payment collection for BPOs: multiple clients, multiple PSPs
DTMF payments: how keypad capture keeps agents out of PCI scope
Ready to route every payment to the right client's account? Talk to us. If you'd rather explore the technical side first, docs.shuttleglobal.com covers the APIs and flows, with sandbox accounts available for testing.