La mayoría de las guías sobre cómo manejar las solicitudes de reembolso comienzan en la notificación. Apple te avisa, Google te avisa, y aquí está lo que debes responder. Tiene sentido, pero cuando llega el aviso, el trabajo útil ya está hecho o ya se perdió, porque lo que puedes decir sobre una compra depende de lo que registraste cuando sucedió.
Por eso, esta publicación empieza antes, en el checkout. Qué datos de compra importan cuando llega una solicitud de reembolso, dónde guardarlos y cómo se convierten en una respuesta que la tienda realmente tomará en cuenta. Si nunca has vinculado un identificador a una compra, lee primero nuestra publicación sobre appAccountToken y la defensa ante reembolsos, porque todo lo que sigue asume que puedes conectar un ID de transacción con una persona.
Puntos clave
Tanto Apple como Google deciden los reembolsos por sí mismos, y ambos ahora te piden datos de compra primero. Apple te da 12 horas; Google, 24.
Las tiendas quieren datos generales, no registros detallados. Si se entregó, cuánto se usó, si recibieron una muestra y cuál es tu preferencia.
Necesitas cuatro datos almacenados por cada compra: quién, cuándo se entregó, cuándo se usó y si ya le has reembolsado antes a esta cuenta.
Apple dice que la mayoría de las solicitudes de reembolso llegan dentro de los 30 días posteriores a la compra. Guarda los datos al menos ese tiempo; en la práctica, 90 días.
Las apps que empiezan a responder ven caer su tasa de reembolsos en alrededor de un tercio, pero solo si hay algo registrado que decir.
Qué te piden realmente las tiendas
La solicitud de Apple es pequeña. Cuando un cliente pide un reembolso por una compra dentro de la app, recibes un CONSUMPTION_REQUEST y respondes a través del endpoint Send Consumption Information con cinco campos. Si el cliente dio su consentimiento para que compartas datos, si la compra se entregó, qué porcentaje se consumió (en miliunidades, así que 100,000 equivale a la totalidad), si antes tuvo una muestra o prueba gratuita, y tu preferencia de reembolso. Antes Apple pedía una docena de campos y eliminó la mayoría, lo cual interpreto como que Apple decidió que ya conoce el historial del cliente mejor que tú.
La versión de Google es para contracargos y es un poco más detallada. Una notificación de revisión de reembolso pendiente llega a través de Real-time Developer Notifications con un token. Envías una solicitud POST a orders.reviewrefund con ese token, el mismo indicador de contenido de muestra, una preferencia de DECLINE, APPROVE o NEUTRAL, un porcentaje de consumo opcional, y hasta 1,000 eventos de uso con marcas de tiempo. Esto importa más ahora que Google cobra a los desarrolladores por los contracargos en pedidos posteriores al 3 de agosto de 2026.
Ninguna de las dos tiendas quiere tu exportación de analítica. Quieren entrega, consumo, muestreo y preferencia, y todo lo demás que almacenas existe para completar esos datos de forma veraz y rápida.
Historial de compras para reembolsos: qué conservar y por cuánto tiempo
Lo mínimo:
Un identificador en el checkout. appAccountToken en Apple, obfuscatedAccountId en Google. Sin él, una solicitud de reembolso menciona una transacción y no tienes idea de a quién pertenece. Los ingenieros de Apple también recomiendan guardar al menos un originalTransactionId por usuario, porque con cualquiera de ellos puedes llamar a Get Transaction History y obtener todo el historial de compras de ese cliente en tu app, tenga o no la app instalada todavía.
Un registro de entrega. Cuándo otorgaste las monedas o desbloqueaste el nivel, con una marca de tiempo y un resultado. Si la entrega falló, dilo. Ese es el único caso en el que deberías querer que se apruebe el reembolso, y afirmar lo contrario quema la credibilidad que necesitarás después.
Eventos de consumo. No cada toque, solo los que indican que la compra se usó: monedas gastadas, capítulo abierto, exportación ejecutada. Google acepta hasta mil de ellos. Apple solo quiere un porcentaje, pero no puedes calcular uno que nunca registraste.
Un indicador de muestra por producto. ¿Este cliente tuvo una prueba, una vista previa, un nivel gratuito? Un sí o un no en ambas tiendas, y la gente lo olvida constantemente.
Reembolsos previos en la cuenta. Apple de todas formas evalúa el historial de reembolsos por su cuenta, pero lo querrás para tus propias reglas.
En cuanto a la retención, Apple ha dicho que la mayoría de las solicitudes de reembolso llegan dentro de los 30 días y recomienda almacenar los datos de consumo en consecuencia. Nosotros conservamos 90 días, en parte porque los contracargos de Google pueden tardar más en llegar, y en parte porque el almacenamiento es barato y argumentar de memoria no lo es.
Cómo ayuda el historial de compras con los reembolsos
Una vez que eso está en marcha, la solicitud deja de ser una decisión subjetiva y se convierte en una consulta.
Entregado, consumido por completo, sin muestra, sin reembolsos previos: ese es el caso para DECLINE. Entregado, apenas usado, solicitado en menos de un día: GRANT_FULL cuesta poco y la alternativa se ve mezquina. La entrega falló de tu lado: apruébalo y corrige el error. Usado parcialmente durante varias semanas: Apple tiene GRANT_PRORATED para esto, y en Google el porcentaje de consumo cumple la misma función.
Los números lo respaldan. Dipsea, una app de audio por suscripción, empezó a responder las solicitudes de Apple a finales de 2024 y su tasa de reembolsos pasó de 3 % a 1.9 % en unas dos semanas. En cuanto a contracargos, Appcharge le dijo a PocketGamer que las disputas sin asistencia se ganan entre el 20 % y el 30 % de las veces, y las respaldadas con evidencia se ganan más del 80 %. En las más de 800 apps que usan Refund Sensor, se ha defendido el 77 % de las solicitudes elegibles, y las que perdemos en su mayoría no tenían nada registrado.
Lo que el historial de compras no hace es permitirte ganar argumentos que no deberías ganar. Si los datos del cliente indican que abrió la app una sola vez, la respuesta honesta es el reembolso.
Cómo procesar solicitudes de reembolso dentro del plazo
El proceso de solicitud de reembolso en ambas tiendas tiene un plazo fijo, así que esto es más infraestructura técnica que criterio. La notificación llega a un endpoint que has registrado. Verificas la firma, extraes el ID de transacción, consultas los registros de entrega y consumo del usuario, calculas el porcentaje, eliges la preferencia según una regla que escribiste de antemano y envías la respuesta. Registra qué enviaste y cuándo, y luego espera el resultado, que en Apple es una notificación REFUND o REFUND_DECLINED. Ante un REFUND, revoca el acceso en la misma hora, porque un cliente reembolsado que conserva el contenido suele volver a pedir más.
Dos cosas suelen causar problemas. El consentimiento: Apple no acepta el envío a menos que customerConsented sea true, así que el permiso para compartir datos de uso debe estar en tus términos antes de la primera solicitud. Y el tiempo: los relojes no se detienen los fines de semana, y una proporción sorprendente de solicitudes llega durante la madrugada. La gestión de solicitudes de reembolso consiste principalmente en asegurarte de que algo esté despierto. Nuestra guía sobre la gestión de solicitudes de reembolso de Apple profundiza más en el aspecto operativo.
Software de procesamiento de reembolsos para desarrolladores, o tu propio código
Con un equipo de backend, el flujo descrito arriba representa una semana de trabajo y después una responsabilidad continua, y esa responsabilidad es la parte costosa.
Si usas RevenueCat o Adapty, ambos responden las solicitudes de consumo de Apple a partir de los datos de uso que sus SDK ya recopilan, y Adapty también cubre la revisión de Google. Una opción razonable por defecto si de todos modos el SDK ya está en la app.
Refund Sensor hace lo mismo sin un SDK. Conectas una clave de API de App Store Connect y una URL de notificaciones, y la herramienta recibe las solicitudes, envía la respuesta dentro del plazo y mantiene una línea de tiempo por cada caso. La configuración toma unos minutos y el precio es fijo. Los detalles están en el sitio de Refund Sensor.
Elijas lo que elijas, incluso no elegir nada, la capa de datos es tuya. Ningún software de procesamiento de reembolsos para desarrolladores puede inventar un registro de entrega que no guardaste.
Conclusión
Se suele hablar de la defensa ante reembolsos como un problema de respuesta, pero en realidad es consecuencia de un problema de registro. Las tiendas hacen cuatro preguntas puntuales, y que puedas responderlas depende de decisiones que tomaste en el checkout y en la entrega, mucho antes de que alguien quisiera su dinero de vuelta.
Vincula un identificador, registra la entrega y el consumo con marcas de tiempo, marca las muestras y conserva todo durante 90 días. Con eso implementado, cómo procesar las solicitudes de reembolso se convierte en una regla y un cron job, y la tasa de reembolsos tiende a resolverse sola.
Preguntas frecuentes
Apple te da 12 horas a partir del CONSUMPTION_REQUEST. Google te da 24 horas a partir de la notificación de revisión de reembolso pendiente para un contracargo. Si no respondes a tiempo, ambas tiendas deciden sin ti.
Cinco campos: el consentimiento del cliente, el estado de la entrega, el porcentaje de consumo en miliunidades, si se proporcionó una muestra y tu preferencia de reembolso. Los campos antiguos, como la antigüedad de la cuenta y el gasto total histórico, ya no existen.
En su mayoría sí, más detalle adicional si lo tienes. Google acepta un porcentaje de consumo y hasta 1,000 eventos de uso con marca de tiempo, y sus opciones de preferencia son DECLINE, APPROVE o NEUTRAL.
En Apple, sí. El envío se rechaza a menos que customerConsented sea true, así que el permiso debe estar incluido en tus términos antes de que llegue la solicitud.
No. Ambas tiendas tratan tu preferencia como un dato más de entrada, y ambas ven el historial completo del cliente. Rechazar cuando tus propios datos muestran una entrega fallida o un uso casi nulo te cuesta credibilidad en los casos que sí importan.
