Un cliente mío descubrió la fuga por accidente. Su propia base de datos marcaba $11,400 de ingresos en febrero. El informe financiero de App Store Connect decía $10,650. Nada se había caído. Ninguna alerta se había disparado. Unos $750 simplemente se habían ido por la puerta, un reembolso a la vez, y se enteró unas cinco semanas después.
Apple decide cada reembolso de App Store. Tú no tienes voz en esa decisión. Lo que sí tienes es una ventana muy estrecha para presentarles evidencia, y solo se abre si tu servidor está realmente escuchando. La mayoría de los artículos sobre reembolsos de Apple App Store para desarrolladores pasan por encima de ese detalle, lo cual es una lástima, porque es la única parte que controlas. La ventana tiene su propio análisis aquí: Cómo el CONSUMPTION_REQUEST de Apple decide tu reembolso.
Puntos clave
Apple decide. No puedes emitir un reembolso, bloquearlo ni siquiera ver el nombre del cliente.
Tu única intervención es responder a un CONSUMPTION_REQUEST, y tiene que llegar dentro de unas 12 horas.
La pérdida de ingresos por reembolsos en App Store se acumula en capas. El reembolso en sí es solo la primera.
RevenueCat ubica la tasa media de reembolso de suscripciones entre 3% y 5%. Los casos extremos llegan al 9% o 18%.
La solución aburrida también es la barata: escucha las notificaciones, respóndelas automáticamente y corta el acceso cuando el dinero se devuelve.
Cómo se ve un reembolso de App Store desde tu lado
Alguien abre reportaproblem.apple.com, inicia sesión, elige una compra de los últimos 90 días, selecciona un motivo y envía la solicitud. Apple la lee. Apple la resuelve.
No te enteras de nada a menos que hayas pedido enterarte. No hay un botón de reembolso en App Store Connect, ni una fila de solicitudes pendientes, ni un correo del cliente al que puedas responder. Si tienes activadas las App Store Server Notifications V2, un CONSUMPTION_REQUEST llega a tu endpoint en el momento en que se presenta la solicitud, con la transacción, el producto y el motivo que eligió el cliente. A partir de ahí tienes unas 12 horas para llamar al endpoint Send Consumption Information con cinco campos: si dio su consentimiento, si la compra se entregó, si hubo una muestra, cuánto la usó y qué resultado quieres.
Responde con datos reales de uso y los reclamos débiles se rechazan con bastante frecuencia. No respondas nada y Apple se queda con la versión del cliente más lo que sugiera su historial de cuenta. Aquí el silencio también cuenta como respuesta, y es la que da la mayoría de los equipos.
Cuando un reembolso se aprueba, recibes una notificación REFUND con una fecha de revocación adjunta. Esa es tu señal para desactivar el acceso del usuario. Lo que nos lleva a la parte cara.
Cómo los reembolsos de App Store generan pérdida de ingresos
No es un número. Son cuatro, y tres de ellos nunca aparecen en un informe de reembolsos.
El reembolso. El precio se descuenta de tu próximo pago. El Paid Applications Agreement de Apple sí dice que Apple puede quedarse con su comisión en una venta reembolsada, y esa cláusula ha asustado a mucha gente durante años. Los desarrolladores que realmente han revisado sus informes de pagos dicen que Apple descuenta la parte posterior a la comisión, no el precio completo. Pierdes tu parte. Normalmente no la de ellos.
El acceso que nadie corta. Que el dinero salga y que las suscripciones terminen son dos eventos separados del lado de Apple, y solo uno ocurre por sí solo. Si te pierdes esa notificación REFUND, el usuario conserva sus funciones Pro. Gratis. He visto casos que duraron cuatro meses antes de que alguien lo notara, en un plan anual de $59.99. Repasamos todo el lío en cómo retirar el acceso después de un reembolso.
Tus reportes. Los reembolsos aparecen semanas después de la compra, a veces pasado un periodo de facturación. Si cuentas los ingresos en la semana en que se ganaron y nunca restas lo que se reembolsó después, tu LTV queda inflado sin que te des cuenta. Luego compras tráfico a un CAC que no puedes pagar y te preguntas por qué la cohorte nunca se recupera.
La inversión publicitaria. Pagaste por conseguir a ese usuario. Pidió el reembolso igual. Ese dinero se fue y nada en tu dashboard se mueve para avisarte.
Cómo se ve una tasa de reembolso normal
Los benchmarks sirven para una sola cosa: saber si tienes un problema real o solo uno normal. El State of Subscription Apps de RevenueCat cubre más de 75,000 apps y ubica la tasa media de reembolso alrededor del 3% al 5% de las suscripciones pagadas en su primer periodo de facturación. Los casos extremos llegan al 9% o 18%.
El nivel de precio es el corte interesante. Los planes de precio bajo rondan una mediana de 2.7%, los de precio alto cerca del 4.5%. Más o menos un punto por cada escalón que subes. Los planes anuales también se reembolsan más que los semanales, lo cual tiene sentido. Un cargo de $79 genera expectativas que uno de $4.99 no genera.
Así calculo el número para un cliente nuevo:
Extrae las transacciones reembolsadas de los últimos 90 días del historial de reembolsos.
Asigna cada una al mes en que ocurrió la compra original, no al mes en que se reembolsó.
Divide entre las transacciones pagadas de ese mismo mes.
Separa por producto. Un paywall malo siempre se esconde dentro de un promedio sano.
Menos del 2% está bien. Entre 2% y 5% es normal. Por encima del 5%, empieza a investigar. Por encima del 10%, deja de culpar a tu marketing y lee en voz alta el texto de tu paywall.
Prevención de reembolsos en App Store: cómo reducirlos
No hay un único interruptor. Es un montón de decisiones pequeñas, y algunas importan mucho más que otras.
Responde cada CONSUMPTION_REQUEST. Es la palanca más grande y la que casi todos se saltan. ¿Alguien consumió el 90% de un desbloqueo de por vida y luego afirmó que nunca funcionó? Recházalo y muestra el uso. ¿Un padre cuyo hijo compró un paquete de $29.99 por accidente? Deja pasar ese. Ambas decisiones necesitan una respuesta registrada.
Entrega algo en la primera sesión. Los reembolsos se concentran al inicio. Si un usuario nuevo no logra un resultado real antes de llegar al paywall, le vendiste una promesa.
Di la renovación en voz alta. Precio, periodo, fecha de renovación, en la misma pantalla que el botón de compra. La mayoría de los motivos de reembolso se reducen a sorpresa, y la sorpresa es una decisión de diseño.
Lanza una prueba o una muestra. El formulario de consumo de Apple pregunta literalmente si existió una. Decir que sí ayuda a tu caso y les da a los usuarios indecisos una entrada más barata.
Dale una puerta al soporte. Un enlace de contacto visible más un refund request sheet dentro de la app envía a la gente molesta hacia ti antes de que vaya a Apple. Esa hoja existe desde iOS 15. No puede otorgar un reembolso, solo iniciar la solicitud.
Corta el acceso cuando el dinero se devuelve. Maneja REFUND y REFUND_REVERSED, y devuelve el acceso en una reversión para que los clientes honestos no paguen por un cambio de opinión de Apple.
Vigila a los reincidentes. El endpoint Get Refund History de Apple lista cada transacción reembolsada vinculada a un usuario. Revísalo antes de darle a la misma cuenta una segunda prueba o un descuento.
El problema de las 12 horas
Las notificaciones llegan a las 3 a.m. de un sábado. Responder una correctamente implica validar la cadena de firma JWS de Apple contra sus certificados raíz, cruzar la transacción con una persona real en tu propia base de datos, calcular un porcentaje de consumo en milésimas, generar un JWT de vida corta con una clave de In-App Purchase y enviarlo. Antes de que se acabe el tiempo. Cada vez.
El sandbox te da 5 minutos en lugar de 12 horas, lo que se lee como una pista bastante directa sobre lo que Apple espera de ti. Un servidor. No una persona con una laptop.
Los equipos que prefieren no construir ese pipeline usan Refund Sensor. Funciona con las claves de tienda que ya tienes, responde cada solicitud con evidencia de la transacción bastante antes del límite y lleva la cuenta corriente de lo que lograste conservar. Unos cinco minutos para configurarlo, sin SDK, sin cambios de código, sin volver a enviar la app.
¿Prefieres comparar opciones? Cómo elegir software de gestión de reembolsos de Apple para desarrolladores explica qué comparar.
Fuentes
Preguntas frecuentes
No. Apple es dueño de la relación de cobro, así que solo Apple puede devolver el dinero. Tus dos opciones son responder a una solicitud de reembolso con evidencia, o entregarle tú mismo al cliente el formulario de reembolso de Apple a través del refund request sheet de StoreKit.
A los clientes se les dice que tendrán respuesta dentro de 48 horas. Tu propia ventana es mucho más ajustada: unas 12 horas desde el CONSUMPTION_REQUEST.
El acuerdo dice que tiene derecho a hacerlo. En la práctica, los desarrolladores que han revisado sus informes de pagos en App Store Connect ven que se descuenta la parte posterior a la comisión, así que pierdes lo que ganaste y no el precio completo.
Nada, a menos que tú lo hagas. Apple envía una notificación REFUND con una fecha de revocación, y tu servidor tiene que terminar la suscripción. Si se te pasa, ese usuario se queda con Pro gratis.
Entre 2% y 5% de las transacciones pagadas en apps de suscripción, según los datos de RevenueCat de más de 75,000 apps. Salud, fitness y educación están más arriba. Si pasas del 10%, revisa los precios y el texto del paywall antes que cualquier otra cosa.
Sí, cuando Apple revierte el reembolso. Recibirás una notificación REFUND_REVERSED y deberías devolver todo lo que le quitaste.
Normalmente sí. Un consumible de $2.99 no vale diez minutos del día de una persona. Sí vale dos segundos de tiempo de servidor, y en una app de alto volumen esos montos pequeños se suman rápido.
