BillingMeld: por qué el servidor debe verificar la compra en lugar de la aplicación

La compra dentro de una aplicación móvil generalmente parece simple solo para el usuario. Hace clic en un botón, confirma el pago, obtiene acceso a una función o suscripción, y espera que todo funcione automáticamente a partir de ahí.

Para el desarrollador, detrás de ese botón comienza un proceso mucho más complejo. Es necesario confirmar la compra en sí misma, tener en cuenta las renovaciones, el final de la suscripción, devoluciones, revisiones de operaciones, cambios de dispositivo y las diferencias entre las tiendas Apple y Google.

El problema principal surge cuando el servidor comienza a considerar la aplicación cliente como la fuente de la verdad.

Si la app informa: «Compra realizada», el servidor otorga acceso y continúa basándose en ese estado obtenido en una sola ocasión. Pero el ciclo de vida de la compra no termina allí.

La suscripción puede ser renovada, la autoriyección puede estar desactivada, el pago puede ser reembolsado, y la operación puede ser retirada por la tienda.

Por eso, en BillingMeld, la compra la confirma no la aplicación, sino el servidor.

El cliente informa, pero no decide

En la arquitectura de BillingMeld, la aplicación móvil no es la principal fuente de información sobre la compra.

El cliente puede transmitir datos sobre la operación realizada, pero esto solo sirve como base para verificar. La decisión final la toma la parte del servidor de BillingMeld, que comprueba la información a través de la infraestructura de Apple o Google.

Esta es una diferencia fundamental.

La app en el teléfono puede trabajar con un estado antiguo, no recibir un cambio a tiempo o transmitir datos que ya no corresponden con el estado actual de la compra.

Además, el cliente no debe tener la capacidad de decidir por sí mismo si un usuario tiene acceso pago o no.

BillingMeld verifica, por ejemplo:

• si realmente existe esa compra;

• si corresponde a la app y producto necesarios;

• si el período pagado está vigente;

• si se realizó alguna renovación;

• si se desactivó la renovación automática;

• si se realizó un reembolso;

• si la operación fue retirada;

• si el período pagado aún no finalizó.

De esta forma, el mensaje del cliente deja de ser prueba de compra y pasa a ser una razón para verificar su estado real.

Una fuente única de verdad para los servidores

A los servicios conectados no les es necesario implementar toda la integración con Apple y Google simultáneamente.

Consultan a BillingMeld, que ya devuelve un estado normalizado de la compra.

Por ejemplo: acceso activo, período pagado finalizado, renovación confirmada, autoriyección desactivada, o compra retirada.

Esto permite una clara delimitación de responsabilidades.

Apple y Google son las fuentes del estado de la operación de la tienda. BillingMeld verifica estos datos, los normaliza a un modelo común y mantiene el estado actualizado. El producto final decide sobre el acceso solo en base al estado de BillingMeld.

Para los servidores de productos, esto significa un contrato único en lugar de múltiples integraciones independientes.

No es necesario implementar reglas específicas para App Store, y luego para Google Play, y después intentar unificar diferentes formatos, eventos y estados en una lógica común.

No se puede confiar completamente en el cliente

La aplicación en el cliente funciona en el dispositivo del usuario.

Puede ser cerrada, reiniciada, restaurada desde una copia de seguridad, actualizada posteriormente o instalada en otro dispositivo. Puede trabajar durante un tiempo con información antigua o no recibir un evento ocurrido después de la compra inicial.

Incluso sin intervención del usuario, esto hace que el cliente no sea una fuente confiable del estado final de la suscripción.

Por ejemplo, el usuario realiza una suscripción y obtiene acceso. Posteriormente, la compra puede haber sido reembolsada o la tienda puede haber retirado la operación.

Si el servidor solo conoce el mensaje inicial del cliente, seguirá considerando la compra como vigente.

En otra situación, el usuario puede haber desactivado la renovación automática. En ese caso, el período ya pagado debe seguir activo hasta su fin.

Si el sistema opera solo con un estado primitivo «suscripción activa/no activa», es fácil que cierre el acceso demasiado pronto o que lo quede abierto después de que el derecho haya finalizado.

