Si transfieres una app a otra cuenta de desarrollador, los pedidos anteriores a la venta se quedan con el vendedor, y esto es lo que significa para los reembolsos

La página de ayuda de Google lo dice en una línea: los pedidos creados antes de transferir una app permanecen en la cuenta original. Así que, cuando transfieres una app a otra cuenta de desarrollador, los suscriptores pasan al comprador, pero el historial de compras no. Los reembolsos, las disputas y los tickets de soporte ligados a ese historial no se resuelven solos. Recaen en quien señalen las reglas de la tienda, que no siempre es la parte que cobró. Apple y Google lo gestionan de forma distinta, y Apple dice menos que Google. Esto es lo que documenta cada tienda, qué partes de tu sistema de reembolsos dejan de funcionar sin avisar tras una transferencia y qué poner por escrito antes de que cualquiera de las dos partes firme.

Qué se mueve y qué se queda cuando transfieres una app

Ambas tiendas tratan una transferencia como un cambio de propietario de ahí en adelante. La app, sus usuarios y sus valoraciones se mueven. El registro financiero del pasado, en su mayoría, no.

En el App Store

La regla de Apple trata sobre los datos. El desarrollador que transfiere conserva el acceso a la información de pagos y ventas anterior a la transferencia y pierde el acceso a todo lo posterior. El destinatario solo recibe la información de pagos y ventas de las transacciones que ocurren después de la transferencia. La guía de transferencia de Apple no aborda los reembolsos de compras hechas antes de la transferencia. No dice nada sobre de qué ingresos sale un reembolso tardío.

En Google Play

Google es más explícito. Los usuarios, las estadísticas, los datos, los comentarios, las valoraciones y las suscripciones se transfieren. Los pedidos creados antes de la transferencia se quedan en la cuenta original, y si alguno necesita un reembolso, Google indica que tienes que volver a la cuenta original o usar la Google Play Developer API. La cuenta del vendedor no deja de importar el día de la venta. Sigue siendo el único lugar desde el que se pueden emitir algunos reembolsos.

Quién emite un reembolso tras transferir una app

En ambas tiendas, la mayoría de los reembolsos se deciden sin intervención del desarrollador. Apple gestiona las solicitudes de reembolso por su cuenta. En Google Play, los compradores pueden reembolsar ellos mismos muchas compras en un plazo de 48 horas, y el soporte de Google concede otros. Una transferencia no cambia nada de eso. Lo que cambia es quién puede ver el reembolso y quién puede actuar en los pocos flujos que piden algo al desarrollador.

Un reembolso que quieres conceder en Google Play

Imagina que un suscriptor de toda la vida escribe al nuevo propietario pidiendo que le devuelvan un cargo de dos meses antes de la venta. El nuevo propietario no puede reembolsarlo desde su propia Play Console, porque el pedido no está ahí. El vendedor tiene que iniciar sesión y hacerlo, o alguien con acceso a la API de la cuenta del vendedor tiene que llamar a la Google Play Developer API. Si el vendedor ha cerrado la cuenta o ha dejado de responder, ese reembolso queda bloqueado. Google incluso ofrece devolver al vendedor la tarifa de registro de $25 si cierra la cuenta original tras una transferencia, y justo por eso el comprador debería asegurarse de que los reembolsos anteriores a la transferencia estén resueltos antes de que eso ocurra.

Un reembolso que Apple concede por su cuenta

En el App Store no eres tú quien emite los reembolsos, es Apple. Cuando Apple reembolsa una compra anterior a la transferencia, el registro de pago y venta está en manos del desarrollador original. La documentación de transferencias de Apple no dice de qué ingresos sale ese reembolso, así que ninguna de las partes debería darlo por supuesto. Ponlo en el acuerdo.

Los dos flujos de reembolso que piden pruebas

Solo dos flujos de reembolso piden algo al desarrollador. Apple envía un CONSUMPTION_REQUEST y te da 12 horas para responder con datos de consumo mediante Send Consumption Information. Google Play envía una revisión de contracargo, y tienes 24 horas para responder mediante orders.reviewrefund. Ambas respuestas se firman con credenciales que pertenecen a una cuenta, no a la app. Ahí es donde las transferencias se rompen.

El circuito de reembolsos que se rompe durante una transferencia

Una app transferida puede seguir vendiendo durante semanas sin que nadie note que la parte de reembolsos se ha quedado a oscuras.

La URL de notificaciones y la clave de In-App Purchase de Apple

La URL de App Store Server Notifications se configura por app, en App information dentro de App Store Connect. La guía de transferencia de Apple no la menciona, así que el nuevo propietario debería abrir esa pantalla el primer día y apuntar producción y sandbox a su propio servidor. Si sigue indicando el endpoint del vendedor, cada CONSUMPTION_REQUEST de la app llega a un servidor que el comprador no gestiona, y las 12 horas pasan en silencio.

