BillingMeld: kwa nini seva inapaswa kuthibitisha ununuzi kuliko programu

Ununuzi ndani ya programu ya simu kwa ujumla huonekana kuwa rahisi kwa mtumiaji pekee. Anabonyeza kitufe, anathibitisha malipo, anapata ufikiaji wa kipengele au usajili — na anatarajia kuwa kila kitu kitafanya kazi kiotomatiki baadaye.

Kwa mteja, nyuma ya kitufe hiki huanza mchakato mgumu zaidi. Inahitajika kuthibitisha ununuzi wenyewe, kuzingatia kuhusu mageuzi ya usajili, kumalizika kwa usajili, urejeshaji, maoni ya operesheni, mabadiliko ya kifaa na tofauti kati ya maduka ya Apple na Google.

Shida kuu huibuka pale ambapo seva inaanza kuhesabu programu ya mteja kama chanzo cha ukweli.

Iweza kusema: “Ununuzi umekamilika”, na seva ifungue ufikiaji na kuendelea kuzingatia hali iliyopatikana awali. Lakini mzunguko wa maisha wa ununuzi hauishi hapo.

Usajili unaweza kusasishwa, urekebishaji wa moja kwa moja unaweza kuzimwa, malipo yanaweza kurejeshwa, na operesheni yenyewe inaweza kutwaliwa na duka.

Ndiyo maana BillingMeld inathibitisha ununuzi si kwa programu, bali kwa seva.

Client anasema, lakini haamua

Katika usan architecture wa BillingMeld, programu ya simu si chanzo kikuu cha habari kuhusu ununuzi.

Client inaweza kupitisha data kuhusu operesheni iliyofanyika, lakini hii ni tu msingi wa uthibitisho. Uamuzi wa mwisho hufanywa na sehemu ya seva ya BillingMeld, ambayo inathibitisha habari kupitia miundombinu ya Apple au Google.

Hii ni tofauti muhimu.

Programu kwenye simu inaweza kufanya kazi na hali ya zamani, isiweze kupokea mabadiliko ya ghafla kwa wakati, au kuwasilisha data ambazo hazilingani tena na hali halisi ya ununuzi.

Pia, client haipaswi kuwa na uwezo wa kuamua kwa kujiamulia kwamba mtumiaji anastahili ufikiaji wa kulipia.

BillingMeld inakagua, kwa mfano:

• Je, ununuzi huo upo halali;

• Je, unahusiana na programu na bidhaa inayohusika;

• Je, kipindi chilicholipwa kwa sasa kinatumika;

• Je, mageuzi ya ununuzi yamefanyika tena;

• Je, urekebishaji wa moja kwa moja umezimwa;

• Je, kurejeshwa kwa malipo kumefanyika;

• Je, operesheni imetwaliwa na duka;

• Je, kipindi cha kulipwa hakijamalizika bado.

Hii inafanya ujumbe wa mteja usiwe ushahidi wa ununuzi, bali ni sababu ya kuangalia hali yake halisi.

Chanzo kimoja cha ukweli kwa seva

Huduma zilizounganishwa hazihitaji kutekeleza uratibu kamili kati ya Apple na Google kwa wakati mmoja.

Wanawasiliana na BillingMeld na hupata hali ya ununuzi iliyosahihishwa tayari.

Mfano: ufikiaji umewekwa, kipindi cha kulipwa kimemalizika, mageuzi ya ununuzi yameshaithibitishwa, urekebishaji wa moja kwa moja umezimwa, au ununuzi umeretwa.

Hii inaruhusu majukumu kugawanyika waziwazi.

Apple na Google ndizo vyanzo vya hali ya operesheni ya duka. BillingMeld inathibitisha data hizi, kuzifanya ziwe mfano wa pamoja, na kuzihifadhi kwa hali sahihi. Mchakato wa mwisho unabeba uamuzi wa ufikiaji kwa msingi wa hali ya BillingMeld.

Kwa seva za bidhaa, hii ina maana ya mkataba mmoja badala ya utekelezaji wa uratibu kwa kila duka kipekee.

Hakuna haja ya kutekeleza kanuni za App Store au Google Play kwa kila huduma kwa kipekee, na kujaribu kuleta muundo, matukio na hali tofauti kuwa na mpangilio wa pamoja.

