Un reembolso de Family Sharing revierte un pago pero puede dejar a otras cinco personas usando tu app, y solo tu servidor puede cortarles el acceso

Una compra en un grupo de Family Sharing puede entregar tu app a seis personas. La persona que pagó es una de ellas. Las otras cinco nunca abrieron su cartera, y Apple aun así espera que tu app funcione para todas. Ese es el trato que aceptas en el momento en que activas Family Sharing para una compra dentro de la app. También es la razón por la que un reembolso de Family Sharing es un animal distinto de uno corriente. Cuando el comprador recupera su dinero, la venta se revierte para una cuenta, pero el acceso que concediste hasta a cinco personas más no se apaga solo. Tu servidor tiene que hacerlo, y si se escribió para vigilar solo al comprador, no lo hará.

Aquí tienes el panorama completo en un solo lugar. Esto recorre cómo marca Apple una compra compartida, el único campo que distingue al comprador de la familia, exactamente cuándo te envía Apple un REVOKE y cómo leerlo, el detalle silencioso que separa un reembolso de alguien que simplemente abandona la familia, y lo que un reembolso compartido cuesta de verdad una vez que cuentas el cómputo que ya gastaste en personas que nunca te pagaron.

Qué reparte Family Sharing, y a cuántas personas

Activa Family Sharing para un producto y cambias quién es tu cliente de pago. Un grupo familiar en Apple puede tener hasta seis personas, un organizador y hasta cinco miembros. Cuando alguien del grupo compra un producto compartible en familia, todos en el grupo obtienen acceso a él. No pagan. No aparecen en tus ingresos. Simplemente aparecen en tu app con un derecho válido, porque Apple emite a cada uno una transacción que apunta a la misma compra.

Solo dos tipos de producto son compartibles, y los consumibles no son uno de ellos

Family Sharing cubre exactamente dos clases de compra dentro de la app: no consumibles y suscripciones de renovación automática. Los consumibles, los productos de monedas y créditos, nunca se comparten, y por eso un miembro de la familia nunca dispara un CONSUMPTION_REQUEST ni aparece en tus informes de consumo. Si tu app vende solo consumibles, los reembolsos de Family Sharing no son tu problema. Si vendes un desbloqueo de por vida o un plan recurrente, sí lo son.

El campo que distingue a un comprador de un beneficiario

Cada transacción que Apple emite lleva un inAppOwnershipType. Tiene dos valores. PURCHASED significa que esta cuenta pagó por el producto y puede gestionarlo, incluido cancelarlo o solicitar un reembolso. FAMILY_SHARED significa que esta cuenta es un miembro de la familia que tiene acceso a través de la compra de otra persona. Ambos dan derecho a la persona a usar tu producto. Solo uno de ellos pagó. El campo está en la transacción de StoreKit, el recibo y la App Store Server API, así que puedes leerlo dondequiera que ya compruebes los derechos.

Cómo llega a tu servidor un reembolso de Family Sharing

Un reembolso de una compra compartida empieza igual que cualquier reembolso de Apple. El comprador, la única persona que puede, pide a Apple que le devuelvan el dinero. Apple decide. Si Apple lo concede, la compra del comprador se revierte y Apple envía a tu servidor una notificación REVOKE de App Store Server. Tanto la V1 como la V2 de la notificación la llevan. El REVOKE es tu única señal de que el derecho asociado, y cada copia compartida en familia del mismo, ahora es nulo.

No revoques una transacción, vuelve a leer todo el historial

La recomendación de Apple sobre un REVOKE es tajante: no lo trates como un simple interruptor. Cuando recibas uno, recorre todo el historial de transacciones del cliente y reconstruye sus derechos desde cero, porque una persona puede tener más de una transacción que conceda el mismo producto o uno distinto. Revoca solo la transacción nombrada en la notificación y puedes dejar a un miembro de la familia reembolsado con acceso activo, o cortar a alguien que aún tiene un segundo derecho válido. Restablece el panorama completo cada vez.

