BillingMeld: Kāpēc Pirkuma Pārbaudi Veic Servers, Ne Lietotne

Mazajā mobilajā lietotnē veiktais pirkums parasti šķiet vienkāršs lietotājam. Viņš nospiež pogu, apstiprina maksājumu, iegūst piekļuvi funkcijai vai abonementam — un sagaida, ka viss turpinās automātiski.

Izstrādātājam aiz šīs pogas sākas daudz sarežģītāks process. Ir jāapstiprina pati pirkuma darījuma kārta, jāuzrauga pagarinājumi, beigu periodi, atmaksas, operāciju atsaukumi, ierīces maiņa un atšķirības starp Apple un Google veikaliem.

Galvenā problēma rodas, kad serveris sāk uzskatīt klienta lietotni par patiesības avotu.

Ja lietotne paskaidro — „Pirkums veikts”, serveris dod piekļuvi un turpina balstīties uz iepriekš iegūto stāvokli. Taču pirkuma dzīve cikls šeit nebeidzas.

Abonements var tikt pagarināts, automātisks pagarinājums var tikt izslēgts, maksājums var tikt atmaksāts, un pati operācija — atsaukta veikali.

Tādēļ BillingMeld pirkumu apstiprina ne lietotne, bet serveris.

Klients sniedz ziņas, bet nestrādā

Architektūrā BillingMeld mobilā lietotne nav galvenais informācijas avots par pirkumu.

Klients var nodot datus par veikto operāciju, bet tas ir tikai pamats pārbaudei. Gala lēmumu pieņem servera daļa, kas pārbauda informāciju, izmantojot Apple vai Google infrastruktūru.

Tas ir būtisks principa atšķirība.

Telefona lietotne var darboties ar veco stāvokli, laicīgi neiegūt nākamo izmaiņu vai nodot datus, kas jau vairs neatbilst pirkuma aktuālajai situācijai.

Turklāt klients nedrīkst spēt patstāvīgi lemjot, vai lietotājam pienākas maksas piekļuve.

BillingMeld pārbauda, piemēram:

• vai šāda pirkuma vispār ir;

• vai tas attiecas uz konkrētu lietotni un produktu;

• vai maksātais periods šobrīd ir spēkā;

• vai noticis pagarinājums;

• vai ir izslēgts automātiskais pagarinājums;

• vai ir veikta atmaksa;

• vai operācija ir atsaukta;

• vai maksātais periods vēl nav beidzies.

Šādi klienta ziņojums kļūst nevis pierādījums par pirkumu, bet gan iemesls pārbaudīt tā aktuālo statusu.

Vienlaicīgs patiesības avots serveriem

pieslēgtajiem servisiem nav jādara pilns integrācijas process vienlaikus ar Apple un Google.

Tie vēršas pie BillingMeld un saņem jau normalizētu pirkuma statusu.

Piemēram: piekļuve ir aktīva, maksātais periods ir beidzies, pagarinājums apstiprināts, automātiskais pagarinājums ir izslēgts vai pirkums ir atsaukts.

Šāds pieejas mehānisms ļauj skaidri sadalīt atbildību.

Apple un Google ir avoti pašu veikaliņa operācijas statusam. BillingMeld pārbauda šos datus, normalizē tos un saglabā aktuālo stāvokli. Galalēmuma apstiprinājumu pieņem, pamatojoties uz BillingMeld statusu.

Serveriem šis ir viens kopīgs līgums vietā daudziem neatkarīgiem integrēšanas risinājumiem.

Nav jāizstrādā individuālie noteikumi katrai platformai — App Store, Google Play — un jācenšas sapludināt dažādu formātu, notikumu un statusu loģiku kopīgā risinājumā.

Kāpēc klientam nevar pilnībā uzticēties

Klienta lietotne darbojas uz lietotāja ierīces.

To var slēgt, pārstartēt, atjaunot no dublējuma, vēlāk palaist citā ierīcē vai pārinstalēt. Tā var ilgstoši darboties ar veco informāciju vai vispār neiegūt notikumus, kas notikuši pēc sākotnējā pirkuma.

Pat bez lietotāja iejaukšanās šāda lietotne ir slikta galvenā situācijas novērtēšanas avots.

Piemēram, lietotājs ir abonējis pakalpojumu, saņēmis piekļuvi. Vēlāk var tikt veikta atmaksa vai veikts atcelšanas process veikalā.

Ja serveris zina tikai par sākotnējo klienta ziņojumu, tas turpinās uzskatīt pirkumu par aktīvu.

Vēl viena situācija — lietotājs var izslēgt automātisko pagarinājumu. Bet jau maksātais periods ir joprojām aktīvs līdz tā beigām.

Ja sistēma izmanto tikai primitīvo stāvokli „abonements ir / nav”, tā viegli var parādīties situācijā, kad piekļa aizvēršana notiek pārāk agri vai atstāj piekļuvi pēc tiesību beigas.

BillingMeld bāzējas uz citādu loģiku: klients nepierāda savas tiesības. Viņš ziņo par notikumu, bet serveris nosaka faktiskās pirkuma attiecības.