Kwanini mteja hawezi kuaminika kikamilifu

Programu ya mteja inafanya kazi kwenye kifaa cha mtumiaji.

Inaweza kufungwa, kuanzishwa upya, kurudishiwa kutoka kwa nakala rudufu, kusanidiwa tena baadaye au kuanzishwa kwenye kifaa kingine. Inaweza kufanya kazi kwa muda na habari za zamani au kukosa tukio muhimu lililotokea baada ya ununuzi wa awali.

Kwa mfano, mtumiaji akasajili usajili na kupata ufikiaji. Baadaye, ununuzi ukarejeshwa au duka likarejesha operesheni.

Ikitambuliwa kuwa tu na server kuhusu ujumbe wa awali wa mteja, seva itaendelea kuhesabu ununuzi kuwa halali.

Kwa hali nyingine, mtumiaji anaweza kuzima urekebishaji wa moja kwa moja, na kipindi kilicholipwa kinapaswa kuendelea hadi mwisho wa wakati wa matumizi.

Ikitumia hali ya chini kama “usajili upo / haupo”, mfumo utaanza kufunga ufikiaji mapema kuliko inavyopaswa au kuacha ufikiaji baada ya kipindi cha ufikiaji kuisha.

BillingMeld imejengwa kwa mtiririko tofauti: client haitathibitisha haki zake binafsi. Inatoa kuhusu tukio, na seva inathibitisha hali halisi ya ununuzi.

Ununuzi si tukio moja tu

Kwa kweli, una mzunguko wa maisha.

Anapatikana operesheni, inathibitishwa na duka. Kisha, usajili huanza kwa kipindi cha kulipwa. Baadaye, mageuzi ya ununuzi yanaweza kufanyika tena.

Mtumiaji anaweza kuzima urekebishaji wa moja kwa moja, lakini bado aendelee kuboresha usajili hadi mwisho wa kipindi cha kulipwa.

Malipo yanaweza kushindikana kwa mageuzi ya baadaye.

Urejeshaji unaweza kufanyika.

Kwa hali tofauti, ununuzi unaweza kuitwa. Hii inamaanisha sio kwamba mshiko wa ununuzi ni tukio moja tu, bali ni mzunguko wa maisha halisi wa ununuzi wenye hali nyingi.

Kwa sababu hii, seva inahitaji kuelewa hali ya sasa ya ununuzi, si tu kumbukumbu ya ukweli wa zamani.

Urejeshaji wa ununuzi hauachiwa bila kugunduliwa

Hii ni wazi zaidi ikiwa kuna urejeshaji na uvunjaji wa operesheni.

Ununuzi wa awali ulikuwa sahihi. Mtumiaji alilipa kwa kweli na alipata ufikiaji wa bidhaa.

Lakini, baadaye hali ya operesheni ikabadilika.

Ikitambua mabadiliko, BillingMeld huongeza hali yake ya ununuzi na, inapohitajika, huongeza uhakiki kupitia duka.

Baada ya hapo, huduma iliyounganishwa inafanya kazi na hali mpya.

Hii huondoa imani isiyo na kikomo kwamba, miezi michache au miezi mingi iliyopita, mteja aliripoti kuwa na ununuzi wa mafanikio.

Ikiwa duka halichukii tena haki hiyo, BillingMeld huionyesha hali hiyo.

Kufuta usajili na kumalizika kwa ufikiaji si vitu hivyo hivyo

Haya yana tofauti muhimu.

Ikitokea mtumiaji amezima urekebishaji wa moja kwa moja, hii kwa kawaida haimaanishi kwamba ufikiaji unapaswa kufungwa mara moja.

Kwa mfano, kipindi cha kulipwa kinaendelea, na baada ya kuwa na malipo, ufikiaji unapaswa kuendelea hadi mwisho wa kipindi cha sasa.

Hali ya BillingMeld inapaswa kuhifadhi taarifa ya uzuia wa mageuzi ya baadaye, lakini pia kuelewa tarehe ya mwisho wa kipindi cha kulipwa kilichopo tayari.

