Apple y Google reembolsan una tienda a la vez, así que tu suscripción multiplataforma tiene que cortar el acceso en todas las demás

Tu suscriptor pagó a Apple, abrió tu app de Android esa misma tarde y ahora usa tu web en el trabajo. Entonces Apple le hace un reembolso. Google Play no lo sabe. Tu facturación web no lo sabe. Salvo que tu propio servidor corte el acceso, una suscripción multiplataforma reembolsada sigue funcionando en cada pantalla que lee tu base de datos de cuentas. Las tiendas reembolsan escaparate por escaparate, y tu sistema de cuentas es el único lugar donde existe la suscripción completa. Eso lo convierte en el único lugar que puede terminarla.

Por qué el reembolso de una tienda no termina una suscripción multiplataforma

Apple permite este esquema de forma explícita. La App Review Guideline 3.1.3(b), Multiplatform Services, dice que las apps que funcionan en varias plataformas pueden permitir a los usuarios acceder a contenido, suscripciones o funciones que adquirieron en tu app en otras plataformas o en tu web, siempre que esos artículos también estén disponibles como compras dentro de la app.

La guía de Apple para ofrecer una misma suscripción en varias apps describe cómo funciona en la práctica. Tu servidor concede el acceso usando una base de datos de cuentas unificada, y todas las apps leen de ella. La misma guía advierte que, si una compra no se propaga a las demás apps, el usuario puede acabar pagando más de una vez por el mismo servicio.

Ese diseño tiene una consecuencia que se suele pasar por alto. El derecho de acceso vive en tu base de datos, pero cada tienda solo conoce sus propios recibos. Apple puede reembolsar la compra del iPhone y avisar a tu servidor. No puede decirle nada a tu app de Android ni a tu web. Si el gestor de reembolsos solo actualiza el cliente de iOS, el cliente recupera su dinero y conserva la suscripción en todo lo demás.

Cómo revocar el acceso en todas las plataformas tras un reembolso

Vincula cada compra a una sola cuenta

Asociar un reembolso a una persona es la parte difícil, porque cada tienda identifica al comprador a su manera. Ambas te dan un campo para tu propio ID de cuenta. Úsalo en todas las compras.

• En Apple, define un appAccountToken, un UUID que generas tú, cuando empieza la compra. El App Store devuelve ese mismo UUID en la información de la transacción y de la renovación. Apple indica que puedes reutilizar un mismo valor para todas las transacciones del mismo cliente.
• Si el cliente compró fuera de tu app, por ejemplo canjeando un código de oferta en el App Store, la transacción no tiene token. El endpoint Set App Account Token lo añade. En una suscripción de renovación automática se aplica a la renovación actual y a las siguientes, no a las transacciones pasadas, y no funciona con compras compartidas mediante En Familia.
• En Google Play, pasa un ID de cuenta ofuscado con setObfuscatedAccountId al iniciar el flujo de facturación. Tiene un límite de 64 caracteres. Google advierte que los datos personales en texto claro, como un correo electrónico, provocan el bloqueo de compras, y recomienda cifrado o un hash unidireccional.

Escucha a ambas tiendas y escribe un único derecho de acceso

Apple envía REFUND cuando reembolsa cualquier tipo de producto, incluidas las suscripciones de renovación automática. Envía REFUND_REVERSED cuando revierte un reembolso que ya había concedido, por una disputa abierta por el cliente. En Google Play, la Voided Purchases API lista las compras reembolsadas y con contracargo, cada una con un orderId que identifica la compra o renovación exacta. Tu procesador web envía su propio evento de reembolso. Los tres deberían llegar al mismo gestor y modificar el mismo registro.

Revoca el derecho de acceso, no la cuenta

Un reembolso anula una compra, no a una persona. Retira el acceso que provenía de la compra reembolsada y vuelve a calcular lo que la cuenta sigue teniendo. Si el cliente tiene además una suscripción activa de otra tienda, conserva el acceso gracias a ella. Si no, todos los clientes pierden las funciones premium la próxima vez que consulten tu servidor.

Cuando la misma persona se suscribe en dos tiendas

