A group booking is one payer buying several seats, and the part that breaks is the two who do not turn up.

How do you take one payment for a whole group?

With a quantity, not with a loop. Stripe's own documentation creates a Checkout Session with line_items[0][quantity] set to the number of units, so eight seats at the same price is one line item with a quantity of eight and one payment for the lot. Put your own booking reference in the session metadata, because the webhook that tells you the money arrived needs to find the booking it belongs to. Where seats differ in price, adults and children, dinner and drinks, add a line item per price rather than per person. The guest list is yours. The payment provider never needs to know who sat where, and keeping names out of it means a late swap is a database edit instead of a new charge.

If you want the organiser to set the number themselves, Stripe documents an adjustable quantity on the line item, with a default minimum of nothing and a default maximum of 99, raisable to 999999, read on 14 October 2026. Two details matter for a party. Checkout stops a customer removing an item when it is the only one left, and if you are holding seats you should reserve against the maximum you allowed rather than the quantity you started with. Set the minimum to the smallest party you will actually serve on a Friday night. A minimum of nothing on your only line item is a checkout that can complete for an empty table.

The other model is a payment per guest, with a link each and everyone paying for themselves. It is kinder to the organiser's friendships and worse at everything else. You now have as many payments as guests, each able to fail on its own, as many refunds when the date moves, and a party that is three quarters paid at midnight on the Thursday. For a table of eight, take one payment from the organiser and let them settle up between themselves. Keep the per-guest flow for the cases where no single person is willing to be liable, like a hen weekend split six ways. The plumbing is the same either way, and adding payments covers the first pass.

What changes with the calendar is the instrument, not the structure. A booking for tonight can be a straight charge. A booking for the end of the month should not be, and the reason is an expiry date most people never think about.

Stripe, place a hold on a payment method, read 14 October 2026

What do you do when the headcount changes?

You have two instruments and they are not equally good. Either you held the money and capture less than you held, or you took the money and give some of it back. Stripe documents both. The first one is cheaper, quieter and has a deadline. The second one works whenever you like and costs you a fee every time.

The hold is a capture method of manual, set when you create the Checkout Session or the PaymentIntent. That authorises the amount without taking it. On the day you capture, and you can capture less than you authorised by passing an amount to capture. Stripe's own example captures 7.50 USD of an authorised 10.99 USD. A partial capture automatically releases the rest, so for two missing seats out of eight there is no refund in the story at all. The catch sits in the same page: for most payments you only get one capture, and if you partially capture you cannot come back for the difference. Count heads, then press it once. Two more honest limits. Not every payment method supports it, cards and a handful of wallets do while bank debits like ACH do not, and some card statements do not visibly distinguish a hold from a completed payment, which generates the message asking why you charged them twice.

The deadline is the part that catches booking apps specifically. An authorisation expires. Stripe lists card-not-present validity as 7 days for Visa, Mastercard, American Express and Discover on customer-initiated transactions, and 5 days for Visa on merchant-initiated ones, which it notes is exactly 4 days and 18 hours. In person through a card reader the windows are shorter again: 5 days for Visa and 2 days for Mastercard, American Express and Discover. The charge carries a capture-before timestamp so you can see your own deadline. Miss it and the funds are released and the payment moves to canceled, which means your fully booked party is now unpaid and nobody told you. So a hold is for a booking inside the week. Anything further out is a deposit now and a balance later.

Stripe, authorisation validity windows and capturing less than you held, read 14 October 2026

When the money has already landed, a partial refund is a refund created against the PaymentIntent with an amount in the smallest currency unit. You may issue more than one refund against the same charge, which covers a party that shrinks twice, but the total can never exceed the original charge. Three things about refunds are worth putting in your own copy before a customer finds them. The processing fee from the original transaction is not returned, so handing back two seats costs you the fee on eight. Refunds go only to the original payment method, so a closed card becomes the issuer's problem and occasionally a failure that takes up to 30 days to come back to you. And the organiser sees the credit about 5 to 10 business days later, not tonight.

One refund behaviour is worth a line in your cancellation email. A refund issued shortly after the original charge can be processed as a reversal, in which case the original charge drops off the statement and no separate credit ever appears. To somebody watching for money to arrive, that looks exactly like nothing happened. Also worth knowing before a bad Saturday: the Stripe dashboard will refund payments in bulk, but only in full, so partial refunds are issued one at a time. A cancelled party of twenty with a retained deposit is twenty manual refunds unless your app does it for you.

