BillingMeld: ինչու պետք է արդյուքնում հաստատում կատարվի սերվերից, այլ ոչ թե հավելվածից

Մոբայլ հավելվածի ներսում գնումը սովորաբար միայն օգտագործողի համար է պարզ։ Նա սեղմում է կոճակը, հաստատում է վճարումը, ստանում հասանելիություն ֆունկցիային կամ բաժանորդագրությանը — և սպասում է, որ ամեն ինչը ինքնաբերաբար կաշխատի։

Դա ծրագրավորողի համար ավելի ծանր գործընթաց է։ Կարող է հաստատել գնելու գործընթացը, հաշվի առնել երկարաձգումները, ավարտին հասնող բաժանորդագրությունները, վերադարձները, գործառնությունների արձագանքները, սարքի փոփոխությունը և տարբերությունը Apple և Google խանութների միջև։

Հիմնական խնդիրն առաջանում է, երբ սերվերը սկսում էիք համարել, որ հաճախորդային հավելվածը պահանջի ճշմարտության աղբյուրն է։

Եթե հավելվածը հայտնել է՝ «Գնումը կատարվել է», սերվերը բացում է հասանելիությունը և շարունակվում է հենվել միայն մի անգամ ստացված կարգավիճակի վրա։ Բայց գնումների կյանքի ցիկլը այսքանով չի ավարտվում։

Բաժանորդագրությունը կարող է երկարաձգվել, ավտոմատ երկարաձգումը կարող է անջատվել, վճարումն այցել կարող է վերականգնվել, իսկ գործողությունը՝ վերարկուծվել։

Իրեն BillingMeld-ում գնումը հաստատում է ոչ թե հավելվածը, այլ սերվերը։

Հաճախորդը հայտնում է, բայց չի որոշում

BillingMeld-ի կառույցում մոբայլ հավելվածը չի հանդիսանում հիմնական տեղեկատվության աղբյուր գնման մասին։

Հաճախորդը կարող է փոխանցել կատարված գործարքի տվյալները, բայց դա միայն ստուգման հիմք է։ Վերջնական որոշումը ընդունում է BillingMeld-ի սերվերային մասը, որը ստուգում է տեղեկատվությունը Apple կամ Google ենթակառուցվածքների միջոցով։

Այս արժեքավոր տարբերությունն է։

Հետագա զարգացումները՝ հնացած կամ սխալ տեղեկություններ, որոնք փոխանցված են սխալ ժամանակ՝ կարող են հանգեցնել սխալ որոշումների։

Բացի այդ, հաճախորդին պետք չէ ինքնուրույն որոշել, արդյոք նա ունի վճարովի հասանելիություն։

BillingMeld-ը մասնավորապես ստուգում է՝

• արդյոք այդ գնումը իսկապես կա;

• նվագում է կապված այն անհրաժեշտ հավելվածի և ապրանքի հետ;

• օգտագործվում է արդյոք վճարված ժամկետը;

• կանFür enղձգումներ կամ արտանետումներ;

• արդյոք ավտոմատ երկարաձգումը անջատված է;

• կատարե՞լ է վերադարձ;

• էլ անկյուն է դրվել գործարքը;

• ավելի՞ չավարտված է վճարվող ժամկետը։

Այսպիսով, հաճախորդի հաղորդագրությունը՝ իր տեսանկյունից, չի հանդիսանում գնումը հաստատող փաստացի ապացույց, այլ պարզապես հիմք՝ ստուգելու նրա իրական վիճակն ու կարգավիճակը։

Նույնական աղբյուր՝ ճշմարտության համար

Միացյալ ծառայություններին անհրաժեշտ չէ իրականացնել միաժամանակ խոշոր ինտեգրացիաների ամբողջ հավաքածուն Apple և Google- ի հետ։

Նրանք դիմում են BillingMeld-ին և ստանում են արդեն նորմալացված գնումների կարգավիճակը։

Օրինակ՝ մատչում է ակտիվ, վճարման ժամկետը ավարտված, երկարաձգումը հաստատված, ավտոմատ երկարաձգումը անջատված կամ գնումը վերականգնված է։

