Mateixa subscripció a web, iOS i Android: com evitar cobraments dobles amb un estat unificat

Vendre un servei digital a través de múltiples canals és habitual per a qualsevol empresa de programari o continguts. Un usuari pot descobrir el producte des del navegador del seu ordinador, registrar-se a través d'una campanya a xarxes socials i utilitzar després el servei al seu telèfon mòbil, ja sigui a iOS o a Android. Tanmateix, quan conviuen diferents canals de facturació, sorgeix un problema operatiu greu: el doble cobrament involuntari.

Aquest escenari es produeix quan un client amb una quota activa a la web instal·la l'aplicació mòbil i, en trobar-se amb una pantalla de pagament nativa, es torna a subscriure a través d'Apple In-App Purchase o Google Play Billing. També passa a la inversa: usuaris que paguen a la botiga mòbil i després introdueixen la seva targeta a la web creient que han de renovar l'accés. Per resoldre aquest conflicte no n'hi ha prou d'atendre queixes a suport; és imprescindible dissenyar una arquitectura de subscripció amb un estat d'accés unificat.

La identitat d'usuari davant de l'identificador de la botiga

L'origen dels cobraments duplicats rau en la desconnexió entre dues identitats: el compte de l'usuari al teu servei i el seu compte a l'ecosistema de la botiga (l'Apple ID o el compte de Google). Per a les botigues d'aplicacions, la transacció està vinculada exclusivament al seu propi entorn, sense saber a quin client intern correspon fins que el teu servidor rep el rebut de compra i l'associa.

Per evitar friccions tècniques i operatives dins de l'ecosistema de pagos en apps, la regla fonamental és que els permisos d'accés mai no han de dependre del dispositiu ni validar-se de manera aïllada al client mòbil. L'estat de la subscripció ha de residir a la teva pròpia base de dades, vinculat a un compte d'usuari autenticat amb credencials pròpies (com correu i contrasenya o accés federat).

Quan un usuari obre l'aplicació al mòbil, el client ha de consultar primer al servidor si aquest compte ja disposa d'un estat d'accés actiu. Si la subscripció ja és vigent gràcies a un cobrament previ a la web o en una altra botiga, l'aplicació ha de desbloquejar les funcions de pagament immediatament i ocultar qualsevol pantalla de compra o mur de pagament.

Un motor central de subscripcions i webhooks

Per governar múltiples canals sense incoherències, el servidor ha d'actuar com un concentrador d'esdeveniments. Cada canal de cobrament opera amb els seus propis temps i mecanismes de notificació:

• La web: processa pagaments recurrents mitjançant targeta o dèbit bancari a través d'una passarel·la de pagament, que emet esdeveniments de cobrament, fallada o cancel·lació mitjançant webhooks directes al servidor.
• Apple App Store: utilitza notificacions de servidor (Server Notifications v2) per avisar de renovacions, cancel·lacions, reemborsaments o períodes de gràcia.
• Google Play: gestiona els esdeveniments de subscripció a través de missatges en temps real mitjançant cues al núvol cap a la teva infraestructura.

El teu sistema ha de normalitzar aquests tres orígens en un únic model de dades. Cada registre de subscripció ha d'emmagatzemar el canal d'origen, l'identificador extern de la transacció i la data d'expiració calculada. D'aquesta manera, la lògica de negoci només consulta un valor: si l'usuari té dret actiu d'ús i fins a quina data.

Aquest esquema resulta indispensable per a una correcta gestió de suscripciones, ja que desacobla la passarel·la concreta del dret efectiu a utilitzar el producte.

Com gestionar canvis de pla i migracions de canal

El conflicte més complex apareix quan un client decideix modificar el seu pla o canviar el mètode de cobrament passant d'una plataforma a una altra. Per exemple, un usuari subscrit a la web que vol aprofitar el saldo d'una targeta de regal al seu compte d'Apple, o un subscriptor de Google Play que vol passar a la web per obtenir una tarifa corporativa anual.

Les botigues mòbils prohibeixen modificar directament una subscripció contractada a les seves passarel·les des d'un servidor extern. Per tant, mai no has d'intentar cobrar a la web a un client la subscripció del qual continuï activa a Apple o Google. Si el sistema detecta que existeix una subscripció mòbil vigent, la interfície web ha d'informar amb claredat que el cobrament es gestiona a través de la botiga corresponent i oferir un enllaç als paràmetres de subscripció del dispositiu.

Per habilitar el canvi de plataforma sense cobraments superposats, el flux tècnic ha de seguir aquests passos:

• Informar el client que ha de cancel·lar primer l'autorenovació a la plataforma d'origen.
• Mantenir l'accés actiu durant els dies restants del cicle de facturació ja pagat.
• Permetre la contractació a la nova plataforma únicament quan la subscripció anterior hagi expirat de manera definitiva.

Aquesta precaució s'ha d'extremar quan intervenen periodos de prueba, ja que un usuari podria activar un període gratuït a la botiga mòbil tenint ja un pla de pagament a la web, cosa que generaria disputes administratives complexes.

El registre previ com a barrera contra compres orfes

Una de les causes habituals de reclamacions és la compra anònima en aplicacions mòbils. Si permets que un usuari premi el botó de subscripció natiu abans d'haver creat o iniciat sessió amb un compte a la teva plataforma, el rebut de compra queda flotant al dispositiu local. Si més endavant inicia sessió amb un correu diferent, el sistema no sabrà a qui assignar aquest cobrament i l'usuari correrà el risc de pagar una altra vegada a la web.

La solució tècnica consisteix a exigir l'autenticació abans de presentar qualsevol opció de compra dins de l'app. Si per raons de disseny permets la compra prèvia, el rebut retornat per Apple o Google ha de quedar desat temporalment al dispositiu i enviar-se al servidor de manera obligatòria i immediata tan bon punt l'usuari completi el registre.

Conclusió

Sincronitzar l'accés entre la web, iOS i Android no és només una qüestió d'interfície, sinó de coherència en el disseny de les dades. Centralitzar els esdeveniments en un únic registre d'usuari al servidor, condicionar la visibilitat de les pantalles de compra a l'estat real del compte i bloquejar contractacions simultànies en diferents canals protegeix la teva empresa contra devolucions i simplifica l'experiència dels teus clients.