Splitting a phone payment sounds like splitting a check. It isn't, and the difference is why the request eats your Friday.
Splitting a check at a table means you have the guests, the cards, and a terminal in the same place. Somebody declines, they hand you another card, done in twenty seconds. Splitting a payment by phone means reading a sixteen-digit number aloud, then an expiry, then a security code, then a billing zip, four times over, while three other lines ring, and then finding out that the third card declines and the person holding it left the office.
What the caller is usually actually asking for
Most split requests come from one of three situations, and only one of them genuinely needs a split.
The office lunch, where four people are chipping in and nobody wants to be the one who covers it. This is the common case and it does not need a split payment at all. It needs one person to pay and a receipt they can forward.
The family or group order, where two households are ordering together. Same thing. One payer, and they settle between themselves.
The genuine case is a pre-arranged event where two entities are formally paying separate portions, a company covering food and an individual covering alcohol, or two departments splitting a catering bill. That one is real, it involves accounting on their end, and it deserves to be handled properly with time set aside for it.
The first two are asking you to do arithmetic and card entry so their group doesn't have to. That's a favor with a cost, and the cost lands on the shift, not on the person asking.
What it costs at the counter
Time it once during your dinner rush and you will stop debating the policy.
Each card is a separate read-back, a separate keying, a separate authorization, and a separate confirmation. Three cards is roughly three times the phone time of one, plus the amount arithmetic, plus repeating totals until everyone agrees. During peak that is several minutes of a person who is not answering the phone, not expediting, and not helping the guest at the counter.
The failure mode is worse than the duration. If card one and two authorize and card three declines, you now hold a partially paid order. Do you fire it? Do you call back? Do you refund the first two, and if you do, the customer sees pending holds against cards that will take days to release, which produces the confusion described in why a large phone order can show up twice on a card.
Nobody plans for that state, so it gets improvised, and improvisation at 7:15pm on a Friday is where money goes missing.
What your POS will and won't do
Check this before you write a policy, because the answer varies and it constrains everything.
Some point-of-sale systems handle multi-tender on a single ticket cleanly, including card-not-present entries. Some only split tender on an open check at a terminal, which makes a phone split awkward and manual. Some let you split but report it in a way that makes end-of-day reconciliation harder, which your bookkeeper will discover later and mention to you loudly.
Ask your provider two specific questions: can a phone order be paid with multiple card-not-present tenders on one ticket, and does that reconcile normally at close. If the answer to either is no, the operational decision is already made for you.
The rule that actually works
Split by order type and by clock, not by how persuasive the caller is.
Pre-arranged catering, booked in advance, with the split agreed at booking time: yes. You have a person, a scheduled conversation, and no rush. The same applies to deposits, where a company pays the deposit and an individual pays the balance, which fits neatly into the structure in catering deposits and how to collect one.
Same-day orders during service hours: no. One card, or a payment link.
Off-peak same-day, if someone has time and wants to do it: manager's discretion. Just don't write "discretion" into a policy that applies during a rush, because it will be exercised by whoever is least able to afford the minutes.
How to refuse without losing the order
The refusal matters more than the rule. A blunt "we can't do that" reads as inflexibility and occasionally costs a decent order.
The line that works offers the alternative in the same breath. Something like: "I can take the whole thing on one card and send an itemized receipt your group can split up, or I can email a payment link if you'd rather each person pay their own part. Which is easier?"
The customer almost always takes the first option, because their actual goal is not multi-card processing. It's not being stuck with the bill, and a forwarded receipt solves that completely.
For corporate accounts, offer an invoice with terms instead. That is cleaner for them, cleaner for you, and it moves you out of card handling entirely on the orders where the totals are largest.
The fraud angle nobody mentions
Multiple cards on one order is a pattern worth reading in context. A named corporate account splitting a Tuesday lunch is not a risk. An unfamiliar caller placing a large first-time delivery order, offering several cards in sequence, some of which decline, and pressing you to hurry, is a different situation.
Card testing looks like that. So does someone working through a set of numbers that aren't theirs. The signal is not the split by itself, it's the combination of an unfamiliar caller, a big total, several cards, and urgency, alongside the other patterns in phone order fraud red flags.
The safe response is not accusation. It's process. Take one card, verify it, and require a callback on a large first-time delivery. A legitimate customer sits through that. Whatever your policy, the card handling itself should stay in the tokenized path described in collecting payment over the phone safely, because a split payment scribbled on a notepad multiplies the same exposure by the number of cards.
Where automation fits
A voice agent takes a single card well, on every call, with the same read-back and the same authorization behavior at 8pm as at 2pm. That covers nearly all of your phone payment volume.
A split request should not be something it attempts. Hand it to a person, or hand it to a payment link. The reason is not technical difficulty, it's that a partial failure needs somebody to decide what happens to a half-paid order, and that decision has money and a customer relationship attached to it. Put it in your escalation rules alongside the other cases in human handoff and failover.
Write your rule as one sentence on the phone card: one card during service, splits only on pre-booked catering, payment link for everyone else. Then check next month whether anyone lost an order because of it. In most operations, nobody did.