Այս մոտեցումը թույլ է տալիս հստակ բաժանել պատասխանատվությունը։

Apple և Google-ն իրենց սեփական տվյալների աղբյուրներն են՝ գործարքի կարգավիճակ։ BillingMeld-ը ստուգում է այդ տվյալները, հարմարեցնում է ընդհանուր մոդելին և պահում է մինչև վերջ актуալացված կարգավիճակը։ Դարաձև, վերջնական արտադրանքը առաջարկում է մուտքի թույլտվությունը՝ արդեն հաշվի առնելով BillingMeld-ի կարգավիճակը։

Սա նշանակում է, որ արտադրանքի սերվերների համար՝ փոխարեն շատ ինքնուրույն ինտեգրացիաների,՝ գործարքների ընդհանուր կառավարումը հեշտ է։

Վերջին նպատակն է՝ չկրկնիվացնել, այլ՝ միավորված մոդելով ապահովել մատչում։

Դա նաև կերպով նվազեցնում է հնարավոր սխալները՝ տարբեր հավելվածներում տարբեր օրինակը misunderstanding։

Համար նորից վստահել հնարավոր չէ

Հաճախորդային հավելվածը աշխատում է օգտագործողի սարքում։

Դա կարելի է փակել, վերածել կամ վերօգտագործել՝ նոր սարքում, կամ վերամշակելու համար մի այլ սարքում։ Դա կարող է որոշ ժամանակ աշխատել հին տվյալներով կամ մերժել նոր գործարքները, որոնք տեղի են ունեցել հաջորդած փոփոխությունների ընթացքում։

Աստվածային սխալներից զերծ՝ այն իր լիարժեք հիմքը չէ՝ որպես վերջնական տեղեկատվության աղբյուր։

Օրինակ՝ օգտվողը փակել է ծանուցումը և ստացել է գրանցում, հետո կատարվել է վերադարձ կամ գործարքը հետզանում են։

Եթե սերվերը գիտի միայն նախնական հաղորդագրության մասին, նա շարունակում է կարծել, որ գործարքը ակտիվ է։

Միաժամանակ, օգտագործողը կարող է անջատել ավտոմատ երկարաձգումը, որն այնուամենայնիվ, չպետք է կարճ պահել մնացած գործող դադարեցումից։

Եթե համակարգը աշխատում է միայն պարզ բուլյան վիճակով՝ «նա կա / նա չկա»,՝ այն հեշտությամբ կկանգնեցնի ավտոմատ անվտանգությունը կամ կհեռացնի հասանելիությունը՝ վատ նպատակներով։

BillingMeld-ի միտքն այն է, որ հաճախորդը չի հաստատում իր իրավունքները։ Նա պարզապես հայտնում է իր իրադարձությունը, իսկ սերվերը որոշում է՝ ինչ է իրական վիճակը։

Գնումը՝ դա չի նշանակում միայն մեկ միջոցառումը

Բազում սխալներ կան գնումների կառավարման բլոկի մեջ՝ համար հաշվի առնելով, որ գնումը միևնույն միջոցառում չէ։

Այն ունի իր կենդանի ցիկլը՝ նախ ցույց է տալիս գործարքը, այնուհետև հաստատում է այն, սկսվում է վճարված ժամկետը, կարելի է երկարաձգել կամ ոչ:

Օգտագործողը կարող է անջատել ավտոմատ առաջացմանը, բայց մինչ այդ շարունակել օգտվել բաժանորդագրությունից։

Վճարումն էլ կարող է չանցնել։

Բեռնում կամ վերականգնում ենթակա է, և նախորդ կարգավիճակին կարող է վերադառնալ։

Սա նշանակում է, որ միայն «այժմ դա կա / չկա» մոդելը չի բավականացնում։

Սերվերը պետք է հասկանալ, թե ինչ է կատարվում հիմա։

Վերահաներում խելամիտ չէ անտեսել

Սա հատկապես պարզ է դառնում վերականգնման և վերադարձի դեպքերում։

Առաջին գնումը կարող էր լինել ճիշտ, օգտվողը լուծել է վճարել և ստացել է հասանելիություն։

