BillingMeld: miksi ostoksen tulisi vahvistaa palvelimen eikä sovellus

Kohteen sisäinen ostos mobiilisovelluksessa vaikuttaa yleensä käyttäjälle yksinkertaiselta. Hän painaa nappia, vahvistaa maksun, saa pääsyn toiminnallisuuteen tai tilaukseen — ja odottaa, että kaikki jatkuu automaattisesti.

Kehittäjälle tämän napin taustalla alkaa kuitenkin paljon monimutkaisempi prosessi. On vahvistettava itse ostotapahtuma, huomioitava jatkuvat tilaukset, tilauksen päättyminen, palautukset, toimenpiteiden arviointi, laitteen vaihto ja erot Apple ja Google kauppojen välillä.

Ongelma syntyy, kun palvelin alkaa pitää client-sovellusta totuuden lähteenä.

Jos sovellus ilmoittaa: “Osto tehty”, palvelin avaa pääsyn ja jatkaa tämän tilan seuraamista. Mutta oston elinkaari ei pääty tähän.

Tilaukseen voidaan tehdä jatkoa, automaattinen uusinta voidaan poistaa käytöstä, maksu voidaan palauttaa, ja kauppa voi perua toimenpiteen.

Siksi BillingMeld vahvistaa oston ei sovellus, vaan palvelin.

Asiakas raportoi, mutta ei päätä

BillingMeld-arkkitehtuurissa mobiilisovellus ei ole oston pääasiallinen tieto­lähde.

Asiakas voi välittää tiedon suoritetusta toiminnasta, mutta tämä on vain tarkoitus tarkistukselle. Lopullisen päätöksen tekee BillingMeld-palvelin, joka tarkistaa tiedon Apple- tai Google-infrastruktuurista.

Kyseessä on periaatteellinen ero.

Sovellus puhelimessa voi toimia vanhalla tilalla, ei välttämättä saa seuraavaa muutosta ajoissa, tai välittää tiedon, joka ei enää vastaa nykyistä ostotilaa.

Lisäksi asiakkaalla ei pitäisi olla mahdollisuutta päättää itsenäisesti, onko käyttäjällä oikeus maksulliseen käyttöön.

BillingMeld tarkistaa esimerkiksi:

• tuleeko tällainen osto oikeasti olemassa;

• kuuluuko se oikealle sovellukselle ja tuotteelle;

• onko maksettu jakso voimassa;

• onko jatkoa tehty;

• onko automaattinen uusinta poistettu käytöstä;

• onko palautus tehty;

• onko toimenpide peruttu;

• onko maksettu jakso päättynyt

Näin asiakkaan viesti ei ole todiste ostosta itsessään, vaan peruste tarkistaa sen todellinen tila.

Yhtenäinen totuuden lähde palvelimille

Liitetyt palvelut eivät tarvitse toteuttaa itsenäisesti koko integraatioita Appleen ja Googleen samanaikaisesti.

Ne hakevat BillingMeldistä jo normalisoidun oyntaxnitteen.

Esimerkiksi: pääsy on voimassa, maksettu jakso on päättynyt, jatko on vahvistettu, automaattinen uusinta on poistettu käytöstä tai osto on peruttu.

Tämä mahdollistaa vastuun selkeän jakamisen.

Apple ja Google ovat oston tilan lähteet. BillingMeld tarkistaa nämä tiedot, muuttaa ne yhteiseen malliin ja säilyttää ajantasaisen tilan. Lopullinen pääsys päätös tehdään juba BillingMeld-tilan perusteella.

Sovelluksille tämä tarkoittaa yhtenäistä sopimusta, eikä useiden itsenäisten integraatioiden tarvitse olla erikseen.

Ei tarvitse toteuttaa omia App Storen, Google Playn sääntöjä, ja yrittää sovittaa eri formaatien, tapahtumien ja tilojen logiikkaa yhteen.

Ei voi täysin luottaa asiakkaaseen

Asiakassovellus toimii käyttäjän laitteella.

Sitä voi sulkea, uudelleenkäynnistää, palauttaa varmuuskopiosta, päivittää myöhemmin tai käyttää toisella laitteella. Se voi ajoittain toimia vanhalla tiedolla tai olla saamasta tapahtumaa, joka on tapahtunut ostojen jälkeen.

Ainakaan käyttäjän puuttumatta asiaan, tämä tekee asiakkaasta huonon lopullisen tilan lähteen.

Esimerkiksi käyttäjä on tilannut ja saanut pääsyn. Myöhemmin tilaukselle on voitu tehdä palautus, tai kauppa on perunut toimenpiteen.

Jos palvelin tietää vain alkuperäisestä asiakkaan viestistä, se jatkaa ostoksen aktiivisena.

Toisessa tilanteessa käyttäjä voi poistaa automaattisen uusinnan. Tällöin jo maksettu jakso pysyy edelleen aktiivisena loppuun asti.

Jos järjestelmä käsittelee vain yksinkertaista tilaa “osta/ei osta”, se helposti sulkee pääsyn liian aikaisin tai jättää sen jäljelle, vaikka oikeus käyttöön olisi ollut jo lopussa.

