Cada tipo de compra dentro de la aplicación se reembolsa de forma diferente, y solo dos de ellos piden tu versión

El tipo de compra dentro de la aplicación que elegiste en App Store Connect o en la Play Console decide más que cómo se vende el producto. Decide cómo se comporta un reembolso cuando llega, si el cliente puede recuperar el artículo gratis después, y si alguna vez te piden tu versión antes de que se mueva el dinero. Un paquete de monedas, un desbloqueo de por vida, una suscripción mensual y un pase de temporada puntual son cuatro objetos legales y técnicos distintos, y las reglas de reembolso los tratan así. La mayoría de los desarrolladores lanzan todos ellos con el mismo código de compra y luego se preguntan por qué los reembolsos parecen inconsistentes. No son inconsistentes. Son específicos de cada tipo.

Esto es lo que es cada tipo de compra dentro de la aplicación, cómo le afecta un reembolso, y por qué solo dos de los cuatro dirigen la decisión a través de tu servidor.

Los cuatro tipos de compra dentro de la aplicación, y por qué los reembolsos se dividen según ellos

Apple define cuatro tipos de producto. Un consumible se agota y se compra de nuevo: moneda de juego, pistas, una recarga de energía. Un no consumible se compra una vez y se conserva para siempre: un desbloqueo pro, una mejora sin anuncios, un paquete de niveles descargable. Una suscripción de renovación automática se cobra en un ciclo repetido hasta que el cliente cancela. Una suscripción sin renovación concede acceso durante un periodo fijo que no se renueva por sí solo, como una temporada de contenido vendida como un único término.

Google Play organiza el mismo catálogo de forma diferente pero llega al mismo lugar. Divide los productos en productos de pago único y suscripciones, y un producto de pago único se marca como consumible o no según si tu aplicación lo consume tras la compra. Las palabras difieren. Las consecuencias del reembolso no.

Los consumibles son el tipo al que el fraude de reembolsos apunta de verdad

Un consumible es el caso de reembolso más difícil al que te enfrentarás, y no es casualidad que sea aquel en torno al cual Apple construyó la solicitud de consumo. En el momento en que un cliente compra 10,000 monedas y tu servidor se las concede, el valor está entregado. Si las gasta y luego solicita un reembolso, la tienda puede devolverle su dinero, pero las monedas ya no están y tampoco lo que te costó concederlas. Las propias herramientas de Apple lo reflejan: un consumible abandona el registro de la transacción una vez completado y nunca lleva una fecha de cancelación, porque no hay nada persistente que cancelar.

Por eso el consumible es el tipo de producto donde las pruebas rinden. Cuando un cliente solicita un reembolso de un consumible, Apple envía a tu servidor un CONSUMPTION_REQUEST y espera hasta 12 horas por una llamada Send Consumption Information. En esa llamada estableces un deliveryStatus y, cuando has entregado, un consumptionPercentage. El porcentaje es un entero en milésimas de 0 a 100,000, donde 100,000 significa que el cliente usó toda la compra. Un saldo de monedas que tus registros muestran totalmente gastado es un 100,000 que puedes informar, y es el hecho más sólido que puedes presentar ante una reclamación de compra no intencionada.

Los consumibles no pueden restaurarse, así que el momento lo es todo

Como un consumible no puede restaurarse, no puedes recuperarlo como puedes revocar una suscripción. Una vez concedido un reembolso, tu única protección es el registro que guardaste en el momento de la venta. Si no registraste la entrega y el consumo cuando ocurrieron, estarás reconstruyéndolos bajo un reloj de 12 horas, que es el peor momento para ponerse a buscar datos. Regístralo a la entrada, no a la salida.

Las suscripciones se reembolsan según un reloj que no controlas

Las suscripciones de renovación automática son donde la mayoría de las aplicaciones ganan su dinero, y la actualización de reembolsos de la WWDC24 por fin las dirigió por la misma ventana de pruebas que los consumibles. Desde la versión 2.11 de App Store Server Notifications, una solicitud de reembolso de una suscripción de renovación automática también dispara un CONSUMPTION_REQUEST. Así que los reembolsos de suscripciones que antes se decidían por completo sin ti ahora llegan con una ventana de 12 horas adjunta.

El truco está en cómo se mide el consumo. Para una suscripción de renovación automática, Apple no quiere que inventes un porcentaje de uso. Calcula el consumo a partir del tiempo transcurrido por sí misma, así que alguien a seis meses de un plan anual se lee como consumido a la mitad aproximadamente, sin importar lo que envíes. Tu palanca no es el porcentaje. Es un refundPreference honesto de GRANT_FULL, GRANT_PRORATED o DECLINE, respaldado por la señal de uso que realmente tengas. Envía la preferencia que las pruebas respaldan y deja que Apple la sopese.

Las suscripciones sin renovación se parecen más a un desbloqueo único

Una suscripción sin renovación es un término fijo que el cliente compra una vez, y se comporta más como un no consumible que como un plan de renovación automática a efectos de reembolso. Apple rara vez le dirige un CONSUMPTION_REQUEST, y no hay renovación automática que prorratear. Tu aplicación es responsable de rastrear el término y restaurarlo en los dispositivos del cliente, así que un reembolso significa terminar una ventana de acceso que gestionabas tú mismo, no una que Apple cronometraba por ti.