BillingMeld está basado en otra lógica: el cliente no confirma sus derechos. Es él quien informa el evento, y el servidor determina el estado real de la compra.

Una compra no es un evento único

Uno de los errores principales en la arquitectura de la facturación es tratar la compra como un evento único.

En realidad, tiene un ciclo de vida.

Primero, aparece una operación. Luego, se confirma en la tienda. Para la suscripción, comienza el período pagado. Después, puede haber una renovación adicional.

El usuario puede desactivar la renovación automática, pero seguir usando la suscripción hasta el final del período pagado.

El pago puede no procesarse en una futura renovación.

Se puede realizar un reembolso.

En algunos casos, la compra puede ser retirada.

Por ello, el hecho de que «esta compra alguna vez existió» no es suficiente.

El servidor necesita saber qué pasa con ella en el presente.

La devolución de compra no pasa desapercibida

La necesidad de una arquitectura server-side se hace evidente especialmente en casos de reembolsos y cancelaciones.

La compra inicial puede ser perfectamente válida. El usuario pagó por el producto y obtuvo acceso.

Pero luego, el estado de la operación cambió.

Si BillingMeld recibe la información del cambio, actualiza su estado y, si es necesario, vuelve a verificar los datos en la tienda.

El servicio conectado trabaja ya con el nuevo estado.

De esta forma, la app deja de confiar únicamente en la confirmación de hace semanas o meses.

Si la tienda ya no considera vigente ese derecho, BillingMeld lo refleja en su estado.

Cancelar una suscripción y finalizar el acceso no son lo mismo

Aquí hay una diferencia importante.

Si el usuario desactivó la renovación automática, eso generalmente no significa que el acceso deba terminarse inmediatamente.

El período pagado puede seguir vigente.

En ese caso, BillingMeld debe guardar que la renovación se desactivó, pero también registrar la fecha de fin del período ya pagado.

Solo después de que acabe, el acceso deja de considerarse activo, si no hubo una nueva confirmación.

Este es uno de los motivos por los cuales un simple valor booleano subscription = true no es suficiente para una facturación correcta.

El estado de la suscripción siempre está vinculado al tiempo y a los eventos del ciclo de vida.

La renovación también requiere una verificación separada

La suscripción no termina con el primer pago.

El servidor debe entender si hubo una renovación adicional y si la siguiente período pagado está confirmado por la tienda.

BillingMeld monitorea estos cambios y actualiza el estado de la suscripción.

Si la renovación está confirmada, el derecho de acceso continúa.

Si no hay un nuevo cargo o la tienda ya no confirma el próximo período, el sistema no debe simplemente extender el acceso por sí mismo.

Desde el punto de vista del usuario, esto parece natural: el acceso dura tanto como dure la suscripción pagada.

Para los desarrolladores, esto significa que no tienen que reimplementar la misma lógica de renovación en cada app.

Un escenario típico

El usuario suscribe a través de una app móvil.

El cliente recibe la información de compra y transmite los datos necesarios a BillingMeld. Pero ese mensaje aún no confirma definitivamente la compra.

BillingMeld verifica la operación con la tienda correspondiente.

Si App Store o Google Play confirman la compra y su estado cumple con las reglas del producto, BillingMeld registra el derecho activo.

Luego, el servicio conectado proporciona el acceso pagado.

El estado continúa vigente independientemente del mensaje inicial del cliente.

Si se renueva la suscripción, BillingMeld toma en cuenta el nuevo período pagado.

Si el usuario desactiva la renovación automática, el período actual sigue vigente hasta su fin.

Si se realiza un reembolso o la operación es retirada, el estado se altera nuevamente.

En este esquema, la app no mantiene una “verdad” independiente sobre la compra. Trabaja con un estado verificado y almacenado por BillingMeld.

Qué pasa en el cambio de dispositivo

El modelo server-side es especialmente útil cuando el usuario cambia de teléfono o reinstala la app.