BillingMeld perustuu toiseen logiikkaan: asiakas ei vahvista oikeuksiaan itse. Hän raportoi tapahtuman, ja palvelin määrittelee faktisen ostotilan.

Ostot eivät ole yksittäinen tapahtuma

Yksi yleinen virhe laskutusarkkitehtuurissa on käsittää osto kuin yksittäinen tapahtuma.

Sen elinkaari kuitenkin on.

Aluksi tapahtuma syntyy, sitten se vahvistetaan kaupasta. Tilikauden alkaa maksujakso. Myöhemmin voi tulla jatkoa.

Käyttäjä voi poistaa automaattisen uusinnan mutta jatkaa tilauksen käyttöä maksetun jakson loppuun asti.

Maksettu jakso voi jäädä kesken, tai palautus voidaan tehdä.

Joissain tapauksissa osto voidaan perua.

Siksi ei riitä vain tieto, että “ostin joskus”.

Palvelimen on tärkeää ymmärtää, mitä tilassa tapahtuu juuri nyt.

Palautus ei jää huomaamatta

Erityisen hyvin palvelininfrastruktuurin tarve käy ilmi palautuksissa ja peruutuksissa.

Alkuperäinen osto saattoi olla täysin oikea. Käyttäjä maksoi tuote ja sai pääsyn.

Mutta myöhemmin toimenpiteen tila muuttui.

Jos BillingMeld saa tiedon muutoksesta, se päivittää ostotilansa ja tarvittaessa tarkistaa tiedon uudestaan kaupasta.

Tämän jälkeen liitetty palvelu jatkaa uudella tilalla.

Täten tavoin sovellus ei enää voi luottaa siihen, että viime vuosina ilmoitettu ostotilanne on edelleen voimassa, vaan tilan muutokset päivittyvät.

Jos kauppa ei enää tee oikeutta, BillingMeld heijastaa tämän sen tilaan.

Peruutus ja pääsyaikainen käyttöoikeus eivät ole sama asia

Tässä on merkittävä ero.

Jos käyttäjä poistaa automaattisen uusinnan, se ei yleensä tarkoita, että pääsy suljetaan välittömästi.

Voimassa oleva maksettu jakso pysyy käytössä niin kauan kuin sen päättyminen.

Tässä tapauksessa BillingMeldin tulee tallentaa tieto, että jatko on poistettu, mutta samalla ymmärtää maksetun jakson päättymispäivän.

Vain kun sen loppu on saavutettu, pääsyaika päättyy, ellei uuden vahvistuksen ole tullut.

Tämä on yksi syy, miksi yksinkertainen boolean-yksikkö subscription = true ei riitä normaalipäivystykseen.

Tilanteen tila on aina sidoksissa aikaan ja elinkaaritapahtumiin.

Jatkaminen on myös erillinen tarkistus

Tilauksen ei tarvitse päättyä ensimmäiseen maksuun.

Palvelimen tulee ymmärtää, onko tehty jatkoa ja onko seuraava maksettu jakso todella vahvistettu kaupasta.

BillingMeld seuraa näitä muutoksia ja päivittää tilauksen tilaa.

Jos jatko on vahvistettu, pääsy jatkuu.

Jos seuraava laskutus ei tapahdu tai kauppa ei enää vahvista seuraavaa jaksoa, systeemi ei pidä päätöstä itsenäisenä.

Käyttäjälle tämä näyttää luonnolliselta: pääsy on niin kauan kuin maksettu tilaus on voimassa.

Kehittäjille tämä tarkoittaa, ettei tarvitse toteuttaa samaa jatkonlogiikkaa uudestaan jokaisessa sovelluksessa.

Normaalin skenaario

Käyttäjä tekee tilauksen mobiilisovelluksessa.

Klienssi saa tiedon ostosta ja välittää tarvittavat tiedot BillingMeldille. Mutta tämä viesti ei vielä sisällä lopullista vahvistusta ostosta.

BillingMeld tarkistaa tapahtuman asianomaisesta kaupasta.

Jos App Store tai Google Play vahvistaa ostoksen ja sen tila vastaa tuotteen sääntöjä, BillingMeld vahvistaa oikeuden.

Tämän jälkeen liitetty palvelu tarjoaa käyttäjälle maksetut toiminnot.

Tilantila jatkaa elämäänsä riippumatta alkuperäisestä asiakasviestistä.

Jos tilaus jatkuu, BillingMeld päivittää uuden maksetun jakson.

Jos käyttäjä poistaa automaattisen uusinnan, nykyinen jakso jatkuu loppuun.

Jos palautus tai peruutus tapahtuu, tilanne muuttuu taas.

Tässä mallissa sovellus ei säilytä omia “totuuksia” ostosta. Se toimii tilalla, joka on vahvistettu ja tallennettu BillingMeldiin.

Mitä tapahtuu laitetta vaihdettaessa

Palvelinmalli on erityisen hyödyllinen, kun käyttäjä vaihtaa puhelinta tai asentaa sovelluksen uudelleen.