Which is why Stripe's own advice, on the refunds page itself, is that businesses refunding a lot of payments close to the time of the transaction should authorise and capture manually instead, then cancel before capture or reduce the captured amount rather than processing a refund. Cancelling a payment before it completes costs nothing. A refund afterwards might incur a fee and never returns the original one.

Stripe, refund and cancel payments, read 14 October 2026

Does Apple let you charge for a party without in-app purchase?

It does more than let you. App Store Review Guideline 3.1.3(e), headed Goods and Services Outside of the App, 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. Read on Apple's own guidelines page on 14 October 2026. A table, a party in a venue, a court for an hour, a class in your own room: all consumed outside the app. So in-app purchase here is the wrong answer rather than the cautious one, and a card field is what review expects to see. If a search sent you to guideline 3.1.5 for this, that section is Cryptocurrencies and has nothing to do with your party.

The neighbouring rule is the one that catches group bookings specifically, and it is worth reading twice. 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, and Apple names tutoring students, medical consultations, real estate tours and fitness training. The same guideline then states that one-to-few and one-to-many real-time services must use in-app purchase. So a live one-to-one session delivered inside your app can take a card, and a live group session delivered inside your app cannot. A group class people physically attend is a different case again and falls under 3.1.3(e), which forbids in-app purchase. The deciding question is never whether you call it a class. It is where the thing is consumed, and how many people are on the other end.

One more line in 3.1.3 shapes your screens. Apps relying on that section cannot, within the app, encourage users to use a purchasing method other than in-app purchase, with an exception for apps on the United States storefront and the cases set out in 3.1.1(a) and 3.1.3(a), and developers may send communications outside the app about other purchasing methods. For a pure booking app this is mostly academic, because in-app purchase is not available to you anyway. It starts to matter the moment one app sells both a party in a room and something digital, and at that point which payment layer to use stops being a preference and becomes two rails you maintain at once.

Google arrives at a similar place by a different route. Google Play's Payments policy requires Google Play's billing system for access to in-app features and services, then lists the transactions that do not require it, physical services among them, with its own examples including transportation services, cleaning services, airfare, gym memberships, food delivery and tickets for live events. Read on 14 October 2026. Notice the difference in force, because it decides your code rather than your opinion. Google says you do not have to use its billing for this. Apple says that for this you must not use in-app purchase. One is permission and the other is an instruction, and only the second one gets your build rejected.

How much should you take up front for a party?

Enough that cancelling costs something, little enough that booking does not feel like a purchase. For a table, a few units a head turns a no-show from a shrug into a decision. For a party that blocks a room or a member of staff for an evening, a quarter of the expected total is the shape most venues land on. The percentage is not really the question though. What you lose when they vanish is: the hours you rostered, the covers you turned away, the stock you bought for it. Size the deposit against that number and the policy writes itself, including the bit where a party of twenty pays more up front than a party of four.

Pick one of three and put it on the booking screen in the same words you would use on the phone. Deposit now and the balance on the day. A hold now and a capture on the day. Pay in full now with a cancellation window. The third is the most profitable and the most argued about, and it is the one that fills your inbox. Whichever you pick, say the number and the deadline in hours rather than in a paragraph, and show both again in the confirmation. A deposit nobody noticed is a chargeback with extra steps.

A no-show fee is a charge against a card that is not in front of you, so it needs a stored payment method and consent you captured when they booked, not a sentence in a policy page they never opened. Send the reminder before the cancellation window closes, so the person who cannot come still has a free way out. That one message prevents most disputes, because a fee people saw coming is a fee they argue with you about instead of their bank. Automate the reminder before you automate the fee.

The cheapest trick in this whole area is the one Stripe prints in its own cost guidance. If you process a lot of refunds close to the time of the transaction, which is exactly what a booking business does, authorise and capture manually, then cancel before capture or capture a smaller amount instead of refunding. Nobody has lost money yet, so nobody is cross, and you keep the fee you would otherwise have paid to give money back. The arithmetic in the planner above shows the same booking handled all three ways.

Stripe, cancelling a payment costs nothing and refund cost optimisation, read 14 October 2026