BillingMeld: bakit kailangang suriin ng server ang pagbili, hindi ang app

Karaniwang mukhang simple ang pagbili sa loob ng mobile na app para sa user. Ika-klik niya ang button, kinukumpirma ang bayad, nakakakuha ng access sa feature o subscription — at umaasa na lahat ay magpapatuloy na awtomatiko.

Para sa developer, nagsisimula ang isang mas komplikadong proseso sa likod ng button na iyon. Kailangan nitong kumpirmahin ang mismong pagbili, isaalang-alang ang mga renewal, pagtatapos ng subscription, mga pagbabalik, feedback ng operasyon, pagbabago ng device, at mga pagkakaiba sa pagitan ng mga tindahan ng Apple at Google.

Pangunahing problema ang nangyayari kapag ang server ang nagsimulang ituring ang client application bilang pangunahing pinagmumulan ng katotohanan.

Kung ang app ay nagsabi: “Nabuo ang pagbili,” magbubukas ang server ng access at magpapatuloy na nakabase sa isang beses na natanggap na estado. Ngunit hindi dito nagtatapos ang buhay ng isang pagbili.

Maaaring i-renew ang subscription, i-disable ang auto-renew, maibalik ang bayad, o ma-withdraw ang operasyon ng store.

Samakatuwid, sa BillingMeld, hindi app ang nagkukumpirma ng pagbili, kundi ang server.

Sa client nagsasabi, pero hindi nagpapasiya

Sa arkitekturang BillingMeld, ang mobile app ay hindi pangunahing pinagmumulan ng impormasyon tungkol sa pagbili.

Maaaring maghatid ang client ng datos tungkol sa nagawang operasyon, ngunit ito ay paunang hakbang lamang para sa pagsusuri. Ang pinal na desisyon ay ginagawa ng bahagi ng server ng BillingMeld na nagsusuri ng impormasyon gamit ang infrastruktura ng Apple o Google.

Ito ay isang pangunahing pagkakaiba.

Maaaring magtrabaho ang app sa isang luma nang estado, hindi makuha ang kasunod na pagbabago nang tama, o maghatid ng datos na di na tumutugma sa kasalukuyang estado ng pagbili.

Higit pa rito, hindi dapat pinapayagan ang client na magpasya nang mag-isa kung karapat-dapat ang user sa bayad na access.

Sinusuri ng BillingMeld, halimbawa:

• kung talagang umiiral ang pagbili;

• kung ito ay nauugnay sa tamang app at produkto;

• kung aktibo pa ang binayarang panahon;

• kung nangyari ang susunod na renewal;

• kung naka-disable na ang auto-renew;

• kung may refund;

• kung ang operasyon ay na-withdraw;

• kung hindi pa tapos ang binayarang panahon.

Kaya ang mensahe mula sa client ay nagsisilbing hindi patunay sa pagbili, kundi dahilan upang suriin ang aktwal na estado nito.

Pangunahin na pinagmumulan ng katotohanan para sa server

Hindi kailangang magpatupad ang mga nakakabit na serbisyo ng kumpletong integrasyon sa Apple at Google nang sabay-sabay.

Makikipag-ugnayan sila sa BillingMeld at makakatanggap na ng na-normalize na estado ng pagbili.

Halimbawa, aktibo ang access, tapos na ang binayarang panahon, napatunayan ang renew, naka-disable ang auto-renew, o ang pagbili ay na-withdraw.

Nagbibigay-daan ito sa malinaw na paghati-hati ng mga responsibilidad.

Ang Apple at Google ang mga pangunahing pinagmumulan ng estado ng operasyon sa tindahan. Tinatanggap ito ng BillingMeld, inaayos sa isang pangkalahatang modelo, at iniimbak ang kasalukuyang estado. Ang huling produkto ay magpapasya sa access batay sa estado ng BillingMeld.

Para sa mga server ng produkto, nangangahulugan ito ng isang unibersal na kontrata imbes na maraming independiyenteng integrasyon.

