Los reembolsos de suscripciones no funcionan como los reembolsos de un solo pago, y la tienda en la que estás decide cuánta voz tienes

Reembolsar una suscripción y reembolsar una única compra dentro de la aplicación parecen el mismo botón. No lo son. Una compra de un solo pago es un cargo que devuelves. Una suscripción es un cargo recurrente con un derecho activo asociado, así que los reembolsos de suscripciones tienen que responder a dos preguntas que un reembolso de un solo pago nunca hace: cuánto del periodo actual devuelves, y si la suscripción sigue funcionando. La App Store y Google Play responden a esas dos preguntas de formas opuestas, y esa diferencia decide cuánto control tienes y cuánto dinero sale de tu cuenta.

Este es el mapa breve. En la App Store, Apple es dueña de la decisión y tú te enteras después. En Google Play, tú tienes los mandos y eliges completo o prorrateado por tu cuenta. Esto recorre ambas tiendas, los campos y notificaciones exactos que usa cada una, qué pedido tocas cuando una suscripción ha facturado muchas veces, y lo que realmente cuesta un reembolso de suscripción una vez que cuentas el cómputo que ya gastaste.

En qué se diferencian los reembolsos de suscripciones de los reembolsos de un solo pago

Ambas tiendas tratan un reembolso como la reversión de un pedido concreto. En una compra de un solo pago solo hay un pedido, así que no hay nada que elegir. Una suscripción es una cadena de pedidos, uno por periodo de facturación, con un derecho que está activo o no lo está. Esa estructura es la razón por la que un reembolso de suscripción conlleva decisiones que un reembolso de un solo pago no tiene.

La unidad que se revierte es un periodo de facturación

Cuando reembolsas una suscripción, no estás devolviendo toda una vida de pagos. Estás actuando sobre un pedido de la cadena, normalmente el más reciente, que es un único periodo de facturación. Un reembolso completo devuelve todo ese periodo. Un reembolso prorrateado devuelve solo la parte del periodo que el cliente aún no ha usado. En cualquier caso, la venta que reviertes es el precio de un periodo, no todo el historial del cliente con la app.

Quién decide es la verdadera diferencia

La división más marcada es la autoridad. En la App Store, Apple decide si un reembolso de suscripción llega a ocurrir siquiera, y tú aportas contexto como mucho. En Google Play, tú decides, y la API hace exactamente lo que le indicas. El mismo resultado para el cliente, un asiento completamente distinto para el desarrollador, y cambia lo que construyes para gestionar cada uno.

Cómo gestiona la App Store un reembolso de suscripción

Del lado de Apple eres un espectador con un pequeño micrófono. El cliente habla con Apple, Apple toma la decisión, y tu servidor lee el resultado.

El cliente lo pide a Apple, y Apple resuelve

Un cliente de la App Store solicita un reembolso de suscripción en reportaproblem.apple.com, no a ti. Apple revisa la solicitud con sus propias señales y decide. Tú no lo apruebas, y no hay ningún botón en la consola de Apple que te permita emitir un reembolso de suscripción como hace Google Play. Apple tiene hasta 90 días desde la compra para aceptar una solicitud a revisión, y una vez que resuelve, la decisión es de Apple.

Lo que ve tu servidor cuando llega el reembolso

Te enteras del resultado mediante App Store Server Notifications V2. Un reembolso concedido llega como una notificación REFUND, y la transacción ahora lleva un revocationDate que marca cuándo debe terminar el acceso. El autoRenewStatus de la suscripción se establece en false, de modo que deja de renovarse y el cliente pierde el derecho. Si Apple deniega la solicitud recibes REFUND_DECLINED, y si Apple después deshace un reembolso que ya había concedido recibes REFUND_REVERSED y la suscripción vuelve. Tu tarea es leer esto y cambiar el acceso, no emitir un voto.

Apple mide una suscripción por el tiempo, no por tus métricas

En un consumible, puedes decirle a Apple cuánto se usó mediante los datos de consumo. En una suscripción de renovación automática, Apple calcula el consumo a partir del tiempo transcurrido por su cuenta. El propio ejemplo de Apple es un cliente que lleva seis meses en una suscripción anual, que ha consumido cerca del 50 por ciento de ella. Así que tus métricas de uso no fijan la cifra en una suscripción. La única palanca que puedes accionar es refundPreference, y en una suscripción el valor relevante es GRANT_PRORATED, que indica que preferirías que Apple devuelva solo la parte no utilizada. Es una preferencia, no una decisión. Apple sigue resolviendo.

Cómo gestiona Google Play un reembolso de suscripción

Google Play pone la decisión en tus manos. Hay una pantalla en Play Console y un conjunto de métodos de API que te permiten reembolsar una suscripción directamente, elegir cuánto, y decidir si el acceso termina. Esta es la postura opuesta a la de Apple, y viene con decisiones que tienes que acertar.

Completo o prorrateado, y la decisión es tuya