Pirkums — tas nav tikai viens notikums

Viens no galvenajiem kļūdainiem pieņēmumiem biļešu arhitektūrā ir uzturēt pirkumu kā vienotu notikumu.

Patiesībā tas ir dzīvs process ar dažādiem posmiem.

Sākumā ir darījums. Tad tas tiek apstiprināts veikalā. Sākas maksātais periods. Vēlāk var notikt pagarinājums.

Lietotājs var atteikties no automātiskā pagarinājuma, bet turpina izmantot abonementu līdz maksātā perioda beigām.

Nākamās pagarinājuma reizes var nebūt veiksmīgas.

Tādēļ vien, ka pirkums ir reģistrēts kā bijis, vēl nenozīmē, ka tas ir aktuāls šodien.

Serverim jāzina, kas ar to notiek tieši tagad.

Atteikuma neiepriekšējs novērojums

Ārpusē ir skaidrs, cik būtiski ir servera arhitektūra, īpaši atbalstot atgriešanas vai atsaukšanas procesus.

Pirmkārt, sākotnējais pirkums var būt ļoti korekts. Lietotājs ir patiešām samaksājis un ir iegūt piekļuvi.

Bet vēlāk operācijas stāvoklis mainās.

Ja BillingMeld saņem ziņu par izmaiņām, tas atjauno savus pirkuma datus un, ja nepieciešams, vēlreiz pārbauda datus ar veikalu.

Pēc tam pieslēgtā servisa stāvoklis ir atjaunināts ar jaunajiem datiem.

Tādā veidā lietotne vairs nepārliecina par to, ka vairākas nedēļas vai mēnešus atpakaļ klienti ir reiz ziņojuši par veiksmīgu pirkumu.

Ja veikals vairs neuzskata attiecīgo tiesību par aktuālām, BillingMeld to atspoguļo savā statusā.

Abonementa anulēšana un piekļuves terminēšana — nav tas pats

Šeit ir būtiska atšķirība.

Ja lietotājs izslēdz automātisko pagarinājumu, tas parasti nenozīmē, ka piekļuve jāslēdz uzreiz.

Pašreizējais maksātais periods turpinās līdz beigām.

Šādā gadījumā BillingMeld saglabā informāciju, ka pagarinājums ir izslēgts, bet vienlaikus saprot, kad šis maksātais periods beidzas.

Un tikai pēc tā beigām piekļuve tiek uzskatīta par neaktīvu, ja nav noticis jauns apstiprinājums vai pagarinājums.

Tas ir viens no iemesliem, kāpēc vienkārša bool vērtība subscription = true nav pietiekama pareizam pārvaldījumam.

Abonementa statuss vienmēr ir saistīts ar laiku un dzīves cikla notikumiem.

Pagarinājums — tas ir arī atsevišķs pārbaudes punkts

Abonements nebeidzas pirmajā maksājumā.

Serverim jāzina, vai ir noticis nākamais pagarinājums un vai tas ir patiesi apstiprināts veikalā.

BillingMeld seko šīm izmaiņām un atjauno abonementa stāvokli.

Ja pagarinājums ir apstiprināts, piekļuve turpinās.

Ja nākamais maksājums nav noticis vai veikals vairs neapstiprina nākamo periodu, sistēma nedrīkst vienkārši automātiski pagarināt piekļuvi.

Lietotājam tas šķiet dabiski: piekļuve pastāv tik ilgi, cik ir patiesībā darbojošs maksātais abonements.

Izstrādātājiem tas nozīmē, ka nevajag katram lietotnes gadījumam kaut ko atkārtoti realizēt.

Kā tas izskatās ikdienas scenārijā

Lietotājs abonē pakalpojumu mobilajā lietotnē.

Klients saņem pirkuma informāciju un nodod nepieciešamos datus BillingMeld. Bet pati šī ziņa vēl nav galīgs pierādījums, ka pirkums ir apstiprināts.

BillingMeld pārbauda darījumu ar attiecīgo veikalu.

Ja App Store vai Google Play apstiprina pirkumu un tā statuss atbilst produkta noteikumiem, BillingMeld fiksē aktīvu tiesību statusu.

Pēc tam pieslēgtais serviss nodrošina lietotājam maksātos pakalpojumus.

Turpinājumā statuss ir neatkarīgs no sākotnējās klienta ziņas.

Ja abonements tiek pagarināts, BillingMeld ņem vērā jauno maksāto periodu.

Ja lietotājs atslēdz automātisko pagarinājumu, šis periods turpinās līdz beigām.

Ja notiek atmaksa vai atsaukšana, statuss tiek atjaunināts.

Šajā shēmā lietotne nedzīvo ar savu patieso pirkuma stāvokli. Tā darbojas ar statusu, kas apstiprināts un saglabāts BillingMeld.

Kas notiek, mainot ierīci

Servera modelis ir īpaši noderīgs, mainot telefonu vai atkārtoti instalējot lietotni.