Hindi na kailangang gumamit pa ng hiwalay na mga patakaran para sa App Store at Google Play sa bawat serbisyo, o pagsamahin ang iba't ibang format, event, at estado sa isang unibersal na lohika.

Bakit hindi maaaring lubos na umasa sa client

Ang application sa device ay tumatakbo sa device ng user.

Puwedeng isara, i-restart, i-restore mula backup, i-update sa ibang panahon, o patakbuhin sa ibang device. Maaring tumakbo ito nang may lumang impormasyon o hindi makuha ang kasunod na event na nangyari pagkatapos ng orihinal na pagbili.

Kahit walang pakikialam ang user, nagpapahirap ito sa client na maging panghuling pinagmumulan ng estado ng subscription.

Halimbawa, nakapag-subscribe ang user at nakakuha ng access. Ngunit sa kalaunan, may refund o na-withdraw ang store ng operasyon.

Kung ang server ay alam lamang ang orihinal na mensahe mula sa client, magpapatuloy siyang ituring na valid ang pagbili.

Sa ibang sitwasyon, maaring i-disable ng user ang auto-renew. Sa ganitong kalagayan, maaaring ang na-bayaran nang panahon ay mananatili pang aktibo hanggang sa katapusan nito.

Kung gumagana ang sistema sa isang simpleng estado na “may subscription / walang subscription,” madali nitong maisasara ang access nang maaga o mag-iwan ng access kahit tapos na ang karapat-dapat na gamitin.

Binubuo ang BillingMeld ng isang alternatibong lohika: hindi kinukumpirma ng client ang karapatan nito. Ito ay nagsusumite lamang ng mga event, habang ang server ang nag-iimbak ng katotohanan.

Ang pagbili ay hindi isang event lang

Isa sa mga pangunahing pagkakamali sa arkitekturang billing ay ang pagtingin sa pagbili bilang isang beses na event.

Sa katotohanan, mayroon itong isang buhay na cycle.

Una, isang operasyon ang lumilitaw. Pagkatapos ay kinukumpirma ito ng tindahan. Nagsisimula ang binayarang yugto ang subscription. Maaaring may susunod pang renewal.

Maaaring i-disable ng user ang auto-renew, ngunit magagamit pa rin ang subscription hanggang sa katapusan ng na-bayar na panahong iyon.

Maaaring may refund o ang operasyon ay ma-withdraw.

Sa ilang kaso, maaaring i-withdraw ang pagbili.

Samakatuwid, hindi sapat ang simpleng “noong isang beses na nagkaroon ng pagbili” na katotohanan.

Kailangan ng server na maunawaan kung ano ang nangyayari ngayon.

Hindi nakalilimutan ang pagbawi ng pagbili

Lalong nakikita ang kahalagahan ng server-side architecture sa mga kaso ng refunds at withdrawal.

Maaaring naging tama ang orihinal na pagbili. Naibigay nang tama ang access pagkatapos ng pagbabayad.

Ngunit kalaunan, nagbago ang estado ng operasyon.

Kapag nakatanggap ang BillingMeld ng impormasyong nagbabago nito, ina-update niya ang estado ng pagbili at, kung kinakailangan, muling kinakumpirma sa tindahan.

Pagkatapos, ang nakakabit na serbisyo ay magtatrabaho na gamit ang bagong estado.

Pinapalitan nito ang patuloy na pagtitiwala ng app sa isang katotohanang nagsasabi na isang buwan o mas matagal nang nakalipas ay nag-ulat ang user ng matagumpay na pagbili.

Kung hindi na itinuturing ng tindahan ang karapatang iyon bilang valid, itinatala ito ng BillingMeld sa kanyang estado.

Ang pag-cancel ng subscription at pagtatapos ng access ay magkaibang proseso

May mahalagang pagkakaiba dito.

Kung i-disable ng user ang auto-renew, hindi nangangahulugang awtomatikong mawawalang-sayod ang access nang agad-agad.

Maaaring magpatuloy ang kasalukuyang bayad hanggang katapusan ng period.