El derecho a la compra no debe existir solo porque una copia concreta de la app alguna vez vio una transacción exitosa.

Y, por otro lado, reinstalar la app no debe eliminar el derecho confirmado del usuario.

Si el estado de la compra está en el servidor y vinculado a una operación confirmada en la tienda, el nuevo dispositivo puede obtener el estado actual a través del servidor.

Esta es otra razón para no guardar toda la lógica de acceso únicamente en el cliente móvil.

¿Qué beneficios aporta a los desarrolladores?

Para equipos que lanzan varias apps o trabajan con iOS y Android, la gestión de la facturación rápidamente se vuelve una tarea de infraestructura separada.

Hay que tener en cuenta:

• diferentes formatos de datos de Apple y Google;

• confirmación de la compra inicial;

• renovaciones de suscripción;

• fin del período pagado;

• desactivación de la renovación automática;

• reembolsos;

• retiros de operaciones;

• reinstalaciones de la app;

• cambio de dispositivo;

• restauración de compras;

• cambios en el estado sin participación del cliente.

BillingMeld externaliza toda esta lógica en una capa especializada.

Los servidores del producto trabajan con ella mediante un contrato unificado y no deben interpretar por sí mismos las particularidades de cada tienda.

Esto reduce la duplicación de código y, lo que es aún más importante, disminuye la probabilidad de que diferentes aplicaciones de una misma empresa interpreten de manera diferente un mismo escenario de pago.

Lo importante ya no es el cheque, sino el derecho actualizado

Lo que más me interesó de esta arquitectura es la transición de verificar una compra aislada a controlar el estado actual.

El hecho histórico del pago en sí mismo no responde a la pregunta principal del producto:

¿el usuario tiene derecho en este momento a la función de pago?

La operación puede tener una compra inicial exitosa, pero un período finalizado.

La suscripción puede tener la renovación automática desactivada, pero el período ya pagado sigue vigente.

Puedo tener una renovación confirmada.

Puede haber un reembolso realizado.

La tienda puede retirar la operación.

Por eso, el objeto principal ya no es la factura ni la respuesta inicial del cliente, sino el derecho actual del usuario, calculado sobre la base del estado confirmado de la compra.

Este estado es el que BillingMeld transmite a otros servicios.

BillingMeld como frontera entre tiendas y productos

Como resultado, surge una frontera arquitectural bastante clara.

Por un lado, están App Store y Google Play con sus formatos, eventos, reglas y ciclos de vida de compra.

Por otro, las apps y servicios internos, que en la mayoría de los casos solo necesitan una respuesta mucho más sencilla: qué derechos tiene actualmente el usuario.

Entre ambos, BillingMeld.

Recibe los datos de la tienda, los verifica, los normaliza a su propio modelo y proporciona a la infraestructura restante un resultado ya normalizado.

Esto evita que los productos necesiten conocer todas las particularidades internas de cada plataforma de pago.

Por qué esto es importante para el usuario

Para el usuario, una arquitectura de facturación correcta en teoría debería mantenerse casi imperceptible.

Si la compra está confirmada y el período pagado está vigente, el acceso debe funcionar.

Si el usuario desactivó la renovación automática, el período ya pagado no debe terminar antes de tiempo.

Si hay una renovación exitosa, el acceso debe continuar.

Si la tienda confirmó un reembolso o una devolución, el sistema debe reflejar correctamente el cambio en el derecho.

Al cambiar de dispositivo o reinstalar la app, el usuario no debería tener que demostrar manualmente a cada parte de la infraestructura que la compra realmente existe.

En última instancia, la regla es bastante simple:

el cliente informa sobre la compra, la tienda es una fuente externa de su estado, BillingMeld verifica y normaliza ese estado, y los demás servicios toman decisiones basándose en los datos confirmados de BillingMeld.

Por eso, BillingMeld no es solo un módulo de pago más.

Es una capa de confianza en el servidor entre la app móvil, las tiendas de Apple y Google, y los productos que necesitan entender exactamente qué derechos pagos tiene el usuario en ese momento.

Más detalles en el proyecto: billingmeld.de.