Los reembolsos de compras dentro de la aplicación consumibles son los que te cuestan dos veces, porque ya gastaste el dinero en entregarlas

Todo reembolso duele, pero el reembolso de una compra consumible dentro de la aplicación es el que te quita el dinero después de que ya lo gastaste. El reembolso de una suscripción revierte un acceso que puedes desactivar. El reembolso de un no consumible recupera un desbloqueo permanente. Un consumible es distinto. Un paquete de monedas, un lote de gemas, un paquete de créditos de imágenes de IA, un impulso, se canjea en el momento en que llega al saldo del cliente, y para cuando aparece la solicitud de reembolso las monedas ya no están, los créditos se han quemado y el cómputo que produjo el resultado ya se te ha facturado. Esto es lo que hace de los consumibles el problema de reembolsos más agudo de una aplicación, y por qué el consejo habitual de demostrar el valor no te salva aquí.

En qué se diferencia el reembolso de un consumible de cualquier otro reembolso

La tienda trata cada tipo de compra como una de tres cosas, y los reembolsos caen de forma distinta en cada una. La diferencia no es académica. Decide cuánto de tu costo vuelve.

Un consumible se gasta en el momento en que lo entregas

Un no consumible, un desbloqueo de nivel permanente o la eliminación de anuncios, permanece en la cuenta. Una suscripción concede un acceso limitado en el tiempo que puedes revocar. Un consumible se agota al canjearlo. El cliente compra 1,000 monedas, gasta 600 en una función que llamó a tus servidores, y esas 600 ya no están. El valor no quedó en reserva esperando a ser juzgado. Se convirtió en tus costos pagados en el acto.

Por eso las tiendas crearon en primer lugar un flujo de evidencia de reembolso separado para los consumibles. Para una suscripción, la tienda puede razonar sobre cuánto del periodo pagado transcurrió. Para un consumible no hay reloj que leer. O bien entregaste las monedas y el cliente las usó, o no lo hiciste, y solo tu servidor sabe cuál de las dos.

No puedes deshacer la entrega de lo que ya se ha consumido

Cuando se concede un reembolso sobre un consumible, el dinero se revierte pero las monedas no se descanjean solas. Si un cliente compró un paquete de créditos, generó cuarenta imágenes con él y luego obtuvo un reembolso, pagaste cuarenta generaciones y no recibiste nada a cambio. Revocar el saldo restante es lo máximo que puedes hacer, y solo si queda algo. Un consumible totalmente consumido no deja nada que recuperar.

Cuánto te cuesta realmente el reembolso de una compra consumible dentro de la aplicación

La cifra principal de un reembolso de un consumible es el precio de venta que sale de tus libros. La cifra real es el precio de venta más todo lo que ya gastaste convirtiendo esa compra en valor entregado. La mayor parte de esa segunda parte nunca vuelve.

El reembolso revierte el precio, no el cómputo

Supón que un cliente compra un paquete de créditos de IA de $9.99 y los gasta todos generando resultados. Cada generación te costó una llamada real a una API. Cuando Apple concede el reembolso, los $9.99 se devuelven y Apple revierte su comisión, así que tus ingresos declarados quedan en cero. Tu factura de cómputo por esas generaciones no queda en cero. La pagaste, se cobró y sigue pagada. El reembolso no la tocó. Este es el caso exacto para el que se construyó RefundHalt, porque el tiempo transcurrido no prueba nada sobre un consumible y la única defensa es saber qué se entregó realmente.

El lado de la App Store, la única ventana de 12 horas en la que cuenta tu respuesta

En la App Store no tienes un interruptor de reembolso. No puedes conceder el reembolso de un consumible y no puedes denegarlo. Apple decide cada reembolso, una solicitud a la vez, a través de reportaproblem.apple.com. Lo que obtienes en cambio es una única oportunidad de hablar, y es estrecha.

El CONSUMPTION_REQUEST es el único lugar donde Apple te pregunta algo

Cuando un cliente solicita un reembolso sobre un consumible, y el uso compartido de datos de consumo está habilitado para la aplicación, tu servidor recibe una App Store Server Notification de tipo CONSUMPTION_REQUEST. Entonces tienes 12 horas para responder con Send Consumption Information. Si pierdes la ventana, la decisión se toma sin tu aportación. Apple introdujo este flujo específicamente para consumibles, y en 2024 extendió la misma notificación a las suscripciones de renovación automática.

La respuesta lleva un conjunto de campos. Los dos que más importan para un consumible describen cuánto se usó y si lo entregaste siquiera.

Por qué tu respuesta importa más en un consumible que en una suscripción