Sa ganitong kaso, kailangang i-store ng BillingMeld ang impormasyon na naka-disable na ang renewal, ngunit sabay na kailangang maintindihan ang petsa ng pagtatapos ng bayad na period.

At pagkatapos nitong magtapos, mawawalan na ng bisa ang access maliban kung may bagong kumpirmadong renewal.

Ito ay isang halimbawa kung bakit hindi sapat ang isang simpleng boolean na subscription = true para sa maayos na billing.

Ang estado ng subscription ay laging konektado sa oras at mga event ng cycle nito.

Ang renewal ay isa pang hiwalay na pagsusuri

Hindi natatapos ang subscription sa unang bayad lamang.

Kailangang alam ng server kung may update na renewal at kung totoong na-kumpirma ito ng tindahan.

Sinusubaybayan ng BillingMeld ang mga pagbabagong ito at ina-update ang estado.

Kapag nakumpirma ang renewal, magpapatuloy ang karapatan sa access.

Kung walang nangyaring matagumpay na debit o hindi na kinukumpirma ng tindahan ang susunod na yugto, hindi dapat basta-basta mag-renew ng access nang walang batayan.

This makes the user experience more intuitive: ang access ay nananatili hanggang aktibo ang na-bayar na subscription.

Para sa mga developer, nangangahulugan ito na hindi na kailangang ulitin ang parehong proseso ng renewal sa bawat app.

Paano ang karaniwang scenario

Ang user ay nag-oorder ng subscription sa mobile app.

Nakatanggap ang client ng impormasyon sa pagbili at ipinapasa ito sa BillingMeld. Ngunit, hindi pa ito nagpapahiwatig na kumpirmadong kumpirmado na ang pagbili.

Sinusuri ng BillingMeld ang operasyon sa store.

Kung kinukumpirma ng App Store o Google Play ang pagbili at tugma ito sa rules ng produkto, itinatala ng BillingMeld ang aktibong karapatan.

Pagkatapos, nagbibigay ang nakakabit na serbisyo ng access sa user.

Ang estado ay patuloy na umaandar kahit na ang orihinal na mensahe mula sa client ay naipasa na.

Kung mag-renew ang subscription, ina-update ng BillingMeld ang estado sa bagong bayad na yugto.

Kung ia-allow ng user ang auto-renew, magpapatuloy ang access hanggang matapos ang buwanang yugto.

Kapag may refund o withdrawal, magbabago uli ang estado.

Sa ganitong paraan, ang app ay hindi nag-iimbak ng hiwalay nitong “katotohanan” tungkol sa pagbili. Nakikipag-ugnayan ito sa estado na pinatutunayan at iniimbak ng BillingMeld.

Anong nangyayari kapag nagpapalit ng device

Partikular na mapapakinabangan ang server-side approach kapag nagpapalit ang user ng phone o mag-iinstall muli ng app.

Ang karapatang magbili ay hindi dapat nakabase lamang sa isang device na nakakita ng matagumpay na transaksyon.

Sa kabilang banda, hindi dapat burahin ng reinstallation ang na-kumpirmang karapatan ng user.

Kapag ang estado ng pagbili ay nakaimbak sa server at konektado sa kumpirmadong operasyon sa store, maaaring makuha ng bagong device ang aktwal na estado sa server.

Ito ay isa pang dahilan kung bakit hindi kailangang ilagay ang lohika sa access nang eksklusibo sa mobile app.

Ano ang hatid nito sa mga developer

Para sa mga team na naglalabas ng maraming mobile apps o nagtatrabaho sa iOS at Android nang sabay-sabay, mabilis na nagiging isang infrastructure challenge ang billing.

Kailangang tukuyin ang:

• magkaibang format ng datos ng Apple at Google;

• pagsusuri sa orihinal na pagbili;

• renewal ng subscription;

• pagwawakas ng bayad na yugto;

• pag-disable ng auto-renew;

• refunds;

• withdrawal ng operasyon;