Piekļuve nekad nedrīkst balstīties tikai uz to, ka konkrētā lietotne reiz bija veikusi veiksmīgu darījumu.

Pārinstalējot lietotni, pat ja pirkums ir apstiprināts, tas nevar tikt uzskatīts par pilnībā derīgu vai derīgu tikai tāpēc, ka darījuma pierādījums ir serverī.

Ja pirkuma statuss ir norādīts servera pusē un ir saistīts ar apstiprinātu veikaliņa darījumu, jaunais ierīces eksemplārs var saņemt aktuālo statusu caur serveri.

Vēl viena iemesla, kāpēc nav ieteicams visu piekļuves loģiku turēt tikai mobilajā lietotnē.

Ko tas sniedz izstrādātājiem

Komandām, kuras izstrādā vairākas mobilo lietotņu vai strādā ar iOS un Android uzreiz, biļetings kļūst ātri par infrastruktūras uzdevumu.

Jāņem vērā:

• Apple un Google datu formātu dažādības;

• pirmajā pirkumā;

• abonementa pagarinājumos;

• maksātā perioda beigās;

• automātiskā pagarinājuma izslēgšanā;

• atgriezeniskajā saistībā;

• atsaukumu operācijās;

• atkārtotā lietotnes instalācijā;

• ierīces maiņā;

• pirkuma atjaunošanā;

• stāvokļa izmaiņās bez lietotāja iejaukšanās.

BillingMeld šo loģiku ir izvietojis atsevišķā specializētā slānī.

Produkts serveri ar to sadarbojas pēc vienota līguma, un tie nedrīkst veidot atsevišķus pielāgojumus katrai platformai.

Šādi tiek samazināts koda dublējums un, kas vēl svarīgāk, — samazinās varbūtība, ka dažādas uzņēmuma lietotnes interpretēs vienu un to pašu maksājuma scenāriju atšķirīgi.

Galvenais — ne čeks, bet aktuālas tiesības

Šī arhitektūra mani visvairāk interesē ar pāreju no pirkuma pārbaudes uz aktuāla stāvokļa kontroli.

Vēsturiski maksājuma fakts pats par sevi vēl neiekļauj galveno jautājumu:

vai lietotājam pašlaik ir tiesības uz maksas funkciju?

Darījums var būt ar veiksmīgu pirkumu, bet pieejamais periods ir beidzies.

Abonementam var būt izslēgts automātiskais pagarinājums, bet maksātais periods joprojām ir spēkā.

Var būt apstiprināts pagarinājums.

Var būt veikta atmaksas operācija.

Veikals var atsaukt darījumu.

Tādēļ galvenais objekts nav čeks vai sākotnējā klienta ziņa, bet gan lietotāja tiesības, kas tiek aprēķinātas, ņemot vērā apstiprināto pirkuma statusu.

Un šo stāvokli BillingMeld sniedz citiem pakalpojumiem.

BillingMeld kā robeža starp veikaliem un produktiem

Kopumā šajā risinājumā veidojas skaidra arhitektūras robeža.

No vienas puses — App Store un Google Play ar to datu formātiem, notikumiem, noteikumiem un dzīves cikliem.

No otras — lietojumprogrammām un iekšējiem servisiem, kuriem daudz biežāk nepieciešams vienkāršāks atzinums: kādas tiesības ir lietotājam pašlaik.

Intermediarā ir BillingMeld.

Viņš pieņem veikaliņa datus, pārbauda tos, normalizē uz savu modeli un sniedz galapārskatu pārējai infrastruktūrai.

Tādējādi produktiem nav jāzina visas iekšējās īpatnības katram maksājumu nodrošinātājam.

Kāpēc tas ir svarīgi lietotājam

Populāri ir uzskatīt, ka pareiza biļešu arhitektūra ir jāsaskan ar lietotāja līmeni, lai tā būtu nemanāma.

Ja pirkums ir apstiprināts un maksātais periods aktīvs, piekļuve jādarbojas.

Ja lietotājs ir izslēdzis automātisko pagarinājumu, tas nedrīkst radīt iepriekš nav paredzētu piekļuves pārtraukšanu.

Ja ir notikusi jauna pagarināšana, piekļuve turpinās.

Ja ir noticis atgriešanas vai atsaukšanas process, tas ir jāatspoguļo korekti.

Mainoties ierīcei vai atkārtoti instalējot lietotni, lietotājam nevajag manuāli pierādīt, ka pirkums ir noticis.

Beigu beigās šis ir vienkāršs princips:

klients sniedz ziņu par pirkumu, veikals ir ārējs avots tās statusam, BillingMeld pārbauda un normalizē šo statusu, bet pārējie pakalpojumi pieņem lēmumu, balstoties tikai uz apstiprināto stāvokli.

Tādēļ BillingMeld ir ne tikai maksājumu modulis, bet servera uzticības slānis starp mobilajām lietotnēm, veikaliem Apple un Google un produktiem, kas precīzi jāzina piekļuves tiesības lietotājam.

Vairāk informācijas: billingmeld.de.