Los no consumibles son permanentes, lo que corta por ambos lados

Un no consumible es lo más limpio de vender y una trampa silenciosa en el reembolso. Se compra una vez, se liga a la cuenta de tienda del cliente para siempre, y la tienda puede restaurarlo a cualquier dispositivo cuando se pida. Esa permanencia es una ventaja hasta que llega un reembolso, porque ahora tienes que revocar un derecho que la cuenta todavía recuerda. Si tu lógica de revocación solo comprueba en el momento de la compra y nunca vuelve a verificar, un cliente reembolsado puede restaurar compras y volver directo a la función de pago.

Google Play añade aquí un filo duro que pilla a los desarrolladores nuevos. Si tu aplicación no confirma una compra en un plazo de 72 horas, Google la reembolsa automáticamente y revoca el derecho. Un no consumible que tu código de facturación olvidó confirmar no queda en el limbo. Se revierte, y el cliente pierde el acceso a algo que pagó, sin que él lo pidiera.

Quién puede siquiera emitir el reembolso cambia según la tienda y el tipo

Antes de planear cualquier respuesta a un reembolso, sabe quién tiene la pluma. En la App Store, solo Apple puede emitir un reembolso de una compra dentro de la aplicación, para cada tipo de producto. Tu código StoreKit no puede reembolsar una compra, y tu servicio de soporte tampoco. Puedes enviar datos de consumo para influir en la decisión de Apple sobre los dos tipos que abren una ventana, y ese es todo tu control directo.

Google Play es lo contrario. Puedes reembolsar tú mismo un producto de pago único o un pedido de suscripción desde la Play Console o las API de Voided Purchases y de reembolso, total o parcialmente. Esa libertad es también una responsabilidad: un reembolso que emitas sobre un consumible todavía tiene que revocar el artículo en tu propio backend, porque Google no sabe que tus monedas están gastadas. El tipo de producto que elegiste decide lo limpia que es esa revocación.

Lo que cada tipo de reembolso te cuesta de verdad

El precio reembolsado es la línea que todos vigilan y la parte más pequeña de la factura. Cuando cualquier tienda concede un reembolso, revierte su propia comisión junto con él, así que pierdes tus ingresos netos en lugar del precio íntegro de venta. Esa es la buena noticia, y ahí acaba. Lo que la tienda devuelve es la parte que se llevó. Lo que nunca devuelve es lo que ya gastaste para cumplir la venta, y ese número cambia mucho según el tipo de producto.

El consumible es el reembolso caro

Un consumible reembolsado es el que puede costar más que su precio. Digamos que un cliente compra 5,000 créditos que cada uno dispara una llamada de inferencia de pago, gasta 4,000 de ellos, y luego solicita un reembolso. La tienda devuelve el precio y su comisión, pero el cómputo, la factura de la API por token, las imágenes que generaste y cualquier pago a creadores que esos créditos financiaron están todos gastados. Un reembolso de un no consumible al menos devuelve un derecho a tu control. Un reembolso de un consumible devuelve una venta cuyo coste íntegro ya pagaste.

Un contracargo es la versión más pesada de la misma factura

Un reembolso y un contracargo son eventos distintos, y la brecha ahora tiene fecha. Cuando un cliente disputa el cargo con su banco en lugar de pedírselo a la tienda, un contracargo completado es definitivo por parte del banco. Para los pedidos de Google Play realizados a partir del 3 de agosto de 2026, un contracargo perdido factura al desarrollador el precio de compra menos la tarifa de servicio de Play, más la tarifa de contracargo del banco, un cargo fijo que fija la red de tarjetas. Google Play te dirige un contracargo para revisión a través de orders.reviewrefund con una ventana de 24 horas, el único flujo de Google que pide tus pruebas, y puede recaer sobre cualquier tipo de producto.

Cómo responder cuando el tipo decide las reglas

No puedes cambiar sobre qué tipo de producto recae un reembolso después de la venta, pero puedes dejar de tratar a los cuatro de la misma manera.

• Registra la entrega y el consumo de los consumibles en el momento en que ocurren. Ese registro es toda tu defensa en el único tipo que no puede restaurarse, y la ventana de 12 horas es demasiado corta para construirlo desde cero.
• Vuelve a verificar los derechos de los no consumibles tras un reembolso, no solo en la compra. Una llamada de restauración debe comprobar el estado actual, para que un cliente reembolsado no pueda volver a la función de pago.
• Responde a ambas ventanas de pruebas automáticamente. Una solicitud de consumo de 12 horas y una revisión de contracargo de 24 horas no pueden esperar a que alguien lea una bandeja de entrada, y no se extienden por zonas horarias.
• Juzga tu defensa de reembolsos solo por los dos tipos rebatibles. Un recuento creciente de reembolsos en tipos que nunca abrieron una ventana es una señal de producto o de precio, no un fallo de tus pruebas.

Nada de esto trata de ganarle a la tienda. Trata de ajustar tu respuesta al objeto que realmente se vendió. RefundHalt responde al CONSUMPTION_REQUEST del consumible y de la suscripción y a la revisión orders.reviewrefund de Google Play automáticamente, dentro de la ventana, con las pruebas de entrega y uso que registraste en el momento de la venta, y mantiene los reembolsos que ninguna ventana te dejó nunca rebatir en su propio libro, para que el número por el que te juzgas siga siendo honesto.