Բայց հետո հրավիրված պայմաններում կարգավիճակն արդեն փոխվել է։

Եթե BillingMeld-ն ստանում է այդ փոփոխության մասին տեղեկություններ, նա դարձնում է իր կարգավիճակը համապատասխան և, անհրաժեշտության դեպքում, վավերացնում է նոր տվյալները՝ մոնիթորինգի միջոցով։

Այդ ժամանակ արդեն միացված ծառայությունը աշխատում է նոր կարգավիճակով։

Այսպիսով, հավելվածը չի անընդհատ վստահում այն սեփական «ճշմարտությանը», որ մի երկու շաբաթ կամ ամիս առաջ հաճախորդը հայտնել է հաջող Purchased։

Եթե խանությունը այլևս չի հարգում այդ իրավունքը, BillingMeld-ը արտացոլում է դա իր կարգավիճակում։

Բաժանորդագրությունը չեղարկել և հասանելիությունը ավարտելը — ոչ միովին նույնը չեն

Կա կարևոր տարբերություն։

Եթե օգտվողը անջատում է ավտոմատ երկարաձգումը, դա սովորաբար չի նշանակում, որ հասանելիությունը պետք է անհապաղ փակվի։

Ընթերցված ժամկետը կարող է շարունակել աշխատել։

Այն դեպքում, BillingMeld-ը պետք է պահպանի տեղեկությունը, որ հետագա երկարաձգումը անջատված է, բայց նաև՝ հասկանալ վերջին վճարված ժամկետի ավարտին։

Ու միայն իր ավարտից հետո հասանելիությունը դադարում է լինել ակտիվ, եթե նոր հաստատում տեղի չի ունենում։

Սա մեկ օրինակ է, թե ինչու բավարար չէ պարզապես boolean արժեք՝ subscription = true՝ նորմալ բիլինգի համար։

Բաժանորդագրության վիճակը միշտ կապված է ժամանակի և նրա կենդանի ցիկլի Events-ի հետ։

Մեկն երկարաձգում — դա էլ տարբեր ստուգում է պահանջում

Բաժանորդագրությունը չի ավարտվում առաջին վճարով։

Սերվերը պետք է հասկանալ՝ տեղի ունեցե՞լ է ավելի երկարաձգում, և իսկապես հաջորդ վճարված ժամկետը հաստատված է магазинով։

BillingMeld-ը հետևում է այդ փոփոխություններին և արդիականացնում է բաժանորդագրության կարգավիճակը։

Եթե երկարաձգումը հաստատված է, իրավունք է տրամադրվում աշխատանքի։

Եթե հաջորդ վճարումն չի կատարվում կամ խանութը չի հաստատում հաջորդ օրինակը, համակարգը պետք է պակի իրավունքները՝ ոչ միայն ինքնուրույն կանխատեսելով։

Օգտվողի համար դա բնական տեսք է ստանում՝ հասանելիությունը կա այնքան ժամանակ, որքան գործող է վճարված բաժանորդագրությունը։

Ինժեներների համար սա նշանակում է, որ միևնույն երկարաձգման տրամաբանությունը պետք չէ կրկնել յուրաքանչյուր հավելվածում։

Ինչ է սովորական սցենարը

Օգտվողը բաժանորդագրություն է վերցնում մոբայլ հավելվածում։

Հաճախորդը ստանում է գնելու մասին տեղեկություն և փոխանցում է անհրաժեշտ տվյալները BillingMeld-ին։ Բայց հենց այդ հաղորդագրությունն ինքնին դեռ չէ հաստատում գնումը։

BillingMeld-ը ստուգում է գործարքը համապատասխան խանութով։

Եթե App Store կամ Google Play- ն հաստատում է գնումը և կարգավիճակը համապատասխանում է ապրանքի նշած պայմաններին, BillingMeld-ը հաստատում է ակտիվ իրավունքը։

Ենթակա է հասանելիություն, որը տրամադրում է միացված ծառայությունը։

Հետո վիճակը շարունակվում է գործել անկախ հաճախորդի նախնական հաղորդումից։

