BillingMeld: неге сатып алуды қолданба емес, сервер тексеруі керек

Мобильді қолданба ішіндегі сатып алу әдетте қолданушы үшін қарапайым болып көрінеді. Ол батырманы басады, төлемді растайды, функцияға немесе жазылымға қол жеткізеді — әрі қарай бәрі автоматты түрде жұмыс істейтіндей күтіледі.

Дамытушы үшін артында әлдеқайда күрделі процесс басталады. Оған сатып алудың өзі екенін растау, ұзартуларды, жазылымның аяқталуын, қайтаруларды, операциялар туралы пікірлерді, құрылғы өзгерісін және Apple мен Google дүкендерінің айырмашылықтарын ескеру қажет.

Негізгі мәселе пайда болады, егер сервер клиенттік қолданбаның шындығының дереккөзі ретінде саналса.

Егер қолданба «Сатып алу жасалды» деп хабарласа, сервер қол жеткізуді ашады және бұрын алынған жағдайға қарай жалғастырады. Бірақ сатып алу өмірлік циклі мұнымен аяқталмайды.

Жазылым жалғуы мүмкін, автоматты ұзарту өшірілуі мүмкін, төлем қайтарылуы мүмкін, ал операция дүкен тарапынан қайтарылуы мүмкін.

Сондықтан да BillingMeld-те сатып алуды қолданбаның емес, сервердің растайтыны маңызды.

Клиент хабарлайды, бірақ шешім қабылдамайды

BillingMeld архитектурасында мобильді қолданба сатып алу туралы негізгі дереккөзі емес.

Клиент жасалған операция туралы мәлімет бере алады, бірақ ол тек тексеру негізі болады. Қорытынды шешімді BillingMeld сервері қабылдайды, ол ақпаратты Apple немесе Google инфрақұрылымдары арқылы тексереді.

Бұл принциптік айырмашылық.

Телефондағы қолданба ескі жағдаймен жұмыс істей алады, жаңа өзгерістерді уақытында алуы мүмкін емес немесе жеткізуі мүмкін еместігі бар. Сонымен қатар, ол сатып алудың негізгі жағдайымен сәйкес келмейтін деректерді бере алады.

Сонымен бірге, клиентке пайдаланушыға ақылы қол жеткізу құқығын өз бетінше шешуге мүмкіндік бермеу керек.

BillingMeld мысалдар келтіреді:

• Шын мәнінде мұндай сатып алу бар ма;

• ол қажетті қолданба мен өнімге қатысы бар ма;

• қай кезде төленген кезең әлі де іске қосулы ма;

• келесі ұзарту жасалды ма;

• автоматты ұзарту өшірілді ме;

• қайтару жасалды ма;

• операция қайтарылған ба;

• таратылған кезең аяқталды ма.

Осылайша, клиент хабарламасы сатып алудың дәлелі емес, оның нақты жағдайын тексерудің себебі болады.

Серверлер үшін бір шындық көзі

Қосылған сервистер Apple мен Google-дің толық интеграциясын өздері жүзеге асыру қажет емес.

Олар BillingMeld-ке жүгініп, сатып алудың қалыпқа келген жағдайын алатынын алады.

Мысалы: қол жеткізу белсенді, төленген кезең аяқталды, келесі ұзарту расталды, автоматты ұзарту өшірілді немесе сатып алу қайтарылды.

Бұл жауапкершілікті нақты бөлуге мүмкіндік береді.

Apple және Google — дүкен операциясының жағдай көздері. BillingMeld бұл деректерді тексеріп, оларды жалпы модельге әкеледі және актуалды жағдайды сақтайды. Ал соңғы қолдану бұл ақпарат негізінде қол жеткізуді шешеді.

Өнім серверлері үшін бұл бірнеше тәуелсіз интеграцияларды бір контрактта біріктіруді білдіреді.

Әрбір қызметте App Store немесе Google Play ережелерін жүзеге асыру керек болмайды, әртүрлі форматтарды, оқиғалар мен статустарды жалпы логикаға айналдыру қажет емес.

Клиентке толық сенуге болмайтын себебі

Клиенттік қолданба пайдаланушы құрылғысында жұмыс істейді.

Оны жабуға, қайта іске қосуға, сақтық көшірмеден қалпына келтіруге, кейін жаңартуға немесе басқа құрылғыда іске қосуға болады. Ол ұзақ уақыт ескі мәліметпен жұмыс істей алады немесе бастапқы сатып алудан кейін болған оқиғаны мүлдем алмаған болуы мүмкін.

Қолданушының әсері болмаса да, клиент соңғы жағдайдың дереккөзі ретінде сенімді емес.

Мысалы, қолданушы жазылым сатып алып, қол жеткізу алса, кейін қайтару немесе дүкен операцияны қайтарып алуы мүмкін.

Егер сервер тек клиенттің бастапқы хабарламасын білсе, ол сатып алуды әрекеттегі деп санай береді.

Басқа жағдайларда қолданушы автоматты ұзартуды өшірсе, төленген кезең әлі де аяқталмайынша, ол қолданыста бола береді.