El único detalle que separa un reembolso de una ruptura familiar

Aquí está la trampa que cuesta a los equipos una tarde de depuración. Un REVOKE puede significar dos cosas muy distintas para una transacción FAMILY_SHARED, y la manera de distinguirlas es un campo que a veces simplemente está ausente. Cuando el comprador recibe un reembolso, la transacción FAMILY_SHARED viene con un revocationDate. Cuando un miembro de la familia solo abandona el grupo, el mismo tipo de REVOKE llega sin ningún revocationDate. Los ingenieros de comercio de Apple lo han dicho directamente en los foros de desarrolladores. En ambos casos retiras el acceso, pero solo el que lleva fecha es un reembolso, y solo el reembolso es el que además revirtió un pago.

Lo que un reembolso compartido te cuesta de verdad

Sigue el dinero, porque aquí es donde Family Sharing cambia las cuentas en silencio. Un reembolso normal revierte una venta. Apple devuelve el precio al comprador y regresa su comisión, así que el lado de la tienda queda casi a la par. Lo que nunca vuelve es lo que ya gastaste entregando el producto. Con Family Sharing, no lo gastaste una vez. Lo gastaste para hasta seis personas. El comprador y hasta cinco miembros de la familia ejecutaron cada uno tu cómputo, llamaron a tus APIs, llenaron tu almacenamiento y sacaron cualquier pago que financies, todo por la fuerza de un solo pago.

Ahora el comprador reembolsa. El único pago se revierte. El acceso de cada miembro de la familia debería terminar en el mismo momento, porque aquello que justificaba servirles, una compra pagada, ha desaparecido. Si tu servidor revoca solo la transacción PURCHASED y deja activas las FAMILY_SHARED, hasta cinco personas conservan tus funciones de pago gratis, y tú sigues pagando por servirles, sin nada en el sistema contra lo que facturar. Eso no es un error de redondeo. Es cinco veces el coste de entrega de la venta que acabas de devolver.

Las suscripciones hacen la fuga recurrente

Para un no consumible, un miembro de la familia no revocado es una pérdida única que corre hasta que te das cuenta. Para una suscripción de renovación automática es peor, porque el derecho ya era recurrente. Un reembolso de la orden de suscripción debería terminar el uso compartido para todo el grupo, pero un miembro de la familia que queda activo conserva el nivel de pago en cada periodo de facturación en el que no lo cierres. La solución es la misma, restablecer los derechos a partir del historial completo en cada REVOKE, pero el coste de saltártelo se acumula.

Hacerlo bien, y probarlo antes de que lo haga un reembolso real

No hay nada exótico que construir aquí. Todo el trabajo consiste en basar el acceso en el derecho, no en el comprador, y en reconstruir ese acceso en cada REVOKE.

• Guarda el acceso frente a la transacción y su inAppOwnershipType, no frente a una única cuenta de comprador, para que una transacción FAMILY_SHARED conceda acceso por sí sola y pueda revocarse por sí sola.
• Ante cualquier notificación REVOKE, vuelve a leer todo el historial de transacciones del cliente y recalcula los derechos, en lugar de apagar la única transacción nombrada.
• Trata una transacción FAMILY_SHARED con un revocationDate como un reembolso y termina el acceso de ese miembro. Trata una sin revocationDate como una salida familiar y termínalo también.
• No apresures un producto compartido recién comprado a ponerse en servicio. Apple lo retiene cerca de una hora para que el comprador pueda echarse atrás, así que respeta la transacción que Apple realmente emite en lugar de conceder acceso al tocar comprar.
• Ensáyalo. La herramienta Testing Family Sharing de Apple te deja simular una transacción compartida, y un reembolso de sandbox dispara el mismo REVOKE que recibirá tu servidor de producción.

Haz eso y un reembolso de Family Sharing se convierte en un no evento. El comprador recibe su dinero, todo el grupo pierde el acceso en el mismo compás, y dejas de pagar por servir a personas que nunca te pagaban.