Para una suscripción de renovación automática, Apple ya calcula cuánto del periodo de facturación transcurrió y se apoya en eso. Tu respuesta de consumo en su mayoría solo empuja una preferencia. Para un consumible no hay periodo transcurrido que medir. El consumptionStatus que envías es casi la única señal de uso que tiene Apple. Si tu servidor puede afirmar, con certeza, que el cliente consumió el 100 por ciento del paquete, esa es la diferencia entre una transacción defendible y una entrega gratuita silenciosa. Si customerConsented es false, nada de esto se lee, así que el consentimiento debe capturarse en tu flujo de compra mucho antes de que llegue la solicitud.

El lado de Google Play, puedes reembolsar pero el artículo ya no está

Google Play da al desarrollador más control directo que Apple, y ayuda menos de lo que pensarías, porque las vías de reembolso más rápidas nunca llegan a ti.

La ventana de autoservicio de 48 horas te salta por completo

Dentro de las 48 horas siguientes a la compra, un cliente de Google Play puede solicitar un reembolso a través de la tienda y a menudo obtenerlo automáticamente, sin tu intervención. No se te pregunta, no opinas, y para un consumible eso significa que las monedas ya están gastadas y el dinero se ha ido antes de que sepas que hubo una solicitud. La Voided Purchases API es la forma en que te enteras después del hecho, para que puedas revocar el derecho que quede.

Reembolsar y revocar, y lo que revocar no puede hacer

Puedes emitir el reembolso de un consumible tú mismo desde la Play Console o la Order Management API, con un parámetro de revocación opcional que retira el acceso. La revocación funciona limpiamente en cosas que persisten, una suscripción o un derecho duradero. No puede deshacer el gasto de un consumible. Si el cliente ya convirtió las monedas en un resultado entregado, la revocación no tiene nada que reclamar, y cargas con el costo de cumplimiento sin una venta que lo compense.

Qué significa en dinero cuando cambian las reglas de contracargos

Un reembolso y un contracargo no son la misma pérdida, y en un consumible la brecha está a punto de ampliarse. Un reembolso revierte la venta y normalmente devuelve la comisión de la tienda. Un contracargo es el banco del cliente forzando la devolución del dinero, y es definitivo.

A partir del 3 de agosto de 2026, Google Play traslada el costo de un contracargo al desarrollador: el precio de compra menos la tarifa de servicio de Play, más la comisión de contracargo del banco. En un consumible que ya entregaste, la aritmética es brutal. Pagaste el cómputo para cumplirlo, pierdes el precio de compra, y ahora pagas encima la comisión del banco. Un solo paquete de monedas en disputa puede costar más de lo que ganaron varios vendidos. La lección no es pelear los contracargos después del hecho, que rara vez ganas, sino mantener a los clientes descontentos en la vía del reembolso, donde la pérdida es menor y la parte de la tienda vuelve, en lugar de la vía de la disputa, donde no vuelve.

Cómo perder menos con los reembolsos de consumibles

No puedes impedir que las tiendas reembolsen. Puedes asegurarte de que, cuando lo hagan, hayas entregado con honestidad, respondido por completo, y puedas ver el patrón antes de que crezca.

Entrega del lado del servidor y regístralo

Concede los consumibles desde tu servidor después de verificar la transacción, y registra el momento de la entrega y del consumo contra el id de la transacción. Ese registro es lo que te permite responder a un CONSUMPTION_REQUEST con un consumptionStatus verdadero en lugar de una conjetura. Un consumible que entregaste pero que no puedes probar que entregaste es un reembolso que perderás por defecto.

Responde a cada CONSUMPTION_REQUEST, y respóndelo con franqueza

Responde dentro de las 12 horas, siempre. Reporta el consumptionStatus real. Exagerar el uso en un cliente que genuinamente no recibió sus monedas invita al contracargo que intentabas evitar, y el contracargo es el resultado más caro. Honesto, completo, a tiempo. Ese es todo el juego, y solo funciona si los datos ya están capturados antes de que llegue la solicitud.

Vigila los consumibles como su propia cohorte de reembolsos

Mezcla los reembolsos de consumibles en tu tasa de reembolsos general y la señal desaparece. Rastréalos por separado. Un pico de reembolsos en un paquete de monedas o un nivel de créditos suele apuntar a un problema específico, un canje roto, un precio engañoso, un paquete que entrega menos de lo que sugiere el icono. Lee los reembolsos de consumibles frente a las ventas de consumibles, por producto, y la causa suele ser obvia.

La versión corta

El reembolso de una compra consumible dentro de la aplicación es el reembolso que te cuesta antes incluso de que te enteres, porque las monedas se gastaron, los créditos se quemaron y el cómputo se facturó en el momento en que el cliente compró. Apple te deja hablar una vez, durante 12 horas, a través del CONSUMPTION_REQUEST, y en un consumible esa respuesta es casi la única evidencia que existe. Google Play te deja reembolsar pero rara vez pregunta primero, y a partir de agosto de 2026 un contracargo de un consumible cuesta más de lo que costó la venta. Entrega del lado del servidor, registra lo que entregaste, responde a cada solicitud con la verdad, y mantén la pérdida en el carril del reembolso en lugar del carril de la disputa.