Жай ғана «жазылым бар/жазылым жоқ» күйі жүйені асығыс жабуға немесе жалғастыруға әкелуі мүмкін, бұл пайдаланушының рұқсаты аяқталғанша қосулы қалуға әкеледі.

BillingMeld басқа логикаға құрылды: клиент өз құқығын растамайды. Ол оқиғаны хабарлайды, ал сервер нақты жағдайды анықтайды.

Сатып алу — бір оқиға емес

Биллинг архитектурасындағы негізгі қателіктің бірі — сатып алуды бір оқиға ретінде қарастыру.

Шындығында оның өмірлік циклі бар.

Алдымен операция пайда болады, содан кейін дүкен оны растайды. Жазылым үшін төленген кезең басталады. Кейін ол ұзартылуы мүмкін.

Қолданушы автоматты ұзартуды өшіре алады, бірақ жазылымды пайдалана береді, төленген кезең аяқталғанша.

Келесі ұзарту сәтсіз болуы мүмкін.

Қайтару жасалуы мүмкін.

Кейде сатып алу қайтарылуы мүмкін.

Сондай-ақ кейбір жағдайларда сатып алуды қайтарып алуға болады.

Сондықтан «осы сатып алу бұрын болған, бірақ қазір жоқ» фактісі жеткіліксіз.

Серверге оның қазір қандай күйде екенін түсіну маңызды.

Қайтару оқиғасы байқалмай қалмайды

Қайтарулар мен операцияларды қайтару жағдайында серверлік архитектура қажеттілігі айқын көрінеді.

Бастапқы сатып алу дұрыс болған болуы мүмкін, қолданушы шынымен төледе және қол жеткізді.

Бірақ кейін операция жағдайы өзгерді.

Егер BillingMeld өзгерістер туралы ақпарат алса, ол өз сатып алу жағдайын жаңартады және қажет болғанда дүкен арқылы деректерді қайта тексереді.

Осыдан кейін қосылған қызмет жаңа жағдаймен жұмыс істеуді жалғастырады.

Осылайша, қолданба бір мысалға негізделген «бір рет сатып алынды» фактісіне сенім артпайды, ал бақылау деректерін тексеруді жалғастырады.

Дүкен оған құқықты қазірше жарамды деп саналмайтын жағдайда, BillingMeld бұл жағдайды өз жағдайында көрсетеді.

Жазылымды тоқтату мен қол жеткізуді жою бірдей емес

Мұнда маңызды айырмашылық бар.

Қол жеткізуді тоқтату үшін автоматты ұзартуды өшірсеңіз, ол әдетте бірден қол жетімділікті жабуды білдірмейді.

Ағымдағы төленген кезең әрі қарай жұмыс істей береді.

Мұндай жағдайда BillingMeld ұзартуды өшіргенін сақтайды, бірақ аяқталу күнін де біледі.

Одан кейін ғана кезең аяқталғаннан кейін қол жетімділік жабылады, егер жаңа расталған ұзарту болмаса.

Бұл жағдай үшін, қарапайым «жазылым бар/жоқ» мәні жеткіліксіз екенін көрсетеді.

Жазылым жағдайы әрқашан уақытқа және оның өмірлік цикліндегі оқиғаларға байланысты.

Ұзарту — басқа тексеру түрі

Жазылым алғашқы төлеммен аяқталмайды.

Сервер мұның келесі ұзартудың болғанын және ол дүкен тарапынан расталғанын түсінуі қажет.

BillingMeld мұндай өзгерістерді қалайды және жазылым жағдайын жаңартады.

Егер ұзарту расталса, қол жеткізу құқықтары жалғасады.

Егер келесі төлөө сәтті болмаса немесе дүкен оны растамаса, жүйе автоматты түрде ұзартуды жалғастырмайды.

Пайдаланушы үшін бұл табиғи көрінеді: қол жеткізу сол кезең ішінде ғана беріледі, ол нақты төленген жазылымға сәйкес.

Дамытушылар үшін бұл бір логиканың бірнеше қолданбада қайталанбауын қамтамасыз етеді.

Пайдаланушы мобильді қолданбада жазылым рәсімдейді.

Қолданба сатып алу туралы ақпаратты алады және қажет деректерді BillingMeld-ке жібереді. Бірақ бұл хабарлама өзінен-өзі сатып алудың толық расталғандығының негізі емес.

BillingMeld тиісті дүкен арқылы операцияны тексереді.

Егер App Store немесе Google Play сатып алуды растаса және оның жағдайлары өнімнің ережелеріне сәйкес келсе, BillingMeld белсенді құқықты белгілейді.

Одан соң қосылған қызмет қолданушыға төленген мүмкіндіктерді ұсынады.

Құжаттық жағдай бұдан әрі бастапқы хабарламаға тәуелсіз өмір сүреді.

Егер жазылым ұзартылса, BillingMeld жаңа төленген кезеңді ескереді.

Қолданушы автоматты ұзартуды өшірсе, ағымдағы кезең аяқталғанша жұмыс істейді.

