Apple ya vende tu suscripción a empresas enteras por puestos, y el reembolso de una suscripción multipuesto funciona de otra manera

Apple empezó a vender suscripciones de apps a organizaciones por puestos el 22 de octubre de 2026, y activó la opción para la mayoría de los desarrolladores sin preguntar. Las empresas y los centros educativos que usan Apple Business o Apple School Manager ya pueden comprar tu suscripción autorrenovable en bloque mediante una sola compra In-App. Eso cambia cómo se ve en tu servidor el reembolso de una suscripción multipuesto. Una transacción puede pagar ahora por decenas de personas, un puesto puede desaparecer sin ningún reembolso, y el endpoint que usas para defender un caso de reembolso se niega a hablar de las personas que de verdad usan la app.

Qué activó Apple y dónde lo anunció

El lanzamiento llegó como una breve noticia de Apple Developer titulada «Offer your subscriptions to businesses and schools». Dice que las organizaciones pueden comprar los puestos que necesitan mediante una sola compra In-App, asignarlos y gestionarlos con sus herramientas de gestión de dispositivos actuales, y añadir o retirar puestos en cualquier momento. La misma noticia dice que la compra multipuesto está activada por defecto en App Store Connect, salvo que ya hubieras cambiado el ajuste.

La infraestructura llegó durante el mes anterior en los registros de cambios, no en un escenario. La versión 1.22 de App Store Server API, del 28 de septiembre, añadió los campos de puestos y los endpoints de grupos solo en sandbox. El 23 de octubre, una actualización de servidor de una línea llevó los endpoints de grupos y el valor ASSIGNMENT_REVOKE a producción. Si tu gestor de notificaciones no ha cambiado desde el verano, ahora recibe datos que nunca se escribió para leer.

Quién queda activado por defecto

Casi todo el mundo. La página de ayuda de App Store Connect dice que las suscripciones creadas antes del 14 de septiembre de 2026 empiezan desactivadas solo si no usan StoreKit 2 o tienen En familia activado. Las suscripciones de apps personalizadas pasan automáticamente a Apple Business y Apple School Manager, y no puedes desactivarlas. Cambiar el ajuste requiere el rol de Titular de la cuenta, Administrador o Gestor de apps, y retirar Apple Business o Apple School Manager de una suscripción aprobada requiere al Titular de la cuenta.

Cómo aparece una compra multipuesto en tu servidor

Ahora hay dos tipos de transacción para la misma suscripción. La compra de la organización es una transacción, y su campo quantity indica cuántos puestos compró. Cada persona que recibe un puesto obtiene su propia transacción, algo que la sesión de WWDC de Apple describe como el App Store asignando una transacción a cada miembro. Esas transacciones de miembros llevan un inAppOwnershipType de ASSIGNED, junto a los valores PURCHASED y FAMILY_SHARED que quizá ya gestionas.

Apple es tajante sobre qué registro decide el acceso. Su documentación de Get Customer Groups dice que la pertenencia a un grupo es independiente del derecho de acceso, y que para desbloquear contenido debes leer las transacciones del cliente en lugar de depender de la pertenencia al grupo. Concede el acceso a partir de las transacciones. Usa los endpoints de grupos solo para funciones como una vista de administración.

Un puesto retirado no es un reembolso

Aquí es donde fallará la mayoría de los gestores. Cuando una organización quita un puesto a un empleado, Apple envía una notificación REVOKE, el mismo tipo que usa cuando quien compró con En familia deja de compartir. El revocationType de la transacción es ASSIGNMENT_REVOKE, y la instrucción de Apple es directa: revoca el acceso del cliente al contenido que proporciona la transacción.

Nada en ese evento dice que se haya movido dinero. Si tu código trata cada revocación como un reembolso, tu tasa de reembolsos, tus ingresos netos y cualquier alerta que hayas construido sobre ellos contarán la rotación normal de personal como ventas perdidas. Ramifica primero por revocationType.

• ASSIGNMENT_REVOKE: termina el acceso de esta persona. No registres un reembolso.
• FAMILY_REVOKE: termina el acceso del miembro de la familia. No registres un reembolso.
• REFUND_FULL: termina el acceso y registra la transacción completa como reembolsada.
• REFUND_PRORATED: registra la parte indicada en revocationPercentage y luego decide qué acceso se mantiene.

