Un remboursement Family Sharing annule un paiement mais peut laisser cinq autres personnes utilisant encore votre app, et seul votre serveur peut leur couper l'accès

Un seul achat dans un groupe Family Sharing peut confier votre app à six personnes. Celle qui a payé en est une. Les cinq autres n'ont jamais ouvert leur portefeuille, et Apple attend tout de même que votre app fonctionne pour toutes. C'est le marché que vous acceptez au moment où vous activez Family Sharing pour un achat intégré. C'est aussi pourquoi un remboursement Family Sharing est une autre bête qu'un remboursement ordinaire. Quand l'acheteur récupère son argent, la vente s'annule pour un compte, mais l'accès que vous avez accordé à jusqu'à cinq autres personnes ne se coupe pas tout seul. Votre serveur doit le faire, et s'il a été écrit pour ne surveiller que l'acheteur, il ne le fera pas.

Voici le tableau complet en un seul endroit. Ceci parcourt comment Apple marque un achat partagé, le seul champ qui distingue l'acheteur de la famille, exactement quand Apple vous envoie un REVOKE et comment le lire, le détail discret qui sépare un remboursement de quelqu'un qui quitte simplement la famille, et ce qu'un remboursement partagé coûte réellement une fois que vous comptez le calcul que vous avez déjà dépensé pour des personnes qui ne vous ont jamais payé.

Ce que Family Sharing distribue, et à combien de personnes

Activez Family Sharing pour un produit et vous changez qui est votre client payant. Un groupe familial chez Apple peut compter jusqu'à six personnes, un organisateur et jusqu'à cinq membres. Quand n'importe qui du groupe achète un produit partageable en famille, tout le monde dans le groupe y accède. Ils ne paient pas. Ils n'apparaissent pas dans vos revenus. Ils se présentent simplement dans votre app avec un droit valide, parce qu'Apple délivre à chacun d'eux une transaction qui pointe vers le même achat.

Seuls deux types de produit sont partageables, et les consommables n'en font pas partie

Family Sharing couvre exactement deux sortes d'achats intégrés : les non consommables et les abonnements à renouvellement automatique. Les consommables, les produits de pièces et de crédits, ne sont jamais partagés, ce qui explique pourquoi un membre de la famille ne déclenche jamais de CONSUMPTION_REQUEST et n'apparaît pas dans vos rapports de consommation. Si votre app ne vend que des consommables, les remboursements Family Sharing ne sont pas votre problème. Si vous vendez un déverrouillage à vie ou un forfait récurrent, ils le sont.

Le champ qui distingue un acheteur d'un bénéficiaire

Chaque transaction qu'Apple délivre porte un inAppOwnershipType. Il a deux valeurs. PURCHASED signifie que ce compte a payé le produit et peut le gérer, y compris l'annuler ou demander un remboursement. FAMILY_SHARED signifie que ce compte est celui d'un membre de la famille qui a accès grâce à l'achat de quelqu'un d'autre. Les deux donnent à la personne le droit d'utiliser votre produit. Un seul a payé. Le champ se trouve sur la transaction StoreKit, le reçu et l'App Store Server API, si bien que vous pouvez le lire partout où vous vérifiez déjà les droits.

Comment un remboursement Family Sharing atteint votre serveur

Un remboursement sur un achat partagé commence de la même façon que n'importe quel remboursement Apple. L'acheteur, la seule personne qui le peut, demande à Apple de récupérer son argent. Apple décide. Si Apple l'accorde, l'achat de l'acheteur est annulé et Apple envoie à votre serveur une App Store Server Notification REVOKE. Les versions V1 et V2 de la notification la portent. Le REVOKE est votre unique signal que le droit qui le sous-tend, et chaque copie partagée en famille, est désormais nul.

Ne révoquez pas une transaction, relisez tout l'historique

La consigne d'Apple sur un REVOKE est sans détour : ne le traitez pas comme un simple interrupteur. Quand vous en recevez un, parcourez tout l'historique de transactions du client et reconstruisez ses droits de zéro, parce qu'une personne peut détenir plus d'une transaction qui accorde le même produit ou un produit différent. Ne révoquez que la transaction nommée dans la notification et vous pouvez soit laisser un membre de la famille remboursé avec un accès actif, soit couper quelqu'un qui a encore un second droit valide. Rétablissez le tableau complet à chaque fois.