Егер қайтару немесе операцияны қайтарып алу болса, жағдай қайта өзгереді.

Осы сценарийде қолданба сатып алудың жеке «шындық» дерегін сақтамайды. Ол тек расталған және BillingMeld сақтаған жағдаймен жұмыс істейді.

Құрылғы өзгерген кезде не болады

Серверлік модель әсіресе қызмет алмасу кезінде пайдалы: қолданушы телефонды ауыстырғанда немесе қайта орнатқанда.

Құқық тек бір мысалдың күйіне байланысты пайда болмайды. Қолданба қайта орнату арқылы расталған құқықты жоймайды.

Егер сатып алу жағдайы сервер жағына сақталса және расталған дүкен операциясымен байланысты болса, жаңа құрылғы оны сервер арқылы алуы мүмкін.

Бұл тағы бір себеп — қосымшаның өзіндік логикасын сақтау жеткіліксіз.

Бұдан қандай пайда бар

Бірнеше мобильді қолданбаны шығарумен немесе iOS пен Android-ті бірге қолданумен айналысатын топ үшін биллинг өте жылдам инфрақұрылым мәселесіне айналады.

Оған есепке алуы керек:

• Apple және Google-дің әртүрлі форматтары;

• алғашқы сатып алудың расталуы;

• жазылымдардың жалғастырылуы;

• төленген кезеңнің аяқталуы;

• автоматты ұзартуды өшіру;

• қайтарулар;

• операциялардың қайтарылуы;

• қосымшаны қайта орнату;

• құрылғыны ауыстыру;

• сатып алуды қалпына келтіру;

• пайдаланушы қатысқаны жоқ өзгерістер.

BillingMeld бұл логиканы арнайы қабатқа шығарады.

Өнім серверлері бір контракт бойынша жұмыс істейді және әр дүкеннің ерекшелігін жеке өңдеуі қажет емес.

Бұл қайталанатын код санын азайтып, бір компанияның әртүрлі қолданбалары бір сценарийді дұрыс түсінбеуін болдырмайды.

Бастысы — чек емес, өз құқығы

Бұл архитектурада мені ең көп қызықтырғаны — сатып алуды тексеруден актив жағдайды бақылау тәсіліне көшу.

Төлемнің өзінен тарихи фактасы негізгі сұраққа жауап бермейді:

қолданушы қазіргі уақытта төлем функциясына құқы бар ма?

операцияда бастапқы сатып алу болуы мүмкін, бірақ мерзімі аяқталды;

жазылымда автоматты ұзарту өшірілген, бірақ төленген кезең әлі де жүреді;

растау бар, қайтару жасалды, дүкен операцияны қайтарды, құқығымен нақты жағдайды анықтау маңызды.

Осыдан, чек немесе алғашқы клиенттің жауабы емес, расталған жағдай негізінде анықталған қолданушы құқығы басты объектіге айналады.

Бұны BillingMeld басқа сервистерге береді.

BillingMeld — дүкендер мен өнімдер арасындағы шекара

Нәтижесінде нақты архитектуралық шекара пайда болады.

Бір жағында App Store мен Google Play және олардың форматтары, оқиғалары, ережелері мен өмірлік циклдері орналасқан.

Екінші жағында — қолданбалар мен ішкі сервистер, көбінесе, өте қарапайым жауап қажет: қазіргі уақытта қолданушының құқығы қандай.

Олардың арасында BillingMeld орналасқан.

Ол дүкен деректерін қабылдап, тексеріп, өзіндік моделге айналдырады әрі басқа инфрақұрылымға нормализденген нәтиже береді.

Бұл өнімдердің әрқайсысының ішкі ерекшеліктерін білу қажеттілігін алып тастайды.

Пайдаланушы үшін маңызды не?

Дұрыс биллинг архитектурасы пайдаланушы үшін әдетте байқалмайтындай болуы керек.

Қол жеткізу расталған және төленген кезең әрекетте болса, жұмыс істейді.

Қол жеткізуді автоматты ұзартуды өшірсе, ол мерзім бұрын аяқталмайды.

Жаңа ұзарту сәтті болса, қол жеткізу жалғасады.

Қайтарулар немесе операция қайтарылса, құқық өзгертілгенін дұрыс көрсету керек.

Құрылғыны ауыстырғанда немесе қолданбаны қайта орнатқанда, әрбір инфрақұрылым бөлігі сатып алу бар екенін өзі дәлелдеу қажет емес.

Қорытындысы қарапайым болып табылады:

клиент сатып алуды хабарлайды, дүкен — сыртқы дереккөзі оның жағдайының, BillingMeld оны тексереді және қалыпқа келтіреді, ал қалған сервистер расталған деректер негізінде шешім қабылдайды.

Міне, сол себепті BillingMeld — бұл тек тасымалдау модулі емес, ол мобильді қолданбалар мен дүкендер арасындағы сенім серверлік қабатты ұсынады, ол пайдаланушыға нақты қандай ақылы құқығы бар екенін дәл түсінуге көмектеседі.

Толығырақ ақпарат: billingmeld.de.