La forma actual de reembolsar y revocar una suscripción es purchases.subscriptionsv2.revoke, llamada con un revocationContext. Pasa fullRefund y Google Play finaliza la suscripción y devuelve el importe completo del periodo de facturación actual. Pasa proratedRefund y Google Play finaliza la suscripción y devuelve solo el tiempo de derecho restante y no utilizado. El método antiguo solo podía hacer reembolsos completos, que es la razón para usar el más nuevo. Una revocación prorrateada es un cuerpo de dos líneas, un revocationContext que envuelve proratedRefund, y cambias a fullRefund para todo el periodo. Cualquiera de las dos revocaciones dispara una notificación en tiempo real para desarrolladores SUBSCRIPTION_REVOKED, que es tu señal para cortar el acceso.

Qué pedido reembolsas cambia lo que ocurre

Google Play también te permite reembolsar un pedido sin revocar, mediante orders.refund, y aquí muerde una regla sutil. Si reembolsas el pedido más reciente de una suscripción, el pedido se reembolsa, la suscripción se elimina de inmediato, y las recurrencias futuras se cancelan. Si reembolsas un pedido más antiguo de la cadena, ese pedido se reembolsa pero la suscripción permanece activa. En orders.refund el parámetro revoke solo revoca cuando el pedido es el más reciente, así que para terminar el acceso en una suscripción activa usas purchases.subscriptionsv2.revoke en su lugar.

Los límites que hacen tropezar a los desarrolladores

Unos cuantos bordes duros pillan a la gente, y ninguno está en el camino feliz.

• Los pedidos de más de tres años no se pueden reembolsar en absoluto.
• Los reembolsos parciales solo funcionan en pedidos realizados después de March 2018, y nunca en compras de apps de pago.
• Puedes acumular varios reembolsos parciales en un pedido, pero no hasta ni por encima del total del pedido.
• Un reembolso no se puede revertir una vez emitido.

Google Play suele devolver una decisión de reembolso en un día, aunque puede tardar hasta cuatro. Prevé ese retraso cuando un reembolso deba reflejarse en tus propios controles de acceso.

Lo que realmente te cuesta un reembolso de suscripción

El cargo reembolsado nunca es la factura completa. En el momento en que se entregó un pedido de suscripción, ya habías gastado dinero real en él: cómputo, llamadas a la API del modelo, almacenamiento, y cualquier pago vinculado a ese periodo. Un reembolso devuelve la venta. No devuelve lo que gastaste para servirla. En una suscripción, la forma de la pérdida depende de qué reembolso emitas.

Completo frente a prorrateado es una decisión de dinero

Un reembolso completo en Google Play devuelve todo el periodo actual, así que pierdes los ingresos de todo el periodo mientras mantienes cada coste en el que ya incurriste ese periodo. Un reembolso prorrateado devuelve solo la porción no utilizada, así que conservas los ingresos de la parte que el cliente realmente tuvo. Si un cliente lleva el 60 por ciento de un periodo mensual en un plan de 10 dólares, un reembolso completo te cuesta los 10 dólares íntegros, y un reembolso prorrateado te cuesta unos 4 dólares, el 40 por ciento no utilizado. Apple aplica la misma lógica de tiempo transcurrido de su lado cuando dimensiona un reembolso de suscripción.

Los costes que nunca vuelven

Sea cual sea el reembolso que emitas, los costes posteriores de ese periodo se han ido. Una llamada a la API de un modelo que pagaste, un vídeo que renderizaste, almacenamiento que aprovisionaste, un pago a un creador que ya enviaste, nada de eso se revierte cuando el reembolso de suscripción se liquida. Dimensiona el reembolso según lo que el cliente realmente usó, nunca según hace cuánto se suscribió, porque el tiempo transcurrido no es un coste y ninguna de las dos tiendas lo trata como tal. Y después del August 3, 2026, si un cargo de suscripción de Google Play acaba en un contracargo bancario en lugar de un reembolso que emitas tú, también absorbes la comisión de contracargo del banco, que un reembolso que concedes primero evita.

Cómo gestionar los reembolsos de suscripciones sin una persona vigilando

Nada de esto debería esperar a que alguien lea un panel. Las notificaciones llegan a cualquier hora, y el acceso debería cambiar en el momento en que llega un reembolso, no a la mañana siguiente.

Lee el resultado y revoca el acceso en ambas tiendas

En la App Store, escucha REFUND, REFUND_DECLINED y REFUND_REVERSED, y usa el revocationDate y el autoRenewStatus para terminar o restaurar el acceso automáticamente. En Google Play, escucha SUBSCRIPTION_REVOKED y las señales de compra anulada y haz lo mismo. Esta es la fontanería que RefundHalt ejecuta por ti: entra la notificación, se busca la cuenta, se cambia el acceso, ninguna persona en el bucle.

Ten las pruebas listas antes de la disputa

Las ventanas estrechas que sí piden tu aportación, el CONSUMPTION_REQUEST de 12 horas de Apple en consumibles y la revisión de contracargo de 24 horas de Google Play, solo ayudan si las pruebas ya existen. Adjunta un identificador de cuenta a cada compra, un appAccountToken UUID en Apple y un setObfuscatedAccountId con hash de 64 caracteres o menos en Google Play, y registra lo que entregó cada periodo pagado. Entonces, cuando llega un token, el caso ya está construido, y responder dentro de la ventana es trabajo de una máquina, no una carrera a contrarreloj.