Na, tu baada ya mwisho wa kipindi hicho, ufikiaji usihesabiwe kuwa wa kutosha, ikiwa hakuna mageuzi ya kuthibitishwa yatakayofanyika.

Hii ni mojawapo ya sababu sababu mbaya kutumia tu thamani ya kweli subscription = true kwa usawa wa kawaida wa ununuzi.

Hali ya usajili huendelea kuhusiana na wakati na matukio ya mizunguko ya maisha.

Uboreshaji ni pia uthibitisho tofauti

Usajili hauishii kwenye malipo ya kwanza tu.

Seva inapaswa kuelewa ikiwa mageuzi ya ununuzi yalitokea na kama kipindi kijacho cha kulipwa kimehifadhiwa na duka.

BillingMeld inazifuata hivyo na kuendesha hali ya usajili.

Ikitambua mageuzi ya kuthibitishwa, haki ya ufikiaji inaendelea.

Ikiwa malipo yanashindikana au duka halithibitishi kipindi kijacho, mfumo haupaswi kuongeza ufikiaji kwa hiari yake.

Kwa mtumiaji, hali hii inahisi kama ya kawaida: ufikiaji uwepo muda wote wa usajili ulio na haki halali.

Kwa waendelezaji, hii ina maana kwamba hawapasi kuandika tena mchakato mmoja wa kuongeza ufikiaji katika kila programu.

Jinsi mfumo wa kawaida unaonekana

Mtumiaji anasajili usajili kwenye programu ya simu.

Client hupokea habari kuhusu ununuzi na kupitisha data muhimu kwa BillingMeld. Lakini ujumbe huu bado si msingi wa kuhesabu ununuzi kuwa wa kuthibitishwa kikamilifu.

BillingMeld inathibitisha operesheni kupitia duka husika.

Ikiwa App Store au Google Play inathibitisha ununuzi na hali yake inakubali kanuni za bidhaa, BillingMeld inarejesha haki ya active.

Baada ya hapo, huduma iliyounganishwa huendelea kutoa huduma zilizolipwa.

Halafu, hali inachukua hali mpya bila kujali ujumbe wa awali wa mteja.

Ikiwa usajili unaongezwa, BillingMeld inazingatia kipindi cha kulipwa kipya.

Ikiwa mtumiaji anazima urekebishaji wa moja kwa moja, kipindi chenye malipo kinaendelea hadi mwisho wake wa kisasa.

Ikiwa operesheni inarejeshwa au inasusiwa, hali inabadilika tena.

Kwenye mfumo huu, programu haihifadhi hali yake binafsi kuhusu ununuzi. Inashirikiana na hali iliyothibitishwa na kuhifadhiwa na BillingMeld.

Nini kinatokea wakati wa kubadilisha kifaa

Modeli ya seva ni muhimu hasa wakati mtumiaji badilisha simu au anasakinisha programu tena.

Haki ya ununuzi haipaswi kuishi kwa sababu tu mfano maalum wa programu uliona operesheni yenye mafanikio hapo awali.

Kwa hivyo, usakinishaji upya wa programu haupaswi kuharibisha haki ya kuthibitishwa ya mtumiaji.

Ikiwa hali ya ununuzi iko upande wa seva na ina uhusiano na operesheni iliyothibitishwa kwa duka, kifaa kipya kinaweza kupokea hali halisi kupitia seva.

Hii ni sababu nyingine ya kutotegemea kutoka kwa lesa ya ufikiaji ndani ya programu ya simu pekee.

Hii ni kwa manufaa ya waendelezaji nini

Kwa timu inayotengeneza programu kadhaa za simu au zinazofanya kazi kwa wakati mmoja na iOS na Android, bili mara nyingi hubadilika kuwa mchakato wa miundombinu pekee.

Inahitaji kuzingatia:

• miundo tofauti ya data za Apple na Google;

• uthibitisho wa ununuzi wa awali;

• mageuzi ya usajili;

• kumalizika kwa kipindi kilicholipwa;

• kuzima kwa urekebishaji wa moja kwa moja;

• urejeshaji;

• uvunjaji wa operesheni;

• ufungaji upya wa programu;

• ubadilishaji wa kifaa;

• kuanzisha na kurejesha ununuzi;

