El manejo de reembolsos falla de formas silenciosas, así que prueba los reembolsos de compras dentro de la app en el sandbox antes de que lo haga un cliente real

Tu manejo de reembolsos es la única ruta de código que solo se ejecuta cuando el cliente ya se ha ido. Nada en tu QA normal la toca, porque para llegar a ella tienes que ser reembolsado de verdad. Así que se lanza sin probar, permanece en silencio durante meses y luego falla en un reembolso real, donde el fallo cuesta dinero en lugar de una prueba en rojo. La solución es dejar de tratar un reembolso como algo que te ocurre y empezar a disparar uno a propósito. Tanto Apple como Google te permiten disparar un reembolso en un entorno de prueba y observar cómo reacciona tu servidor. Aquí te explicamos cómo probar los reembolsos de compras dentro de la app en la App Store y Google Play antes de que un cliente que paga demuestre que tu manejador estaba roto.

Los tres entornos en los que puede dispararse un reembolso, y solo uno es producción

Hay tres lugares separados donde puede dispararse un reembolso de Apple o Google mientras desarrollas, y no son intercambiables. Dos de ellos son tuyos para disparar cuando quieras. El tercero es producción, donde nunca quieres encontrarte por primera vez con un error de reembolso. La trampa es suponer que el fácil, las pruebas locales en Xcode, demuestra toda tu tubería. Demuestra tu app. No dice nada sobre tu servidor.

Las pruebas de StoreKit en Xcode son locales, así que ejercitan tu app y nada más

Las pruebas de StoreKit integradas en Xcode se ejecutan contra un archivo de configuración en tu Mac, sin ida y vuelta a Apple. Abre el StoreKit Transaction Manager desde la barra de depuración, selecciona una transacción comprada y haz clic en la flecha curva de reembolso. La transacción cambia a reembolsada y el listener Transaction.updates de tu app se dispara, exactamente como lo haría en el mundo real. También puedes llamar a beginRefundRequest para presentar la hoja de reembolso real, y en el entorno de Xcode el problema que elijas se corresponde uno a uno con un RevocationReason, con el reembolso aplicado de inmediato. Esta es la forma más rápida de demostrar que tu cliente corta el acceso en el momento en que revocationDate deja de ser nulo. Es también todo lo que las pruebas locales pueden decirte, porque nada aquí llega nunca a los servidores de Apple, así que no se envía ninguna App Store Server Notification. Tu backend no se entera de nada.

El sandbox es donde tu servidor por fin se entera de un reembolso

Para probar la mitad de tu integración que decide el dinero, tu servidor, necesitas el sandbox de Apple. Configura una URL de App Store Server Notifications V2 de sandbox en App Store Connect, inicia sesión con un tester de sandbox en un dispositivo y compra. Ahora un reembolso en el sandbox entrega una notificación REFUND real a tu backend, y una solicitud de reembolso sobre un consumible o un renovable automáticamente entrega un CONSUMPTION_REQUEST, el mismo payload firmado que recibirá tu servidor de producción. Antes de disparar nada, llama al endpoint Request a Test Notification. Le indica al servidor de la App Store que envíe una notificación de tipo TEST a la URL que configuraste y te entrega un testNotificationToken, que pasas a Get Test Notification Status para confirmar la entrega. Si esa ida y vuelta no funciona, tampoco funcionará ninguna notificación real.

Cómo probar los reembolsos de compras dentro de la app en la App Store

Ejecútalo en este orden, desde la comprobación barata del cliente hasta la ida y vuelta completa del servidor. Cada paso ejercita una pieza diferente, y los posteriores son los que producción de verdad te factura.

• Crea una clave de In-App Purchase en Users and Access, Integrations, In-App Purchase en App Store Connect, y úsala para firmar tus llamadas a la App Store Server API.
• Apunta tu URL de App Store Server Notifications V2 de sandbox a tu backend, luego llama a Request a Test Notification y confirma que el payload TEST llega y se verifica contra la cadena de certificados de Apple.
• En el Transaction Manager de Xcode, reembolsa una compra y confirma que tu app retira el derecho en el instante en que se establece revocationDate.
• Inicia sesión con un tester de sandbox, compra un consumible, solicita un reembolso y confirma que tu servidor recibe el CONSUMPTION_REQUEST y puede ensamblar y enviar una respuesta Send Consumption Information bien dentro de la ventana de 12 horas.
• Reembolsa una compra de sandbox y confirma que la notificación REFUND llega a tu servidor, que revocas el acceso o descuentas el saldo del consumible, y que una entrega repetida de la misma notificación no se aplica dos veces.

