A Family Sharing refund reverses one payment but can leave five other people still using your app, and only your server can cut them off

One purchase in a Family Sharing group can hand your app to six people. The person who paid is one of them. The other five never opened their wallet, and Apple still expects your app to work for all of them. That is the deal you opt into the moment you turn on Family Sharing for an in-app purchase. It is also why a Family Sharing refund is a different animal from an ordinary one. When the buyer gets their money back, the sale reverses for one account, but the access you granted to as many as five other people does not switch off on its own. Your server has to do that, and if it was written to watch only the buyer, it will not.

Here is the whole picture in one place. This walks through how Apple marks a shared purchase, the one field that tells the buyer apart from the family, exactly when Apple sends you a REVOKE and how to read it, the quiet detail that separates a refund from someone just leaving the family, and what a shared refund actually costs once you count the compute you already spent on people who never paid you.

What Family Sharing hands out, and to how many people

Turn on Family Sharing for a product and you change who your paying customer is. A family group on Apple can hold up to six people, one organizer and up to five members. When anyone in the group buys a family-shareable product, everyone in the group gets access to it. They do not pay. They do not appear in your revenue. They just show up in your app with a valid entitlement, because Apple issues each of them a transaction that points at the same purchase.

Only two product types are shareable, and consumables are not one of them

Family Sharing covers exactly two kinds of in-app purchase: non-consumables and auto-renewable subscriptions. Consumables, the coins-and-credits products, are never shared, which is why a family member never triggers a CONSUMPTION_REQUEST or shows up in your consumption reporting. If your app sells only consumables, Family Sharing refunds are not your problem. If you sell a lifetime unlock or a recurring plan, they are.

The field that tells a buyer from a beneficiary

Every transaction Apple issues carries an inAppOwnershipType. It has two values. PURCHASED means this account paid for the product and can manage it, including cancel it or request a refund. FAMILY_SHARED means this account is a family member who has access through someone else's purchase. Both entitle the person to use your product. Only one of them paid. The field is on the StoreKit transaction, the receipt, and the App Store Server API, so you can read it wherever you already check entitlements.

How a Family Sharing refund reaches your server

A refund on a shared purchase starts the same way any Apple refund does. The buyer, the only person who can, asks Apple for their money back. Apple decides. If Apple grants it, the buyer's purchase is reversed and Apple sends your server a REVOKE App Store Server Notification. Both V1 and V2 of the notification carry it. The REVOKE is your one signal that the entitlement behind it, and every family-shared copy of it, is now void.

Do not revoke one transaction, re-read the whole history

Apple's guidance on a REVOKE is blunt: do not treat it as a single toggle. When you get one, walk the customer's entire transaction history and rebuild their entitlements from scratch, because a person can hold more than one transaction that grants the same or a different product. Revoke only the transaction named in the notification and you can either strand a refunded family member with live access, or cut off someone who still has a valid second entitlement. Reestablish the full picture every time.

The one detail that separates a refund from a family breakup

Here is the trap that costs teams a debugging afternoon. A REVOKE can mean two very different things for a FAMILY_SHARED transaction, and the way you tell them apart is a field that is sometimes simply absent. When the buyer gets a refund, the FAMILY_SHARED transaction comes with a revocationDate. When a family member just leaves the group, the same kind of REVOKE arrives with no revocationDate at all. Apple's commerce engineers have said so directly on the developer forums. Either way you pull the access, but only the dated one is a refund, and only the refund is the one that also reversed a payment.

What a shared refund actually costs you

Walk the money, because this is where Family Sharing quietly changes the math. A normal refund reverses one sale. Apple returns the price to the buyer and hands its commission back, so the store side nets close to even. What never comes back is what you already spent delivering the product. With Family Sharing, you did not spend it once. You spent it for as many as six people. The buyer and up to five family members each ran your compute, called your APIs, filled your storage, and pulled any payouts you fund, all on the strength of a single payment.

Now the buyer refunds. The one payment reverses. Every family member's access should end at the same moment, because the thing that justified serving them, one paid purchase, is gone. If your server revokes only the PURCHASED transaction and leaves the FAMILY_SHARED ones live, up to five people keep your paid features for free, and you keep paying to serve them, with nothing left in the system to bill against. That is not a rounding error. It is five times the delivery cost of the sale you just gave back.

Subscriptions make the leak recurring

For a non-consumable, an unrevoked family member is a one-time loss that runs until you notice. For an auto-renewable subscription it is worse, because the entitlement was already recurring. A refund on the subscription order should end sharing for the whole group, but a family member left live keeps the paid tier every billing period you fail to close them out. The fix is the same, reestablish entitlements from the full history on every REVOKE, but the cost of skipping it compounds.

Getting it right, and testing it before a real refund does

There is nothing exotic to build here. The whole job is to key access off the entitlement, not off the buyer, and to rebuild that access on every REVOKE.

• Store access against the transaction and its inAppOwnershipType, not against a single buyer account, so a FAMILY_SHARED transaction grants access on its own and can be revoked on its own.
• On any REVOKE notification, re-read the customer's full transaction history and recompute entitlements, rather than flipping off the one transaction named.
• Treat a FAMILY_SHARED transaction with a revocationDate as a refund and end that member's access. Treat one without a revocationDate as a family departure and end it too.
• Do not rush a brand-new shared purchase into service. Apple holds it for about an hour so the buyer can back out, so honor the transaction Apple actually issues rather than granting on the buy tap.
• Rehearse it. Apple's Testing Family Sharing tooling lets you simulate a shared transaction, and a sandbox refund fires the same REVOKE your production server will get.

Do that and a Family Sharing refund becomes a non-event. The buyer gets their money, the whole group loses access in the same beat, and you stop paying to serve people who were never paying you.