Le seul détail qui sépare un remboursement d'une rupture familiale

Voici le piège qui coûte une après-midi de débogage aux équipes. Un REVOKE peut vouloir dire deux choses très différentes pour une transaction FAMILY_SHARED, et la façon de les distinguer est un champ qui est parfois tout simplement absent. Quand l'acheteur obtient un remboursement, la transaction FAMILY_SHARED arrive avec un revocationDate. Quand un membre de la famille quitte simplement le groupe, le même genre de REVOKE arrive sans aucun revocationDate. Les ingénieurs commerce d'Apple l'ont dit directement sur les forums des développeurs. Dans les deux cas vous retirez l'accès, mais seul celui qui est daté est un remboursement, et seul le remboursement est celui qui a aussi annulé un paiement.

Ce qu'un remboursement partagé vous coûte réellement

Suivez l'argent, car c'est là que Family Sharing change discrètement le calcul. Un remboursement normal annule une vente. Apple rend le prix à l'acheteur et rétrocède sa commission, si bien que le côté boutique s'équilibre presque. Ce qui ne revient jamais, c'est ce que vous avez déjà dépensé pour livrer le produit. Avec Family Sharing, vous ne l'avez pas dépensé une fois. Vous l'avez dépensé pour jusqu'à six personnes. L'acheteur et jusqu'à cinq membres de la famille ont chacun fait tourner votre calcul, appelé vos API, rempli votre stockage et tiré tous les versements que vous financez, le tout sur la base d'un unique paiement.

Maintenant l'acheteur demande un remboursement. L'unique paiement s'annule. L'accès de chaque membre de la famille devrait prendre fin au même moment, parce que ce qui justifiait de les servir, un achat payé, a disparu. Si votre serveur ne révoque que la transaction PURCHASED et laisse les FAMILY_SHARED actives, jusqu'à cinq personnes conservent vos fonctionnalités payantes gratuitement, et vous continuez de payer pour les servir, sans rien qui reste dans le système à facturer. Ce n'est pas une erreur d'arrondi. C'est cinq fois le coût de livraison de la vente que vous venez de rendre.

Les abonnements rendent la fuite récurrente

Pour un non consommable, un membre de la famille non révoqué est une perte unique qui court jusqu'à ce que vous le remarquiez. Pour un abonnement à renouvellement automatique c'est pire, parce que le droit était déjà récurrent. Un remboursement sur la commande d'abonnement devrait mettre fin au partage pour tout le groupe, mais un membre de la famille laissé actif garde le niveau payant à chaque période de facturation où vous ne le clôturez pas. Le correctif est le même, rétablir les droits à partir de l'historique complet à chaque REVOKE, mais le coût de l'omettre s'accumule.

Bien s'y prendre, et le tester avant qu'un vrai remboursement ne le fasse

Il n'y a rien d'exotique à construire ici. Tout le travail consiste à rattacher l'accès au droit, pas à l'acheteur, et à reconstruire cet accès à chaque REVOKE.

• Stockez l'accès rattaché à la transaction et à son inAppOwnershipType, pas à un unique compte d'acheteur, pour qu'une transaction FAMILY_SHARED accorde l'accès par elle-même et puisse être révoquée par elle-même.
• Sur toute notification REVOKE, relisez l'historique complet des transactions du client et recalculez les droits, plutôt que de désactiver la seule transaction nommée.
• Traitez une transaction FAMILY_SHARED avec un revocationDate comme un remboursement et mettez fin à l'accès de ce membre. Traitez-en une sans revocationDate comme un départ de la famille et mettez-y fin aussi.
• Ne précipitez pas un achat partagé tout neuf en service. Apple le retient environ une heure pour que l'acheteur puisse se rétracter, alors honorez la transaction qu'Apple délivre réellement plutôt que d'accorder l'accès au moment de l'appui sur acheter.
• Répétez-le. L'outil Testing Family Sharing d'Apple vous permet de simuler une transaction partagée, et un remboursement en sandbox déclenche le même REVOKE que recevra votre serveur de production.

Faites cela et un remboursement Family Sharing devient un non-événement. L'acheteur récupère son argent, tout le groupe perd l'accès dans le même temps, et vous cessez de payer pour servir des gens qui ne vous payaient jamais.