Եթե բաժանորդագրությունը երկարաձգվում է, BillingMeld-ը հաշվում է նոր վճարված ժամկետը։

Եթե օգտվողը անջատում է ավտոմատ երկարաձգումը, ներքին ժամանակի ընթացքում գործող ժամկետը մնում է։

Եթե տեղի է ունենում վերադարձ կամ գործարքի վերականգնում՝ կարգավիճակը նոր է փոխվում։

Այնպես որ, հավելվածը չի պահում սեփական «ճշմարտությունը», այլ աշխատում է հաստատված և պահպանված կարգավիճակի հետ՝ հաստատված BillingMeld-ից։

Ինչ է կատարվում փոխել սարքը

Սերվերային մոդելը հատկապես օգտակար է, երբ օգտվողն փոխում է հեռախոսը կամ տեղադրում նորից հավելվածը։

Իրավունքը չի կարող միայն գոյություն ունենալ այն դեպքում, երբ տվյալ հավելվածի பிரதարը երբևէ տեսել է հաջող գործարք։

Եվ հակառակը՝ վերամշակումը չի կարող ոչնչացնել հաստատված իրավունքը օգտվողի։

Եթե կարգավիճակը գտնվում է սերվերի վրա, և կապված է հաստատված գործարքային հետ, նոր սարքը կարող է ստանալ գործող կարգավիճակը սերվերից։

Սա ևս մեկ կարևոր պատճառ է, որ լայնամաշտաբ ինքուրույն իրավասու տրամադրումը կենտրոնական առկայության վրա։

Ինչ արժե դա ծրագրավորողների համար

Ինքնուրույն թիմի համար, որոնք աշխատում են մի քանի մոբայլ հավելվածների կամ iOS և Android տարբերակների վրա, բիլինգը շատ արագ վերածվում է առանձին ինֆրաստրուկտուրային համակարգի։

Նրանք պետք է հաշվի առնեն՝

• Apple և Google տարբեր տվյալների ձևաչափերը;

• առաջին գնելու հաստատումը;

• բաժանորդագրությունների երկարաձգումները;

• վճարված ժամկետների ավարտը;

• ավտոմատ երկարաձգման անջատումը;

• վերադարձները;

• գործարքների առկայությունը;

• հավելվածի կրկնակի տեղադրում;

• սարքի փոխանակումը;

• գնումների վերականգնումը;

• ադրամատիրական կարգավիճակի փոփոխություններ, որոնք տեղի են ունենում օգտագործողի ներգրավվածության გარეშე։

BillingMeld-ը այս ամբողջ տրամաբանությունը տեղափոխում է հատուկ շերտ։

Սպառնալիք են դառնում՝
բոլոր կախված տարբերակների և գործարքների վերաբերյալ՝ թիմերի՝ անկախ մոդելով, որոնք չեն պետք ընդհանրապես բոլոր հատկությունները հաշվի առնել։

Սա նվազեցնում է կրկնվող կոդի քանակը և, առավել կարևոր, նվազեցնում է տարբեր ծրագրեր, միևնույն ծրագրի տարբեր տարբերակներում, տարբեր օպերացիաների իմաստը տարբերվելու վտանգը։

Ավելորդ չի լինի պարզապես ճշմարտության ենթակա լինելը

Նախ, ամենակարևորը՝ կաբինետներին ստիպված չեն կրկնօրինակում վճարման բոլոր հնարավոր սցենարները։

Բոլորը միշտ հասկանում են, թե արդյոք օգտվողի իրավունքը ակտիվ է այսօր, թե ոչ։

Եթե գործարքը հաստատված և վճարման ժամկետը գործող է, մուտքն ապահով է։

Եթե օգտվողը անջատում է ավտոմատ երկարաձգումը, արդեն վճարված ժամկետը չի կարելի կարճակրում։

Եթե տեղի է ունենում փոխարինում, այն արագ ցույց է տալիս նույն կարգավիճակը՝ հաստատված։

Եթե հաստատվում է վերադարձ, կամ գործարքը վերականգնում է ստատուսը՝ համաձայն կարգավիճակի։