Por qué no puedes defender un reembolso de un puesto asignado

Apple sigue decidiendo cada reembolso del App Store. Cuando un cliente lo solicita, Apple envía un CONSUMPTION_REQUEST y te da 12 horas para responder mediante Send Consumption Information. Con el modelo multipuesto, la persona que usa la app y la persona que pagó son distintas, y la API de Apple ahora traza una línea firme entre ambas.

Send Consumption Information rechaza las transacciones asignadas

Si llamas a Send Consumption Information, a su versión V1 o a Set App Account Token con una transacción asignada, Apple devuelve InvalidAssignedTransactionNotSupportedError. Apple aconseja comprobar si el inAppOwnershipType es ASSIGNED antes de llamar. En la práctica, tus pruebas van en la transacción del comprador o en ninguna parte. El uso que tu app registra en las cuentas de los miembros sigue valiendo la pena, porque es la única forma de saber si los puestos se llegaron a usar.

Cómo es un reembolso prorrateado

Apple añadió REFUND_PRORATED y revocationPercentage en diciembre de 2025. La solicitud de consumo te permite pedir ese resultado con un refundPreference de GRANT_PRORATED. Para una suscripción autorrenovable, Apple indica que no envíes un consumptionPercentage con GRANT_PRORATED, porque calcula el porcentaje por su cuenta. Si el reembolso se revierte más tarde, revocationPercentage desaparece de la transacción.

¿Puedo ampliar la suscripción de un solo empleado como gesto de buena voluntad?

No. Extend a Subscription Renewal Date devuelve AssignedSubscriptionExtensionIneligibleError para una suscripción asignada. Apple explica que una suscripción asignada se renueva con el mismo calendario que la que compró el comprador, así que no se puede mover a un solo miembro por separado.

Lo que te cuesta el reembolso de una suscripción multipuesto

La escala es el nuevo riesgo. La sesión de WWDC de Apple explica los precios por volumen con hasta cinco tramos. Su ejemplo vende puestos a 19,99 $ al mes hasta 20 puestos, 13,99 $ del puesto 21 al 40 y 10,99 $ a partir del puesto 41. Con esas cifras, un pedido de 50 puestos factura 789,50 $ al mes, unos 15,79 $ por puesto. Un REFUND_FULL sobre esa única transacción devuelve los 789,50 $ completos, no el precio de una suscripción.

El coste de servicio escala igual. Cincuenta puestos son cincuenta personas abriendo sesiones en tus servidores, haciendo las llamadas a APIs de terceros que pagan tus funciones y llenando un almacenamiento que te facturan. Si los titulares de puestos de un pedido reembolsado conservan el acceso porque tu gestor solo miró la transacción del comprador, sigues pagando por cada uno de ellos. Un ASSIGNMENT_REVOKE perdido es menor pero más frecuente: la compra ya no cubre a esa persona, y cada petición que hace es coste sin ingresos detrás.

Qué flujos de reembolso piden tu versión

El modelo multipuesto no cambia la lista corta. Solo dos flujos de reembolso piden pruebas al desarrollador: el CONSUMPTION_REQUEST de Apple, respondido mediante Send Consumption Information en 12 horas, y la revisión de contracargos de Google Play, respondida mediante orders.reviewrefund en 24 horas. Todo lo demás se decide sin ti, y para los pedidos de Google Play realizados después del 3 de agosto de 2026, un contracargo le cuesta al desarrollador el precio de compra, menos la comisión de servicio de Play, más las comisiones de contracargo del banco. RefundHalt responde a las solicitudes de consumo de Apple dentro del plazo de 12 horas, con los datos de uso que ya recopilas.

Qué cambiar en tu gestor del App Store esta semana

• Lee quantity en cada transacción de suscripción y guárdalo con la compra.
• Guarda inAppOwnershipType y trata ASSIGNED como un caso propio junto a PURCHASED y FAMILY_SHARED.
• Ramifica la gestión de REVOKE por revocationType, para que ASSIGNMENT_REVOKE termine el acceso sin registrar un reembolso.
• Registra REFUND_PRORATED por la parte de revocationPercentage, no como un reembolso completo.
• Comprueba ASSIGNED antes de llamar a Send Consumption Information, Set App Account Token o Extend a Subscription Renewal Date.
• Decide en App Store Connect si quieres vender a organizaciones, antes de que una compre 50 puestos.