BillingMeld: perché il server dovrebbe verificare l'acquisto anziché l'applicazione

Di solito, l'acquisto all’interno di un’app mobile sembra semplice per l’utente: tocca il pulsante, conferma il pagamento, ottiene l’accesso alla funzione o all’abbonamento — e si aspetta che tutto funzioni automaticamente.

Per lo sviluppatore dietro questa interfaccia, inizia un processo molto più complesso. È necessario confermare l’acquisto stesso, prendere in considerazione i rinnovi, la fine dell’abbonamento, i rimborsi, il cambio di dispositivo, le differenze tra i negozi Apple e Google, e tenere traccia delle operazioni.

Il problema principale si presenta quando il server inizia a considerare l’app cliente come l’unica fonte di verità.

Se l’app dice: «Acquisto completato», il server apre l’accesso e si basa su quello stato una volta ricevuto. Ma il ciclo di vita dell’acquisto non si ferma lì.

Può essere esteso, il rinnovo può essere disattivato, il pagamento può essere rimborsato, e l’operazione stessa può essere revocata dal negozio.

Per questo motivo, in BillingMeld, l’acquisto viene verificato non dall’app, ma dal server.

Il cliente segnala, ma non decide

Nell’architettura di BillingMeld, l’app mobile non è la fonte principale di informazioni sugli acquisti.

Può trasmettere dati sull’operazione effettuata, ma questa è solo una base per la verifica. La decisione finale la prende la parte server di BillingMeld, che verifica le informazioni tramite l’infrastruttura di Apple o Google.

Questa è una differenza fondamentale.

L’app sul telefono può lavorare con uno stato obsoleto, non ricevere tempestivamente l’ultimo aggiornamento o trasmettere dati che ormai non corrispondono più alla situazione attuale dell’acquisto.

Inoltre, il cliente non dovrebbe avere la possibilità di decidere autonomamente se l’utente ha diritto ad un accesso pagato.

BillingMeld verifica, ad esempio:

• se l’acquisto esiste davvero;
• se si riferisce all’app e al prodotto corretti;

• se il periodo pagato è attualmente valido;
• se è stato effettuato un rinnovo;
• se il rinnovo automatico è disattivato;
• se è stato eseguito un rimborso;
• se l’operazione è stata revocata;
• se il periodo pagato non è ancora terminato.

In questo modo, il messaggio del cliente non diventa una prova definitiva dell’acquisto, ma un motivo per verificarne lo stato reale.

Una fonte unica di verità per i server

I servizi integrati non devono implementare autonomamente tutte le integrazioni con Apple e Google contemporaneamente.

Possono rivolgersi a BillingMeld e ricevere lo stato dell’acquisto già normalizzato.

Ad esempio: accesso attivo, periodo pagato terminato, rinnovo confermato, rinnovo automatico disattivato o acquisto revocato.

Questo consente di dividere chiaramente le responsabilità.

Apple e Google sono le fonti dello stato di ogni operazione di negozio. BillingMeld verifica questi dati, li uniforma a un modello comune e conserva lo stato aggiornato. Il prodotto finale prende decisioni sull’accesso basandosi sullo stato di BillingMeld.

Per i server di prodotto, questo significa un contratto unico invece di molteplici integrazioni indipendenti.

Non è più necessario implementare separatamente le regole di App Store, Google Play, e poi cercare di uniformare diversi formati, eventi e stati secondo una logica comune.

Perché non si può fidarsi completamente del cliente

L’app cliente funziona sul dispositivo dell’utente.

Può essere chiusa, riavviata, ripristinata da backup, aggiornata successivamente o installata su un altro dispositivo. Potrebbe funzionare per un po’ con dati obsoleti o non ricevere eventi successivi all’acquisto originale.

Anche senza intervento dell’utente, questo rende il cliente una cattiva fonte di verità definitiva sullo stato dell’abbonamento.

Ad esempio, l’utente ha sottoscritto un abbonamento e ha ottenuto l’accesso. Successivamente, può essere stato effettuato un rimborso o il negozio ha revocato l’operazione.

Se il server conosce solo il primo messaggio del cliente, continuerà a considerare l’acquisto come attivo.

In un’altra situazione, l’utente può aver disattivato il rinnovo automatico. Ma il periodo già pagato dovrebbe rimanere attivo fino alla sua scadenza.

Se il sistema si basa solo su uno stato rudimentale come «abbonamento attivo / non attivo», rischia di chiudere l’accesso troppo presto o di lasciarlo attivo oltre la scadenza.

