Apple now sells your subscription to whole companies by the seat, and a multiseat subscription refund works differently

Apple started selling app subscriptions to organizations by the seat on October 22, 2026, and it switched the option on for most developers without asking. Businesses and schools that use Apple Business or Apple School Manager can now buy your auto-renewable subscription in bulk through a single In-App Purchase. That changes what a multiseat subscription refund looks like on your server. One transaction can now pay for dozens of people, a seat can disappear without any refund at all, and the endpoint you use to argue a refund case refuses to talk about the people actually using the app.

What Apple switched on, and where it announced it

The launch came as a short Apple Developer news post titled "Offer your subscriptions to businesses and schools." It says organizations can purchase the seats they need through one In-App Purchase, then assign and manage those seats with their existing device management tools, and add or remove seats at any time. The same post says multiseat purchasing is enabled by default in App Store Connect unless you'd already changed the setting.

The plumbing arrived over the previous month in the changelogs, not on a stage. App Store Server API 1.22, dated September 28, added the seat fields and group endpoints in sandbox only. On October 23, a one-line server update moved the group endpoints and the ASSIGNMENT_REVOKE value into production. If your notification handler hasn't changed since the summer, it's now receiving data it was never written to read.

Who is opted in by default

Almost everyone. Apple's App Store Connect help page says subscriptions created before September 14, 2026 start opted out only if they don't use StoreKit 2 or have Family Sharing turned on. Subscriptions in custom apps go to Apple Business and Apple School Manager automatically, and you can't opt them out. Changing the setting takes the Account Holder, Admin or App Manager role, and removing Apple Business or Apple School Manager from an approved subscription takes the Account Holder.

How a multiseat purchase shows up on your server

There are now two kinds of transaction for the same subscription. The organization's purchase is one transaction, and its quantity field reports how many seats it bought. Each person who gets a seat receives their own transaction, which Apple's WWDC session describes as the App Store assigning a transaction for each member. Those member transactions carry an inAppOwnershipType of ASSIGNED, alongside the PURCHASED and FAMILY_SHARED values you may already handle.

Apple is firm about which record decides access. Its Get Customer Groups documentation says group membership is separate from entitlement, and that to unlock content you should read the customer's transactions rather than depend on group membership. Grant access from transactions. Use the group endpoints only for features like an admin view.

A removed seat is not a refund

This is the part most handlers will get wrong. When an organization takes a seat away from an employee, Apple sends a REVOKE notification, the same type it uses when a Family Sharing purchaser stops sharing. The transaction's revocationType is ASSIGNMENT_REVOKE, and Apple's instruction is direct: revoke the customer's access to the content the transaction provides.

Nothing in that event says money moved. If your code treats every revocation as a refund, your refund rate, your net revenue and any alerting you've built on top of them will count routine staff turnover as lost sales. Branch on revocationType first.

• ASSIGNMENT_REVOKE: end this person's access. Don't book a refund.
• FAMILY_REVOKE: end the family member's access. Don't book a refund.
• REFUND_FULL: end access and book the full transaction as refunded.
• REFUND_PRORATED: book the share in revocationPercentage, then decide what access remains.

Why you can't defend a refund on an assigned seat

Apple still decides every App Store refund. When a customer asks for one, Apple sends a CONSUMPTION_REQUEST and gives you 12 hours to answer through Send Consumption Information. With multiseat, the person using the app and the person who paid are different people, and Apple's API now draws a hard line between them.

Send Consumption Information rejects assigned transactions

Call Send Consumption Information, its V1 version, or Set App Account Token with an assigned transaction and Apple returns InvalidAssignedTransactionNotSupportedError. Apple's advice is to check for an inAppOwnershipType of ASSIGNED before calling. In practice your evidence goes on the purchaser's transaction or nowhere. Usage your app records against member accounts is still worth keeping, because it's the only way to know whether the seats were used at all.

What a prorated refund looks like

Apple added REFUND_PRORATED and revocationPercentage in December 2025. The consumption request lets you ask for that outcome with a refundPreference of GRANT_PRORATED. For an auto-renewable subscription, Apple says not to send a consumptionPercentage with GRANT_PRORATED, because it calculates the percentage itself. If the refund is later reversed, revocationPercentage disappears from the transaction.

Can I extend one employee's subscription as a goodwill gesture?

No. Extend a Subscription Renewal Date returns AssignedSubscriptionExtensionIneligibleError for an assigned subscription. Apple's reason is that an assigned subscription renews on the same schedule as the one the purchaser bought, so one member can't be moved on their own.

What a multiseat subscription refund costs you

Scale is the new risk. Apple's WWDC session walks through volume pricing with up to five price bands. Its example sells seats at $19.99 a month up to 20 seats, $13.99 for seats 21 to 40, and $10.99 from seat 41. On those numbers, a 50 seat order bills $789.50 a month, about $15.79 a seat. A REFUND_FULL on that one transaction hands back the whole $789.50, not the price of one subscription.

The serving cost scales the same way. Fifty seats mean fifty people running sessions on your servers, making the third-party API calls your features pay for, and filling storage you're billed for. If a refunded order's seat holders keep access because your handler only looked at the purchaser's transaction, you keep paying for every one of them. A missed ASSIGNMENT_REVOKE is smaller but more frequent: the purchase no longer covers that person, and every request they make is cost with no revenue behind it.

Which refund flows ask for your side at all

Multiseat doesn't change the short list. Only two refund flows ask the developer for evidence: Apple's CONSUMPTION_REQUEST, answered through Send Consumption Information within 12 hours, and Google Play's chargeback review, answered through orders.reviewrefund within 24 hours. Everything else is decided without you, and for Google Play orders placed after August 3, 2026, a chargeback costs the developer the purchase price, less Play's service fee, plus the bank's chargeback fees. RefundHalt answers Apple's consumption requests inside the 12-hour window, using the usage data you already collect.

What to change in your App Store handler this week

• Read quantity on every subscription transaction and store it with the purchase.
• Store inAppOwnershipType, and treat ASSIGNED as its own case next to PURCHASED and FAMILY_SHARED.
• Branch REVOKE handling on revocationType, so ASSIGNMENT_REVOKE ends access without booking a refund.
• Book REFUND_PRORATED at the revocationPercentage share, not as a full refund.
• Check for ASSIGNED before calling Send Consumption Information, Set App Account Token or Extend a Subscription Renewal Date.
• Decide in App Store Connect whether you want to sell to organizations at all, before one buys 50 seats.