Las suscripciones dobles son la otra mitad del problema. Alguien se suscribe en Android, se compra un iPhone nuevo, no inicia sesión y vuelve a suscribirse. Ahora paga dos veces por un mismo servicio, y uno de esos cargos suele acabar en una solicitud de reembolso. El equipo de comercio de Apple, respondiendo a un desarrollador en los Apple Developer Forums, lo dijo sin rodeos: un sistema de cuentas debería incluir lógica para evitar la compra duplicada en otra plataforma.

Consulta todas las tiendas antes de mostrar el muro de pago

Haz que el usuario inicie sesión antes del muro de pago, busca todas sus compras activas en tu servidor y omite la oferta si alguna cubre esta plataforma. Esa sola comprobación evita la mayoría de los cargos duplicados antes de que ocurran.

¿Qué compra debo reembolsar si el duplicado ya ocurrió?

Reembolsa la que controlas. En Google Play puedes emitir el reembolso tú mismo en Play Console, y purchases.subscriptionsv2.cancel con DEVELOPER_REQUESTED_STOP_PAYMENTS detiene el siguiente pago. La suscripción web es tuya y puedes reembolsarla directamente. Los reembolsos del App Store los decide Apple, así que si el duplicado está en el iPhone, el cliente lo solicita a Apple, y tu app puede abrir esa solicitud con la API de solicitud de reembolso de StoreKit.

Lo que te cuesta un reembolso que no llega a una plataforma

El precio reembolsado es solo la primera pérdida. Un cliente cuyo reembolso de Apple nunca llegó a tu app de Android ni a tu web sigue usando lo que tú pagas por mantener. Cada sesión sigue consumiendo cómputo. Cada función de IA sigue haciendo llamadas a APIs de terceros que te facturan. Sus archivos siguen ocupando almacenamiento, y si tu app paga a creadores por visualización o por uso, esos pagos siguen saliendo. En un plan anual, eso puede suponer un año entero de costes de servicio para una cuenta que ya no paga nada.

La vía bancaria lo empeora. En los pedidos de Google Play realizados después del 3 de agosto de 2026, Google indica que, cuando prospera un contracargo, el desarrollador responde del precio de compra, menos la comisión de servicio de Play, más las comisiones de contracargo que cobre la entidad financiera. Un contracargo es definitivo en el banco. Un cliente que ha hecho un contracargo y sigue teniendo acceso te ha costado el precio, las comisiones y el coste de servicio a la vez.

El uso multiplataforma sigue siendo una prueba

Una sola cuenta para todas las plataformas también ayuda cuando una tienda pide tu versión. La información de consumo de Apple pregunta qué parte de un consumible, un no consumible o una suscripción no renovable consumió el cliente. En las suscripciones de renovación automática no envías un porcentaje, porque Apple lo calcula a partir del tiempo transcurrido. La revisión de contracargos de Google Play acepta hasta 1000 eventos de uso de consumo, y cada uno puede llevar el ID de cuenta ofuscado. El uso registrado con un mismo ID de cuenta, sea cual sea el dispositivo que lo generó, es uso que puedes demostrar.

Qué reembolsos nunca piden tu versión

La mayoría de los reembolsos se deciden sin ti. Google Play puede reembolsar una compra en un plazo de 48 horas mediante su propio flujo de reembolso. Los reembolsos del soporte de la tienda, las compras anuladas y el reembolso automático de Google de las compras que nunca confirmas, a las 72 horas aproximadamente, ocurren primero y se notifican después. En esos casos, la lógica de revocación anterior es todo el trabajo.

Solo dos flujos piden pruebas. El CONSUMPTION_REQUEST de Apple te da 12 horas para enviar la información de consumo. La revisión de contracargos de Google Play te da 24 horas desde la PendingRefundReviewNotification para responder mediante orders.reviewrefund, y Google solo registra tu primera llamada. RefundHalt responde a ambos dentro del plazo, con los datos de uso que ya recopilas, vinculados a la misma cuenta en todas tus apps.

Lista de comprobación breve para reembolsos multiplataforma

• Define appAccountToken en las compras de Apple y un ID de cuenta ofuscado en las compras de Google Play.
• Completa los tokens de Apple que falten con Set App Account Token en los canjes de códigos de oferta.
• Dirige REFUND y REFUND_REVERSED de Apple, las compras anuladas de Google Play y los reembolsos web a un único gestor.
• Guarda cada compra con su origen y calcula el acceso a partir de todas las compras activas.
• Consulta las compras de todas las tiendas antes de mostrar un muro de pago en cualquier plataforma.