BillingMeld si basa su un’altra logica: il cliente non conferma i propri diritti. Il cliente segnala un evento, ma lo stato reale dell’acquisto viene determinato dal server.

L'acquisto non è un singolo evento

Uno degli errori principali nell’architettura di billing è considerare l’acquisto come un evento isolato.

In realtà, ha un ciclo di vita.

Prima si verifica l’operazione. Successivamente viene confermata dal negozio. Il periodo a pagamento inizia con l’abbonamento. Più avanti può essere effettuato un ulteriore rinnovo.

l’utente può disattivare il rinnovo automatico, ma continuare a usare l’abbonamento fino alla fine del periodo pagato già attivo.

Il pagamento può fallire al rinnovo successivo.

Può essere emesso un rimborso.

In alcuni casi, l’acquisto può essere revocato.

Quindi, il semplice fatto «questa acquisition è avvenuta in passato» non basta.

Il server deve sapere cosa sta succedendo adesso.

La revoca dell’acquisto non passa inosservata

Soprattutto quando si tratta di rimborsi e revoche, questa esigenza della architettura server emerge chiaramente.

Un acquisto iniziale poteva essere perfettamente valido. L’utente ha pagato realmente e ha ottenuto l’accesso.

Ma successivamente, lo stato dell’operazione può cambiare.

Se BillingMeld riceve informazioni sulla modifica, aggiorna il suo stato e, se necessario, verifica nuovamente i dati tramite il negozio.

Di conseguenza, il servizio connesso lavora con il nuovo stato aggiornato.

In questo modo, l’applicazione non si affida più in modo illimitato al fatto che settimane o mesi fa l’utente abbia comunicato una condizione di acquisto riuscita.

Se il negozio non considera più valida la relativa autorizzazione, BillingMeld lo riflette nel suo stato.

Cancellazione dell’abbonamento e fine dell’accesso: non sono la stessa cosa

Qui c’è una differenza importante.

Se l’utente disattiva il rinnovo automatico, in genere ciò non significa che l’accesso si interrompa immediatamente.

Il periodo già pagato può continuare a essere attivo.

In tal caso, BillingMeld deve conservare le informazioni su questa disattivazione del rinnovo, ma anche conoscere la data di fine del periodo già pagato.

Solo al termine di questo, l’accesso si considera terminato, a meno che non venga confermato un nuovo rinnovo.

Questo è uno dei motivi per cui non basta un semplice booleano subscription = true per il billing normale.

Lo stato dell’abbonamento è sempre legato al tempo e agli eventi del suo ciclo di vita.

Il rinnovo è un’altra verifica a parte

L’abbonamento non si conclude al primo pagamento.

Il server deve capire se c’è stato un rinnovo e se il successivo periodo pagato è realmente confermato dal negozio.

BillingMeld monitora tali cambiamenti e aggiorna lo stato dell’abbonamento.

Se il rinnovo è confermato, il diritto all’accesso continua.

Se il pagamento successivo fallisce o il negozio non conferma più il prossimo periodo, il sistema non dovrebbe semplicemente prorogare l’accesso sulla base di supposizioni.

Per l’utente, questo appare naturale: l’accesso dura finché il periodo pagato è valido.

Per gli sviluppatori, questo significa che non devono ripetere la stessa logica di rinnovo in ogni applicazione.

Come funziona uno scenario tipico

L’utente sottoscrive un abbonamento tramite l’app mobile.

Il cliente riceve le informazioni sull’acquisto e trasmette i dati necessari a BillingMeld. Tuttavia, questo messaggio non è ancora una prova definitiva dell’effettivo conferma dell’acquisto.

BillingMeld verifica l’operazione tramite il negozio corrispondente.

Se App Store o Google Play confermano l’acquisto e lo stato è in linea con le regole del prodotto, BillingMeld registra il diritto attivo.

Successivamente, il servizio connesso fornisce all’utente le funzionalità pagate.

Lo stato continua a esistere indipendentemente dal primo messaggio del cliente.

Se l’abbonamento viene rinnovato, BillingMeld aggiorna il nuovo periodo pagato.

Se l’utente disattiva il rinnovo automatico, il periodo corrente continuerà fino alla fine.

Se avviene un rimborso o una revoca, lo stato viene aggiornato nuovamente.

In questa configurazione, l’app non mantiene una propria “verità” dell’acquisto, ma funziona con lo stato verificato e conservato da BillingMeld.

