BillingMeld: зашто плаћање треба проверити сервер, а не апликација

Куповина унутар мобилне апликације обично изгледа једноставно за корисника. Он притиска на дугме, потврђује плаћање, добија приступ функцији или претплати — и очекује да ће све након тога радити аутоматски.

За развијача, након тог дугмета почиње много сложенији процес. Мора потврдити саму куповину, узети у обзир продужења, истек претплате, повраћаје, промене статусних операција, промену уређаја и разлике између продавница Apple и Google.

Главни проблем настаје када сервер почне сматрати да је клијентска апликација извор истине.

Ако апликација јави: „Куповина извршена“, сервер отвора приступ и наставља да се ослања на један пут као што је текао ону једном примљену ситуацију. Али животни циклус куповине се тиме не завршава.

Може бити продужена, аутопродужање може бити онемогућено, плаћање може бити враћено, а сама операција — повучена продавницом.

Због тога у BillingMeld куповину потврђује не апликација, већ сервер.

Клијент јавља, али не одлучује

У архитектури BillingMeld мобилна апликација није главни извор информација о куповини.

Клијент може пренети податке о извршеној операцији, али то је само основа за проверу. Коначну одлуку доноси серверски део BillingMeld, који проверава информације преко инфраструктуре Apple или Google.

Ово је кључна разлика.

Апликација на телефону може радити са старим стањем, можда не добити време промена или пренети податке који више не одговарају актуелном статусу куповине.

Поред тога, клијент не би требао самостално одлучивати да ли кориснику може да буде омогућен платни приступ.

BillingMeld проверава, на пример:

• да ли таква куповина заиста постоји;

• да ли се односи на одређену апликацију и производ;

• да ли је плаћени период тренутно активан;

• да ли је извршено ново продужење;

• да ли је онемогућено даље аутопродужавање;

• да ли је извршен повраћај;

• да ли је операција повучена;

• да ли је платни период истекао.

Тако је порука клијента не више доказ куповине, већ повод да се проверии њено стварно стање.

Јединствени извор истине за сервере

Повезане услуге не морају самостално имплементирати комплетан скуп интеграција са Apple и Google одједном.

Оне се обраћају BillingMeld-у и добијају већ нормализовано стање куповине.

На пример: активан приступ, истекао плаћени период, потврђено ново продужење, онемогућено аутопродужење или куповина повучена.

Ово омогућава јасно делити одговорност.

Apple и Google су извори стања саме продавничке операције. BillingMeld проверава те податке, доводи их до заједничког модела и чува актуелно стање. Коначни производ доноси одлуку о приступу на основу стања BillingMeld-а.

За сервере производа, то значи један contracts довољан за све, уместо више независних интеграција.

Није потребно у свакој услузи понаособ имплементирати правила App Store или Google Play и покушавати ускладити различите формате, догађаје и статусе у општу логику.

Зашто не треба потпуно веровати клијенту

Клијентска апликација ради на уређају корисника.

Може се затворити, поново покренути, обновити из резервне копије, касније поново покренути или инсталирати на другом уређају. Може деловати са старим информацијама или не добити догађај који се десио након прве куповине.

Чак и без интервенције од стране корисника, то чини клијент лошим извором за коначно стање претплате.

На пример, корисник је направио претплату и добио приступ. Касније је вршен поврат или продавница повукла операцију.

Ако сервер зна само о првобитној поруци клијента, он ће и даље сматрати куповину важећом.

У други случај, ако корисник онемогући аутопродужавање, већ плаћени период и даље треба да буде активан до краја.

Ако систем ради само са једноставним стањем као што је „претплата је активна / претплата није“, он ће лако прекинути приступ превремено или га оставити након истека права.

BillingMeld је грађен around другачијој логици: клијент не потврђује своја права. Он јавља догађај, а сервер одређује стварно стање куповине.

Куповина — није једнократни догађај

Једна од главних грешака у архитектури плаћања јесте посматрање куповине као једног догађаја.

У ствари, она има свој животни циклус.

Прво, јавља се операција. Затим се она потврђује од продавнице. За претплату почиње плаћени период. Након тога може бити ново продужење.

Корисник може онемогућити аутопродужавање али наставити користити претплату до истека плаћеног периода.

Плаћање може не успети при следећем продужетку.

Може бити извршен повраћај.

У одређеним случајевима, куповина може бити повучена.

Стога, један догађај „ова куповина је некада постојала“ није довољан.

Сервер мора знати шта је са њом у току сада.

Повлачење куповине не остаје незамечено

Најбоље се то види код повраћених и повучених операција.

Прва куповина могла је бити исправна, корисник је стварно платио и добио приступ.

Али касније стање операције се мења.

Ако BillingMeld прими информацију о промени, он ажурира свој статус куповине и, ако је потребно, проверава податке преко продавнице.

Након тога, повезана услуга ради са новим статусом.

Ово спречава апликацију да бесконачно верује у факат да је корисник једном пријавио успешну куповину још пре пар недеља или месеци.

Ако продавница више не сматра да је право активно, BillingMeld то одражава у свом статусу.

Отказање претплате и истек приступа — није исто

Ово је важна разлика.

Ако корисник онемогући аутопродужавање претплате, то обично не значи да приступ треба одмах престати.

Тренутни плаћени период може продужити свој рок.

У том случају, BillingMeld треба сачувати информацију да даље продужење није омогућено, али и разумети датум истека већ плаћеног периода.

И тек после његовог истека, приступ се више не признаје као активан, уколико ново потврђено продужење није извршено.