• reinstallation ng app;

• pagpapalit ng device;

• pagbawi ng mga pagbili;

Itinatataas ng BillingMeld ang lohika na ito sa isang hiwalay na layer. Ang mga server ay makikipag-ugnayan dito sa isang pangkalahatang kontrata at hindi kailangang intindihin ang bawat detalye ng bawat tindahan nang hiwalay. Ito ay nagbabawas ng duplikasyon ng code at, mas mahalaga, nagpapanatili ng pagkakatulad ng pangkalahatang pag-unawa sa mga scenario ng bayad sa iba't ibang app.

Ang pangunahing hindi na check, kundi ang aktwal na karapatan

Ang pinaka-interesado ako rito ang paglilipat mula sa simpleng pagtanggap ng check sa isang pagbili patungo sa pagkontrol sa kasalukuyang estado nito.

Hindi sapat ang makitang successful ang isang pagbili lamang; ang pangunahing tanong ay:

may karapatan ba ang user na gamitin ang bayad na feature sa kasalukuyan?

Maaaring may successful initial purchase, pero tapos na ang panahon ng serbisyo.

Maaaring naka-disable ang auto-renew, pero aktibo pa rin ang na-bayar na yugto.

Maaaring may kumpirmadong renewal, refund, o operation na na-withdraw na.

Samakatuwid, ang pinakasusi nitong hakbang ay hindi ang check o ang unang sagot ng customer kundi ang kasalukuyang karapatan ng user na nakabase sa kumpirmadong estado ng pagbili.

Ito ang estado na ipinapaalam mismo ng BillingMeld sa ibang serbisyo.

Ang BillingMeld bilang boundary sa pagitan ng store at mga produkto

Lumilitaw ang isang malinaw na arkitekturang hangganan.

Sa isang banda ay ang App Store at Google Play na may kanilang mga format, event, patakaran, at cycle ng pagbili.

Sa kabilang banda ay ang mga app at internal na serbisyo na sa karamihan ay mas nangangailangan lamang ng isang mas simple at pangunahing sagot: ano ang mga karapatang meron ang user sa kasalukuyan.

Ang BillingMeld ay nasa pagitan nila.

Natatanggap nito ang data mula sa tindahan, sinusuri, inaayos sa isang sariling modelo, at nagbibigay ng normalisadong resulta sa ibang bahagi ng infrastructure.

Sa ganitong paraan, ang mga produkto ay hindi kailangang malaman ang lahat ng internal na detalye ng bawat payment platform.

Bakit mahalaga ito para sa user

Para sa user, ang tama at mahusay na arkitekturang billing ay dapat maging di-nasisingit; nakikita lamang ito kapag may problema.

Kung ang pagbili ay kumpirmado at ang binayarang yugto ay gumagana, ang access ay dapat na gumana nang walang hindrance.

Kapag inalis ng user ang auto-renew, ang aktibong yugto ay hindi awtomatikong mawawala bago pa man ito matapos.

Kapag may bagong successful renewal, ang access ay dapat magpatuloy.

Kung ang tindahan ay nagkumpirma ng refund o withdrawal, ang system ay dapat na magrehistro ng pagbabago ng karapatan nang tama.

Sa pagpapalit ng device o muling pag-install ng app, hindi kailangang pilitin ang user na harapin ang bawat bahagi ng infrastructure upang patunayan na totoo ang pagbili.

Sa katapusan, ang simpleng rule ay: ang client ay nagsusumite ng impormasyon, ang store ang nagsisilbing panlabas na tagapagpatunay, at ang BillingMeld ang nagsusuri at naglo-normalize nito bago ipasa sa ibang serbisyo.

Binibigyang-daan nito ang mga produkto na hindi kailangang malaman ang lahat ng detalye ng bawat payment platform. Ang BillingMeld ay isang server-side trust layer na tumpak na nagsusuplay ng current rights ng user.

Para sa karagdagang impormasyon tungkol sa proyekto, bisitahin ang billingmeld.de.