C cosa succede quando si cambia dispositivo

Il modello server-side è particolarmente utile quando l’utente cambia telefono o reinstalla l’app.

Il diritto all’acquisto non dovrebbe esistere solo perché l’istanza dell’app ha visto una transazione riuscita.

Anche la reinstallazione dell’app non dovrebbe invalidare una autorizzazione confermata.

Se lo stato dell’acquisto è mantenuto sul server e collegato alla operazione confermata nel negozio, il nuovo dispositivo può ottenere lo stato attuale tramite il server.

Un motivo in più per non conservare la logica di accesso esclusivamente all’interno dell’app mobile.

C cosa porta ai sviluppatori

Per un team che pubblica più applicazioni o lavora su iOS e Android, il billing si trasforma rapidamente in una questione infrastrutturale separata.

È necessario considerare:

• diversi formati di dati di Apple e Google;
• conferma dell’acquisto iniziale;
• rinnovi di abbonamento;
• fine del periodo pagato;
• disattivazione del rinnovo automatico;
• rimborsi;
• revoca dell’operazione;
• reinstallazione dell’app;
• cambio di dispositivo;
• ripristino degli acquisti;
• cambiamenti di stato senza intervento del cliente.

BillingMeld trasferisce questa logica in uno strato separato e dedicato.

I server di prodotto lavorano con esso secondo un contratto unico e non devono interpretare da soli tutte le caratteristiche di ogni negozio.

Questo riduce il codice duplicato e, cosa ancora più importante, diminuisce la probabilità che più applicazioni della stessa azienda interpretino diversamente lo stesso scenario di pagamento.

L’importanza dello stato corrente, più che di un check

La cosa che più mi interessa di questa architettura è il passaggio da una verifica isolata di un acquisto a un controllo dello stato attuale.

Il fatto che un pagamento sia stato inizialmente confermato non risponde più alla domanda fondamentale del prodotto:

l’utente ha ancora diritto alla funzione a pagamento?

Può esserci stato un acquisto iniziale riuscito, ma il periodo finirà.

Il rinnovo automatico può essere disattivato, ma il periodo già pagato può ancora essere attivo.

Può esserci stato un rinnovo confermato.

Può esserci stato un rimborso.

Il negozio può revocare l’operazione.

Per questo, l’elemento principale non è più il check né la risposta iniziale del cliente, ma lo stato attuale calcolato in base alle condizioni confermate dell’acquisto.

Proprio questo è lo stato che BillingMeld trasmette agli altri servizi.

BillingMeld come confine tra negozi e prodotti

Questo porta a una chiara divisione architetturale.

Da un lato ci sono App Store e Google Play con i loro formati, eventi, regole e cicli di vita degli acquisti.

Dall’altro — le applicazioni e i servizi interni che, nella maggior parte dei casi, hanno bisogno di una risposta molto più semplice: quali diritti ha attualmente l’utente.

Tra loro si interpone BillingMeld.

Accetta i dati del negozio, li verifica, li trasforma nel proprio modello e fornisce all’infrastruttura circostante il risultato già normalizzato.

Così, i prodotti non devono conoscere tutte le caratteristiche interne di ogni piattaforma di pagamento.

Perché questo è importante per l’utente

Per l’utente, una buona architettura di billing dovrebbe essere in sostanza invisibile.

Se l’acquisto è confermato e il periodo pagato è attivo, l’accesso dovrebbe funzionare.

Se l’utente disattiva il rinnovo automatico, il periodo già pagato non deve terminare prematuramente.

Se c’è un nuovo rinnovo riuscito, l’accesso deve continuare.

Se il negozio conferma un rimborso o una revoca, il sistema dovrebbe riflettere correttamente questa modifica di diritto.

In caso di cambio dispositivo o reinstallazione, l’utente non dovrebbe dover dimostrare manualmente a ogni parte dell’infrastruttura che l’acquisto è davvero esistito.

Può essere riassunto così: il cliente segnala, il negozio nasce come fonte esterna di stato, BillingMeld verifica e normalizza, e gli altri servizi prendono decisioni sulla base dei dati confermati da BillingMeld.

Per questo motivo, BillingMeld non è solo un altro modulo di pagamento.

È uno strato server di fiducia tra l’app mobile, i negozi Apple e Google, e i prodotti che devono comprendere esattamente quali diritti a pagamento appartengono all’utente in questo momento.

Per saperne di più sul progetto: billingmeld.de.