• mabadiliko ya hali yaliyotokea bila ushiriki wa mteja.

BillingMeld huleta mchakato huu kwa tabaka maalum la usan architecture.

Seva za bidhaa zinashirikiana nayo kwa mkataba mmoja, na hawapaswi kuhitaji kuainisha sifa za kila duka binafsi.

Hii hupunguza idadi ya msimbo unaojirudia na, ni muhimu zaidi, hupunguza hatari ya kwamba programu tofauti za kampuni moja zitakuelewa mchakato mmoja wa malipo kwa njia tofauti.

Kitu kikuu si risiti, bali haki halali ya sasa

Kile kinachonivutia zaidi katika usan architecture huu ni uhamaji kutoka kwa uthibitishaji wa ununuzi mmoja kwa kudhibiti hali halisi.

Hali ya awali ya malipo yenyewe bado haitoi jibu kuu kwa bidhaa:

Je, mtumiaji anastahili haki ya kutumia kazi ya kulipia sasa?

Operesheni inaweza kuwa na ununuzi wa awali wa mafanikio, lakini kipindi kikamalizika.

Usajili unaweza kuwa na urekebishaji wa moja kwa moja kuzimwa, lakini kipindi cha kulipwa kinaweza kuendelea.

Urekebishaji wa kuthibitishwa unaweza kuwa wa kweli.

Urejeshaji unaweza kufanyika.

Huka duka inaweza kuita operesheni.

Kwa hivyo, si risiti au jibu la awali la mteja ndilo muhimu, bali haki halali ya mtumiaji iliyokokotwa kwa msingi wa hali thibitisho ya ununuzi.

Hali hii inatolewa kwa huduma zingine na BillingMeld.

BillingMeld kama kikomo kati ya maduka na bidhaa

Matokeo yake ni uwepo wa mduara wa usan architecture utatuainishwa vizuri.

Kwa upande mmoja kuna App Store na Google Play na miundo yao, matukio, kanuni na mizunguko ya maisha ya ununuzi.

Kwa upande mwingine, kuna programu na huduma za ndani, zinazohitaji jibu rahisi zaidi: haki gani mtumiaji ana sasa.

Kati yao kuna BillingMeld.

Unashiriki data za duka, kubaini zinazoendana na mfano wa BillingMeld, na kuwasilisha matokeo yaliyosahihishwa kwa miundombinu nyingine.

Hii inaruhusu bidhaa kupunguza uhitaji wa kujua sifa zote za mfumo wa malipo wa kila duka.

Kwanini hii ni muhimu kwa mtumiaji

Kwa mteja, usan architecture wa bili sahihi unapaswa kuwa usioonekana kabisa.

Ikiwa ununuzi umethibitishwa na kipindi cha kulipwa kinahakikisha, ufikiaji unapaswa kufanya kazi bila usumbufu.

Ikiwa mtumiaji amezima mageuzi ya moja kwa moja, kipindi kinacholipwa tayari hakipaswi kuondolewa mapema zaidi ya wakati wa mwisho wa kisheria.

Ikiwa mageuzi ya mafanikio yameshakatika, ufikiaji unapaswa kuendelea.

Ikiwa duka limekiri urejeshaji au kukamata operesheni, mfumo unapaswa kuonyesha mabadiliko ya haki kwa usahihi.

Wakati wa kubadilisha kifaa au kusakinisha tena programu, mtu haipaswi kuonyesha kwa mikono kila sehemu ya miundombinu kwamba ununuzi bado upo.

Hatimaye, kanuni inaweza kuwa rahisi:

client anatoa habari kuhusu ununuzi, duka ni chanzo cha hali yake; BillingMeld inathibitisha na kubadilisha hali hiyo, na huduma nyingine zote zinachukua uamuzi kwa msingi wa data zilizothibitishwa na BillingMeld.

Ndiyo maana BillingMeld si moduli nyingine tu ya malipo, bali ni tabaka la kuaminika kati ya programu ya simu, maduka ya Apple na Google, na bidhaa zinazohitaji kufahamu haki za malipo za mtumiaji kwa sasa.

Kwa maelezo zaidi kuhusu mradi: billingmeld.de.