Բոլոր այդ պահերը՝ սերվերին փոխանցած իրական տվյալները, որ չեն գործարքների մասին միայն մեկ արձագանք՝ հենց հաճախորդին։

Անհրաժեշտ է, որ այս հետևողականությունը պահպանվի՝ ապահովելու վերջնական ճշմարտություն։

Այսպիսով, քանի որ հիմնականում դա ոչ թե մի միջոցառում է, այլ իրավունքը՝

ա՞յժմ ունի ակտիվ կամ ոչ, արդյոք իրավունքը պատահում է կամ չի՝

հետևաբար, կարևոր է, որ սերվերը ստուգում և հաստատում է այն՝ հիմք ընդունելով ապրանքի կարգավիճակը, ոչ թե՝ պարզապես՝ եկամտային արձանագրությունը։

Ինչպես նաև՝ ցանկացած գործարքի կամ պայմանագրի հաստատումից հետո, այսօր՝ ակտիվ կամ ոչ, ինչպես նաև՝ արդյոք արժե երկարաձգում կամ վերականգնում, որոշում կայացվում է հենց սերվերից։

BillingMeld-ը որպես սահմանագիծ խանութների և արտադրանքների միջև

Այսպիսով, ստեղծվում է բավականին հստակ կառավարման սահմանագիծ։

Մեկ կողմում՝ App Store և Google Play, իրենց ֆորմատներով, իրադարձություններով, պայմաններով և գինաբանական ցիկլերով։

Մյուս կողմում՝ հավելվածներն ու ներքին ծառայությունները, որոնք հաճախ ստանում են ավելի պարզ պատասխան՝ արդյոք օգտվողին այժմ ինչ իրավունքներ են պատկանել։

Այմ երկու կողմերի միջեւ է գտնվում BillingMeld-ը։

Նա ընդունում է խանութի տվյալները, ստուգում է դրանց ճիշտությունը, հարմարեցնում իրենց մոդելին և տրամադրում է մյուս ենթակառուցվածքներին արդեն համակարգեցված արդյունք։

Դա հնարավորություն է տալիս արտադրանքներին չգիտեն ամեն պարամետրը՝ խանութի տվյալները, այլ պարզապես օգտվել՝ հիմնվելով հաստատված և նորմալացված տեղեկատվությանը։

Ինչ է դա նշանակում օգտվողի համար

Օպտիմալ՝ օգտվողի համար բիլինգի ճիշտ համակարգը պետք է մնա ամբողջությամբ անհատական զգացողություններից։

Եթե գնումը հաստատված է և վճարված ժամկետը գործում է, մուտքը պետք է աշխատի։

Եթե օգտվողը անջատում է ավտոմատ երկարաձգումը, վճարված ժամկետը չի չորս ժամով պետք լինի։

Եթե ձևափոխվում է ապրանքը, առաջ ընկնում է բանաձևը, կամ միաժամանակ՝ հանվում է գրանցված իրավունքը, համակարգը պետք է իմանա և հաստատի դա։

Ու երբ փոխվում է սարքը կամ հավելվածը կրկին տեղադրվում է, բիլինգի իրական իրավիճակը չի կարող պարզապես ներկայացվել՝ որպես փոխհրաձգության արդյունք։

Այս քարտը դառնում է բավականին պարզ՝

հաճախորդը հաղորդում է, խանութը՝ իր կարգավիճակը, BillingMeld-ը՝ ստուգում և նորմալացնում այդ տվյալները, մյուս ենթակառուցվածքները՝ կայացնելու որոշումը՝ հիմնվելով հաստատված կարգավիճակի վրա։

Այն պատճառով՝ BillingMeld-ը մի աշխարհք է, որն ապահովում է լիարժեք վստահություն մոբայլ հավելվածների, խանութների Apple և Google- ի նորից, և արտադրանքի նկատմամբ, որը իրականում գիտի՝ թե ո՞ր իրավական իրավունքներն են կիրառվում հաճախորդին։

Լրացուցիչ տեղեկությունների համար՝ billingmeld.de.