Mesma subscrición en web, iOS e Android: como evitar cobros dobres cun estado unificado
Permitir que un cliente use a súa subscrición en calquera plataforma sen pagar dúas veces esixe vincular os cobros a unha conta central. Analizamos a arquitectura necesaria para coordinar web, App Store e Google Play.
Vender un servizo dixital a través de múltiples canles é habitual para calquera empresa de software ou contidos. Un usuario pode descubrir o produto desde o navegador do seu ordenador, rexistrarse a través dunha campaña en redes sociais e empregar despois o servizo no seu teléfono móbil, sexa en iOS ou en Android. Non obstante, cando conviven diferentes canles de facturación, xorde un problema operativo grave: o dobre cobro involuntario.
Este escenario prodúcese cando un cliente cunha cota activa na web instala a aplicación móbil e, ao atoparse cunha pantalla de pagamento nativa, vólvese subscribir a través de Apple In-App Purchase ou Google Play Billing. Tamén ocorre á inversa: usuarios que pagan na tenda móbil e logo introducen a súa tarxeta na web crendo que deben renovar o acceso. Para resolver este conflito non abonda con atender queixas en soporte; é imprescindible deseñar unha arquitectura de subscrición cun estado de acceso unificado.
A identidade de usuario fronte ao identificador da tenda
O orixe dos cobros duplicados reside na desconexión entre dúas identidades: a conta do usuario no teu servizo e a súa conta no ecosistema da tenda (o Apple ID ou a conta de Google). Para as tendas de aplicacións, a transacción está vinculada exclusivamente ao seu propio ecosistema, sen saber a que cliente interno corresponde ata que o teu servidor recibe o recibo de compra e o asocia.
Para evitar friccións técnicas e operativas dentro do ecosistema de pagos en apps, a regra fundamental é que os permisos de acceso nunca deben depender do dispositivo nin validarse de forma illada no cliente móbil. O estado da subscrición debe residir na túa propia base de datos, vinculado a unha conta de usuario autenticada con credenciais propias (como correo e contrasinal ou acceso federado).
Cando un usuario abre a aplicación no móbil, o cliente debe consultar primeiro ao servidor se esa conta xa conta cun estado de acceso activo. Se a subscrición xa está vixente grazas a un cobro previo na web ou noutra tenda, a aplicación debe desbloquear as funcións de pagamento de inmediato e ocultar calquera pantalla de compra ou muro de pagamento.
Un motor central de subscricións e webhooks
Para gobernar múltiples canles sen incoherencias, o servidor debe actuar como un concentrador de eventos. Cada canle de cobro opera cos seus propios tempos e mecanismos de notificación:
- A web: procesa pagamentos recorrentes mediante tarxeta ou débito bancario a través dunha pasarela de pagamento, que emite eventos de cobro, fallo ou cancelación mediante webhooks directos ao servidor.
- Apple App Store: emprega notificacións de servidor (Server Notifications v2) para avisar de renovacións, cancelacións, reembolsos ou períodos de graza.
- Google Play: xestiona os eventos de subscrición a través de mensaxes en tempo real mediante colas na nube cara á túa infraestrutura.
O teu sistema debe normalizar estas tres orixes nun único modelo de datos. Cada rexistro de subscrición debe almacenar a canle de orixe, o identificador externo da transacción e a data de expiración calculada. Deste xeito, a lóxica de negocio só consulta un valor: se o usuario ten dereito activo de uso e ata que data.
Este esquema resulta indispensable para unha correcta gestión de suscripciones, xa que desacopla a pasarela concreta do dereito efectivo a utilizar o produto.
Como xestionar cambios de plan e migracións de canle
O conflito máis complexo aparece cando un cliente decide modificar o seu plan ou cambiar o seu método de cobro pasando dunha plataforma a outra. Por exemplo, un usuario subscrito na web que desexa aproveitar o saldo dunha tarxeta de agasallo na súa conta de Apple, ou un subscritor de Google Play que quere pasar á web para obter unha tarifa corporativa anual.
As tendas móbiles prohiben modificar directamente unha subscrición contratada nas súas pasarelas desde un servidor externo. Polo tanto, nunca debes tentar cobrar na web a un cliente cuxa subscrición continúe activa en Apple ou Google. Se o sistema detecta que existe unha subscrición móbil vixente, a interface web debe informar con claridade de que o cobro se xestiona a través da tenda correspondente e ofrecer unha ligazón aos axustes de subscrición do dispositivo.
Para habilitar o cambio de plataforma sen cobros superpostos, o fluxo técnico debe seguir estes pasos:
- Informar ao cliente de que debe cancelar primeiro a autorenovación na plataforma de orixe.
- Manter o acceso activo durante os días restantes do ciclo de facturación xa pagado.
- Permitir a contratación na nova plataforma unicamente cando a subscrición anterior teña expirado de forma definitiva.
Esta precaución debe extremarse cando interveñen periodos de prueba, xa que un usuario podería activar un período gratuíto na tenda móbil tendo xa un plan de pagamento na web, xerando disputas administrativas complexas.
O rexistro previo como barreira contra compras orfas
Unha das causas habituais de reclamacións é a compra anónima en aplicacións móbiles. Se permites que un usuario prema o botón de subscrición nativo antes de crear ou iniciar sesión cunha conta na túa plataforma, o recibo de compra queda flotando no dispositivo local. Se máis tarde inicia sesión cun correo distinto, o sistema non saberá a quen asignar ese cobro e o usuario correrá o risco de pagar de novo na web.
A solución técnica consiste en esixir a autenticación antes de presentar calquera opción de compra dentro da app. Se por razóns de deseño permites a compra previa, o recibo devolto por Apple ou Google debe quedar gardado temporalmente no dispositivo e enviarse ao servidor de forma obrigatoria e inmediata en canto o usuario complete o rexistro.
Conclusión
Sincronizar o acceso entre a web, iOS e Android non é só unha cuestión de interface, senón de coherencia no deseño dos datos. Centralizar os eventos nun único rexistro de usuario no servidor, condicionar a visibilidade das pantallas de compra ao estado real da conta e bloquear contratacións simultáneas en distintas canles protexe a túa empresa fronte a devolucións e simplifica a experiencia dos teus clientes.
Estás a montar subscricións?
Mira as tarifas e proba o panel con datos de exemplo antes de integrar nada.