Las respuestas pasan por la App Store Server API, que necesita una clave de In-App Purchase. Esas claves las genera en Users and Access un Account Holder o un Admin, y Apple solo te deja descargar cada una una vez. La clave del vendedor vive en la cuenta del vendedor. El comprador debería generar la suya, y el vendedor debería revocar la suya en cuanto termine el traspaso.

El secreto compartido y los webhooks de Apple

Para las apps con suscripciones de renovación automática, Apple pide al vendedor que genere un secreto compartido específico de la app antes de la transferencia y lo comparta con el destinatario, que lo usa para verificar las suscripciones. Una vez completada la transferencia, el destinatario debería generar uno nuevo para que nadie ajeno a su organización lo tenga. Los webhooks de App Store Connect también pasan al destinatario, y Apple sugiere que el vendedor los elimine antes si no quiere que después sigan llegando eventos a su servidor.

Los permisos y el proyecto de Cloud de Google

Google indica que los permisos y la configuración de vinculación de los servicios integrados no se transfieren. Pide al vendedor que añada la cuenta de destino como Owner de cualquier proyecto de Google Developers Console que use la app. En Play, ahí es donde suelen vivir tu tema de notificaciones para desarrolladores en tiempo real y la cuenta de servicio detrás de tus llamadas a la Developer API. Si la cuenta de servicio no tiene acceso en la Play Console del comprador, las comprobaciones de compras anuladas fallan y no se puede enviar una respuesta de orders.reviewrefund dentro de sus 24 horas.

Lo que cuesta una transferencia en reembolsos y contracargos

La mecánica anterior se convierte en dinero en tres puntos.

Das servicio a usuarios que pagaron al vendedor

Piensa en un suscriptor que compró un plan anual de $59,99 un mes antes de la venta. En Google Play, ese pedido está en la cuenta del vendedor. En el App Store, su registro de pago se queda con el vendedor. El comprador no recibe ningún pago por él y aun así asume el cómputo, las llamadas a APIs de terceros y el almacenamiento que ese suscriptor usa el resto del año. Si ese suscriptor pide más tarde un reembolso al comprador, el comprador no puede emitirlo en Google Play sin el vendedor. Cuenta esas suscripciones prepagadas al firmar, porque son un coste que el comprador asume sin ingresos asociados.

Contracargos de pedidos que el comprador nunca vendió

Para los pedidos de Google Play hechos después del 3 de agosto de 2026, el desarrollador responde del precio de compra del contracargo, menos la comisión de servicio de Play, más la comisión de contracargo del banco. Un contracargo es firme para el banco una vez decidido. La página de transferencias de Google no dice cómo se gestiona ese coste en un pedido que se quedó en la cuenta del vendedor. Hasta que Google lo aclare, un contrato de venta debería indicar quién paga un contracargo de un pedido anterior a la transferencia y quién responde a su revisión de contracargo.

El tramo del 15% cuenta dos veces los mismos ingresos

La comisión de servicio del 15% de Google Play se aplica al primer $1 millón de ingresos de un desarrollador cada año. Cuando una app pasa entre cuentas de desarrollador de Account Groups distintos, todos los ingresos de la app de ese año natural se incluyen en el total de ambos grupos. El propio ejemplo de Google es una app que ingresó $100.000 en el Account Group A y pasa al Account Group B. Esos $100.000 cuentan para el primer $1 millón de ambos grupos. Un comprador cerca del umbral puede llegar a la tarifa estándar antes de lo que sugieren sus propias ventas.

Qué dejar resuelto antes de transferir una app

Para el vendedor

• Descarga los informes que vayas a necesitar. La exportación masiva, las ventas estimadas y los informes de ingresos de Google no se transfieren, y el destinatario de Apple no verá tu historial.
• Mantén la cuenta original abierta y localizable hasta que los reembolsos y las disputas anteriores a la transferencia hayan seguido su curso.
• Genera y comparte el secreto compartido específico de la app antes de una transferencia en el App Store, y después revoca tu clave de In-App Purchase y elimina los webhooks que no quieras que sigan disparándose.

Para el comprador

• Configura tu propia URL de App Store Server Notifications y genera tu propia clave de In-App Purchase el primer día.
• Da acceso a tu cuenta de servicio en tu Play Console y confirma que las notificaciones para desarrolladores en tiempo real llegan a tu endpoint.
• Pide una lista de suscripciones prepagadas y compras grandes recientes, para saber a quién vas a dar servicio sin ingresos.
• Incluye en el acuerdo de venta los reembolsos, los contracargos y las revisiones de contracargo anteriores a la transferencia, con un contacto designado por parte del vendedor.

RefundHalt se conecta a cada app con credenciales de la cuenta propietaria. Tras una transferencia, conecta la app desde la cuenta del nuevo propietario, y a partir de ese momento las solicitudes de consumo y las revisiones de contracargo llegarán al nuevo propietario.