Oikeutta ostoon ei pitäisi olla vain siksi, että laite on aiemmin nähnyt onnistuneen tapahtuman.

Sama pätee, että sovelluksen uudelleenasennus ei saa tuhota vahvistettua oikeutta.

Jos oston tila sijaitsee palvelimella ja liittyy vahvistettuun kaupan tapahtumaan, uusi laite voi saada tilan palvelimen kautta.

Tämä on vielä yksi syy olla säilyttämättä käyttöoikeuslogiikkaa pelkästään mobiilikliensissä.

Mitä tämä tarkoittaa kehittäjille

Ryhmäterä, joka julkaisee useita mobiilisovelluksia tai työskentelee samanaikaisesti iOS:n ja Androidin kanssa, huomaa, että laskutus muuttuu hyvin nopeasti erilliseksi infrastruktuuritehtäväksi.

On otettava huomioon:

• Apple ja Google eri formaatit

• alkuperäisen oston vahvistaminen

• tilauksen jatkot

• maksetun jakson päättyminen

• automatisen uusinnan poistaminen

• palautukset

• toimenpiteiden peruutukset

• sovelluksen uudelleenasennus

• laitteen vaihto

• ostojen palautukset

• ilman asiakkaan osallistumista tapahtuneet tilan muutokset

BillingMeld siirtää tämän logiikan erilliseen kerrokseen.

Tuotantopalveluiden tulee käyttä tämän kanssa sopimuksen kautta, eikä yrittää tulkita kaikkia kauppakohtaisia erityispiirteitä itse.

Se vähentää päällekkäisten koodien määrää ja mikä tärkeämpää, vähentää riskiä, että eri sovellukset yrityksessä ymmärtävät maksutapahtuman eri tavoin.

Tulevaisuuden luotettava signaali ei ole /

Minua arkitehtuurin muutos kiinnostaa eniten siirtymässä yksittäisen ostotapahtuman varmistamisesta nykyisen tilan valvontaan.

Oston historiatapahtuma ei itsessään vastaa pääkysymykseen:

onko käyttäjällä oikeutta maksulliseen ominaisuuteen nyt?

Vaikka alkuperäinen ostos on onnistunut, vain jakson päättyminen ei riitä.

Tilauksella voi olla off-automaattinen uusinta, mutta silti voimassa oleva maksetun jakson aika.

Voi olla vahvistettu jatko.

Voi olla palautus.

Kauppa voi perua tapahtuman.

Siksi tärkein tieto ei ole tiketti tai asiakkaan alkuperäinen vastaus, vaan ajantasainen oikeus, joka perustuu vahvistettuun ostotilaan.

Juuri tämä tila jaetaan muille palveluille BillingMeldin kautta.

BillingMeld – kauppojen ja tuotteiden rajapinta

Tästä muodostuu selkeä arkkitehtoninen raja.

Toisaalta App Store ja Google Play omine formaatteineen, tapahtumineen, sääntöineen ja ostojen elinkaarineen.

Toisaalta sovellukset ja sisäiset palvelut, jotka tarvitsevat hermostumattoman vastauksen: mitä oikeuksia käyttäjällä on tällä hetkellä.

Näiden välissä on BillingMeld.

Se ottaa kauppojen tiedot, tarkistaa ne, muuttaa ne omaan malliin ja tarjoaa muun infrastruktuurin jo normalisoidun tuloksen.

Tämä tarkoittaa, että tuotteiden ei tarvitse tietää kaikkia ostopalveluiden sisäisiä yksityiskohtia.

Miksi tämä on tärkeää käyttäjälle

Suunnilleen oikea laskutusarkkitehtuuri pitäisi pysyä käyttäjälle näkymättömänä.

Jos osto on vahvistettu ja maksettu jakso voimassa, pääsy toimii.

Jos käyttäjä on poistanut automatisen uusinnan, jo maksettu jakso ei saa katketa ennenaikaisesti.

Jos tapahtuu uusi vahvistettu jatko, pääsy jatkuu.

Jos kauppa vahvistaa palautuksen tai peruutuksen, oikeus muutetaan oikein.

Kun laitetta vaihdetaan tai sovellus asennetaan uudelleen, käyttäjän ei tarvitse manuaalisesti todistaa, että ostohistoria todellakin on olemassa.

Loppujen lopuksi sääntö on yksinkertainen:

asiakas raportoi ostosta, kauppa on ulkoinen lähde tilasta, BillingMeld tarkistaa ja normalisoi tämän tilan, ja loput palvelut tekevät päätöksen vasta vahvistettujen tietojen perusteella.

Juuri tästä syystä BillingMeld ei ole vain yksi maksuväline-moduuli.

Se on palvelinverran luottamuksen kerros mobiilisovelluksen, Apple- ja Google-kauppojen ja lopullisten tuotteiden välillä, jotka tarvitsevat tarkasti ymmärtää, mitä maksullisia oikeuksia käyttäjälle tällä hetkellä kuuluu.

Lisätietoja projektista: billingmeld.de.