A split bill is several separate payments, because one charge takes one card.
Splitting a bill between customers means one payment per person and a running balance you keep yourself. There is no call that charges two cards for one amount. Stripe says so on the page where its documentation takes split tender by name, the one on French meal vouchers, read on 14 October 2026: Stripe does not directly support split tender, and you must orchestrate it by creating separate payments. The PaymentIntent object agrees. Its payment_method field holds the ID of a single payment method, not a list. So the split lives in your app. You set the shares, you create a payment for each one, and you hold the booking until the last share clears. The question almost always arrives late, bolted onto a booking app builder that already works.
What follows is the shape that holds up, the arithmetic that goes wrong first, and the one question that decides whether any of it is allowed: whether Apple treats the thing you are splitting as a real world service or as something sold inside the app. The answer is different for a restaurant table and for a subscription, and the guideline numbers are below.
Start hereThe short version
One total, several payments. Your app owns the arithmetic.
Stripe does document a way to collect one total from several payments. It is in Invoicing rather than in Checkout. You create a separate payment for each person, attach it to the invoice, and Stripe keeps the sums. Its own wording: most invoices are paid with a single payment, and for larger invoices you can accept multiple, smaller payments. Each one can be any amount up to the amount remaining. When a payment succeeds, Stripe updates amount_paid and amount_remaining, and the invoice only turns paid when nothing is left on it.
Two other features get mistaken for this, and it is worth being clear which problem each one solves. Partial authorization is about a single card that does not have enough on it, not about two people. Connect's separate charges and transfers goes the other direction entirely: its own summary is to create charges on your platform account and transfer funds to multiple connected accounts, which divides money you have already collected between recipients. Neither of them bills two customers for one amount.
Can one charge be split across several payment methods?
No, and the shape of the API tells you why before any tutorial does. A PaymentIntent carries a single payment_method field, which Stripe's reference describes as the ID of the payment method used in this PaymentIntent. The neighbouring payment_method_types field is a list, but the reference calls it the list of payment method types that this PaymentIntent is allowed to use. Allowed to use, not used at the same time. One intent resolves to one method and produces one charge.
Partial authorization is the nearest thing in the documentation, and it is not a split between people. Stripe describes it as requesting approval for a portion of the originally requested amount when the available balance is insufficient to cover the full amount. The first instruction on that page answers this whole article: decide how you want to handle the portion that is not covered, and you can create a separate PaymentIntent for another form of payment, cancel the entire PaymentIntent, or capture only up to the partially authorized amount. Separate payments, again.
It also arrives fenced in, which is worth knowing before you plan around it. Online card payments only. Visa, Mastercard, Discover and Amex only, with the issuer and card type deciding whether it works at all. It is an IC+ pricing feature, so you contact Stripe to have it switched on. Stripe still enforces its minimum charge amount and declines any PaymentIntent that falls short of it. And the status comes back on the charge as partially_authorized, fully_authorized, declined or not_requested, alongside amount_requested and amount_authorized, so you have to read the result rather than assume it. Checked 14 October 2026.
So the pattern that works is the dull one. Hold the total on your own record, create one payment per person, mark each share paid when its payment succeeds, and treat the bill as settled only when the remainder reaches zero. If you would rather Stripe kept that remainder than write the bookkeeping yourself, the invoice is the object built to do it, and the partial payments flow is the documented route.
Stripe, accept partial payments for invoices, read 14 October 2026
Work out the shares
Where the leftover pennies go
Amounts are whole cents, because that is what Stripe takes. Tip first, then divide, then hand the remainder to someone on purpose.
Bill
People
Tip
Total owed: $84.00 (8400 cents)
Even share: $21.00, with 0 spare cents to place
The outlined shares carry a spare cent each. Shown so that 8400 cents collected equals 8400 cents owed, every time.
Does Apple make a split bill go through in-app purchase?
For a real world service, no, and Apple is explicit about it. App Store Review Guideline 3.1.3(e), titled Goods and Services Outside of the App and read on 14 October 2026, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. A restaurant table, a haircut, a padel court, a cleaning visit: you take the card yourself, and the store takes no commission on it.
The exemption stops at the edge of the app. Guideline 3.1.1 covers the other side of the line: if you want to unlock features or functionality within your app, by way of example subscriptions, in-game currencies, game levels, access to premium content or unlocking a full version, you must use in-app purchase. So splitting the cost of a court booking is yours to collect. Splitting the cost of a subscription to your app is a different product under a different rulebook, and Apple's commission applies to it.
One edge deserves a second read, because a group feature lands on it by accident. Guideline 3.1.3(d), Person-to-Person Services, allows purchase methods other than in-app purchase for real-time person-to-person services between two individuals, giving tutoring students, medical consultations, real estate tours and fitness training as the examples. It then says that one-to-few and one-to-many real-time services must use in-app purchase. Six people splitting the fee for one live class is not the same case as a one-to-one session, so read the guideline before you build the group version.
If your app lets one person pay another back, guideline 3.2.1(vii) is the paragraph that governs it. Individual users may give a monetary gift to another individual without in-app purchase, provided the gift is a completely optional choice by the giver and 100 percent of the funds go to the receiver of the gift. A gift connected at any point in time to receiving digital content or services must use in-app purchase. The practical reading: you cannot keep a cut of a settle-up and still call it a gift, and you cannot use the gift route to pay for something digital.
Google Play is looser here and words it differently, which matters if you plan to answer both with one sentence. Its payments policy, read on 14 October 2026, says Google Play's billing system must not be used in cases where the payment is primarily for the purchase or rental of physical goods, or for physical services, with gym memberships and food delivery among its own examples, and where payments include peer-to-peer payments. It never uses Apple's phrase about being consumed outside of the app. The two tests are not the same test, so answer them separately.
What happens when one person's share fails?
It stays partially paid, which is a state and not an error. Stripe records every attempt in the invoice's payments list, keeps amount_remaining up to date, and shows your customer the remaining amount with a partially paid status in the customer portal. Your app needs the matching screen: who has paid, who has not, and what happens to the booking while the gap is open. That last one is a policy decision rather than a technical one, and it is far better made in advance than while somebody is standing at a counter.
A few knock-on rules catch people out. While an invoice has open payments on it, you cannot void or edit it, and you cannot mark it uncollectible. Refunds are per payment rather than per bill: a credit note with a refund amount tries to refund the most recent payment, and fails if that payment has already been refunded or if the refund is larger than the payment was. Cancelling a four way split is therefore four refunds and a reconciliation, so build the screen that shows which ones went back.
Recurring splits are the hardest version, and the limit is written down. Stripe does not support partial payments on subscription invoices that are charged automatically. They work where the collection method is send_invoice, which means emailing an invoice rather than charging a card already on file. Two people sharing one membership in a gym membership app cannot each be auto-charged half of the same invoice. The usual answers are two subscriptions at half the price each, or one payer and a private arrangement between the two of them.
Four ways to collect one total from several people
| The approach | Who carries the shortfall | Where it breaks | Works with no accounts |
|---|---|---|---|
| Organiser pays the whole total | The organiser, off your books | They chase their friends, and you never see it | Yes |
| Everyone pays their own share | You, until the last share clears | One failure leaves the bill short and open | No |
| Hold the organiser, charge the rest later | The organiser, up to the held amount | Holds expire, and the amount moves after the hold | No |
| Send each person a payment link | You, with no deadline at all | People forget, and you hold no card on file | Yes |
Where this lands if a builder generated your app
None of the store rules change because an AI wrote the code, and on iOS you are still the one who presses submit. Guideline 4.2.6 is why: apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. Newly uploads iOS builds to TestFlight and publishes to Google Play internal testing, and it does not submit to the App Store on your behalf, because Apple requires the owner of the content to do that.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project that you own, with two way GitHub sync and a standalone Android build, so the payment logic is ordinary code you can read and change rather than a setting in somebody else's dashboard. It is $25 a month, with no free tier. The split arithmetic is the part worth describing precisely when you ask for it: name the rounding rule, say who takes the leftover pennies, and say what happens to the booking when a share fails. Those three sentences are most of the feature.
The honest limit is that no builder can decide your policy. Whether a failed share releases the table, whether the organiser is liable for the rest, whether a share under the minimum charge is refused or rolled into somebody else's: those are business rules, and they are the ones your customers will argue with you about. Write them down first, then build the screens that show them.
Apple, App Store Review Guidelines, guideline 4.2.6, read 14 October 2026
Questions people ask about splitting a bill in an app
Not as one payment. A Stripe PaymentIntent has a single payment_method field, described in Stripe's API reference as the ID of the payment method used in this PaymentIntent. Stripe's own documentation is blunt about the general case: it does not directly support split tender, and you must orchestrate it by creating separate payments. The closest feature, partial authorization, exists for one card without enough balance on it, and even there Stripe tells you to create a separate PaymentIntent for the portion that is not covered. Read 14 October 2026.
Describe the split, then the rules around it
Write down the rounding rule, the minimum share, and what happens to the booking when one person does not pay. Then describe the screens. The payments are the easy half once those three answers exist.
Start building