То је један од разлога што једноставно бисте могли користити боолеанс вредностsubscription = true за нормално функционисање плаћања није довољно.

Статус претплате увек је повезан са временом и догађајима њеног животног циклуса.

Продужавање — и то посебна провера

Претплата се не завршава првом плаћањем.

Сервер мора знати да ли следеће продужење и да ли је следећи плаћени период заиста потврђен од продавнице.

BillingMeld прати ове промене и ажурира статус претплате.

Ако је продужено, право на приступ се наставља.

Ако следеће плаћање није извршено или продавница више не потврђује следећи период, систем не треба само да проширује приступ по претпоставци.

Кориснику то има природан изглед: приступ траје онолико колико је стварно активна плаћена претплата.

За развојне тимове, то значи да једног истога логика за продужење не треба понављати у свакој апликацији.

Како изгледа обична сценарио

Корисник региструје претплату у мобилној апликацији.

Клијент добија информације о куповини и преноси потребне податке BillingMeld-у. Али, сам овај порука још није разлог да се куповина сматра потврђеном.

BillingMeld проверава оперативу преко одговарајуће продавнице.

Ако App Store или Google Play потврди куповину и њено стање одговара правилима производа, BillingMeld региструје активно право.

Након тога, повезана услуга пружа кориснику плаћене могућности.

Стање наставља да живи независно од почетне поруке клијента.

Ако се претплата продужи, BillingMeld узима у обзир нови плаћени период.

Ако корисник онемогући аутопродужавање, тренутни период наставља да важи до краја.

Ако дође до поврата или повлачења операције, статус се поново мења.

У овој шеми, апликација не задржава свој посебни „истину“ о куповини. Она ради са стањем које је потврђено и сачувано од стране BillingMeld-а.

Шта се дешава када се промени уређај

Специјално користан модел када корисник мења телефон или поново инсталира апликацију.

Право на куповину не треба постојати само зато што је одређени примерак апликације некада успешном трансакцијом видео.

И обрнуто, поновна инсталација апликације не смее укинути потврђено право корисника.

Ако стање куповине буде на серверској страни и повезано је са потврђеном продавничком операцијом, нови уређај може добити актуелно стање преко клиента.

То је још један разлог зашто не треба логика приступа да се изричито чува само у мобилној апликацији.

Шта то доноси развијачима

За тим који развија више мобилних апликација или ради са iOS и Android-ом истовремено, плаћање врло брзо постаје посебна инфраструктурна компонента.

Потребно је узети у обзир:

• различите форматe Apple и Google;

• потврду прве куповине;

• продужетак претплата;

• истек плаћеног периода;

• онемогућавање аутопродужавања;

• повраћаје;

• повлачење операција;

• респромин уређаја;

• враћање куповина;

• промену стања које се догодила без учешћа корисника.

BillingMeld ову логику извлачи у посебан специјализовани слој.

Сервери производа ради са тим подршком по једном уговору и не треба сами интерпретирати све особине сваке продавнице.

То смањује број дуплираног кода и, што је још важније, смањује ризик да различите апликације исте компаније буду различито разумеју један исти плаћаони сценарио.

Главно не више је потврда, већ актуелни статус

Највише ме у овој архитектури заинтересовао прелазак од провере једне куповине ка контроли актуелног стања.

Историјска трансакција сама по себи још не одговара на главно питање производа:

да ли корисник тренутно има право на платну функцију?

Може бити успешна прва куповина, али истекао период.

Може бити онемогућено аутопродужавање, али претплата и даље важи за стару плаћену серију.

Може бити потврђено продужење.

Може бити извршен поврат.

Продавница може повући операцију.

Због тога важан је не чек и одговор клиента, већ актуелно право корисника, засновано на потврђеном стању куповине.

Управо то стање BillingMeld прослеђује другим сервисима.

BillingMeld као граница између продавница и производа

Као резултат, јавља се прилично јасна архитектонска граница.

С једне стране су App Store и Google Play са својим форматима, догађајима, правилима и животним циклусима куповина.

С друге стране — апликације и интерне услуге, којима у већини случајева треба много једноставнији одговор: која су права тренутно активна код корисника.

Између њих налази се BillingMeld.

Он прихвата продавничке податке, проверава их, доводи до сопственог модела и пружа осталој инфраструктури већ нормализовани резултат.

Захваљујући томе, производи не морају знати све унутрашње особености сваке плаћаоне платформе.

Зашто је то важно за корисника

За корисника, исправна биллинг архитектура у идеалу уопште треба да остане ненаметљива.

Ако је куповина потврђена и плаћени период важи, приступ треба функционисати.

Ако је корисник онемогућио даље аутопродужење, плаћени период не треба пре раније времена престати.

Ако је извршено ново успешно продужење, приступ треба да се настави.

Ако продавница потврди повраћај или повлачење, систем треба исправно да одрази промену права.

При променама уређаја или поновној инсталацији апликације, кориснику не сме бити потребно рутински доказивати да извршена куповина ипак постоји.

На крају, правила су довољно једноставна:

клијент јавља о куповини, продавница јесте спољни извор стања, BillingMeld проверава и нормализује то стање, а остали сервисни слојеви доносе одлуке већ на основу потврђених података BillingMeld-а.

Због тога BillingMeld није само још један модуљ за наплату.

То је серверски слој поверења између мобилне апликације, продавница Apple и Google и производа који треба да прецизно знају која платна права корисник тренутно има.

Више о пројекту: billingmeld.de.