Cómo ensayar un reembolso y un chargeback en Google Play

Google Play no tiene un modo local como el de Xcode. Todo se ejecuta contra los servidores de Google, pero los license testers lo mantienen gratis y seguro. Añade tus cuentas de Google de prueba como license testers en Play Console y obtienen un conjunto de métodos de pago de prueba que nunca cobran dinero real. Google marca cada compra de prueba con un aviso en el centro del diálogo de compra, y no se calculan impuestos. Lo que importa para probar reembolsos es qué instrumento de prueba eliges, porque cada uno produce un resultado diferente.

Dispara un reembolso, un chargeback y el reembolso automático por falta de confirmación

• Compra con la tarjeta de prueba approve-then-charge-back, y una PendingRefundReviewNotification llega a tu topic de Real-time Developer Notifications momentos después. Respóndela con una única llamada orders.reviewrefund, porque Google solo conserva tu primera respuesta.
• Reembolsa y revoca un pedido de prueba desde la pestaña Orders en Play Console para disparar una VoidedPurchaseNotification, y confirma que tu servidor retira el derecho.
• Deja a propósito sin confirmar la compra de un license tester. Google la reembolsa automáticamente después de 3 minutos en lugar de los 3 días que permite producción, y te envía por correo la cancelación, así que una ruta de confirmación rota aparece en minutos, no en el cuarto día en producción.

Lo que realmente cuesta una ruta de reembolso sin probar

Un manejador de reembolsos no es decoración. Es el código que evita que pagues por servir a alguien que ya no te paga. Cuando falla en silencio, el reembolso igual se procesa, pero el acceso, el saldo y el gasto detrás de ellos no se detienen.

Sigue el dinero. Cuando Apple o Google reembolsa una compra, tú devuelves el precio de venta y la tienda devuelve su comisión, hasta aquí el balance queda parejo. Lo que no vuelve es todo lo que ya gastaste entregando el producto: el cómputo detrás de un resultado generado, las llamadas a la API del modelo, el almacenamiento de lo que el usuario guardó, el pago que ya enviaste a un creador. Un manejador de reembolsos que nunca revoca el acceso deja que un usuario reembolsado siga gastando eso con cargo a tu presupuesto, sin nada en el sistema que lo detenga.

Las dos ventanas de evidencia lo agudizan. Un CONSUMPTION_REQUEST que nunca ejercitaste en el sandbox es una respuesta que envías mal formada o tarde, y Apple a menudo concede el reembolso por defecto cuando tu respuesta no llega dentro de las 12 horas. Una respuesta a un chargeback de Google Play que nunca disparaste con la tarjeta de prueba es una ventana de 24 horas que fallas en vivo, y a partir del 3 de agosto de 2026 un chargeback perdido en Play te cuesta el precio de la compra menos la tarifa de servicio de Play más la tarifa de chargeback del banco. Cada uno de esos fallos es reproducible gratis en un entorno de prueba primero. Ninguno es barato en producción.

Una lista breve antes de lanzar el manejo de reembolsos

No necesitas un laboratorio. Necesitas haber visto cada evento llegar a tu código una vez.

• Tu app retira el acceso en el momento en que una transacción de StoreKit muestra un revocationDate, confirmado en el Transaction Manager de Xcode.
• La URL de tu servidor de sandbox recibe una notificación TEST y la verifica contra los certificados de Apple.
• Un REFUND de sandbox revoca el acceso o descuenta el saldo, y una entrega repetida no cuenta dos veces.
• Un CONSUMPTION_REQUEST de sandbox produce una respuesta Send Consumption Information válida bien dentro de las 12 horas.
• Una PendingRefundReviewNotification de Google desde la tarjeta de prueba de chargeback produce exactamente una llamada orders.reviewrefund.
• Una compra de prueba de Google Play sin confirmar se reembolsa automáticamente en 3 minutos y tu conciliación lo detecta.

Ejecuta esa lista una vez y el manejo de reembolsos deja de ser el código que esperas que funcione. Se convierte en el código que has visto funcionar.