Zer da entitlement bat eta zergatik kudeatu behar den zerbitzarian eta ez mugikorrean

Softwarearen eta mugikorreko zerbitzuen garapenean, sarbide digitala saltzea eta hura ematea sarritan nahastu egiten dira. Erabiltzaile batek ordainketa burutzen du App Store-n, Google Play-n edo webgunean, gailuak berrespena jasotzen du eta, berehala, pantailak ordainpeko funtzioa desblokeatzen du. Hala ere, erosketa-agiria telefonoaren interfazearekin zuzenean lotzeak akats operatiboak eta segurtasun-arazoak eragiten ditu etengabe. Banaketa hori behar bezala kudeatzeko entitlement kontzeptua erabiltzen da.

Kontzeptu horrek zer esan nahi duen eta baimenak zure zerbitzarietan zergatik kalkulatu eta gorde behar diren ulertzea ezinbestekoa da pagos en apps kudeatzen dituen eta negozio-eredu errepikakor fidagarria bilatzen duen edozein enpresarentzat.

Zer da zehazki entitlement bat

Entitlement bat (edo sarbide-eskubidea) erabiltzaile jakin batek plataforma batean eginbide, eduki edo zerbitzu-maila jakin batez gozatzeko duen baimenaren adierazpen logikoa da, epe jakin batean indarrean dagoena.

Ez da nahastu behar produktu komertzialarekin edo eragiketa ekonomikoarekin:

• Produktua edo SKUa: Aplikazio-dendetan edo checkout katalogoan argitaratzen den elementua da (adibidez, `suscripcion_anual_pro`).
• Transakzioa edo ordainagiria: Dendak edo ordainketa-pasabideak kriptografikoki sinatutako egiaztagiria da; kobrantza ondo burutu dela edo proba-aldi bat hasi dela ziurtatzen du.
• Entitlement-a: Zure sistemak transakzio horietatik ateratzen duen ondorio operatiboa da. Esate baterako, `acceso_modulo_analitica` barne-etiketa, urriaren 15eko 23:59an iraungiko dena.

Produktu komertzial bakar batek hainbat entitlement independente eman ditzake; era berean, hainbat produktu desberdinek (iOSen kontratatutako hileko plan batek eta banku-transferentzia bidez fakturatutako enpresa-plan batek) entitlement berbera eman dezakete.

Baimenak gailuan bertan ebaztearen arriskuak

Urte askotan zehar, mugikorreko aplikazio askok erosketen baliozkotzea bezeroan bertan egin zuten: app-ak dendaren ordainagiri kriptografikoa jasotzen zuen, sistema eragilearen liburutegiekin lokalean egiaztatzen zuen eta aldagai boolear bat (adibidez, `isPro = true`) gordetzen zuen gailuaren memorian.

Eredu horrek ahultasun tekniko eta komertzial nabarmenak dakartza:

• Exekuzio-ingurunea manipulatzea: Root edo jailbreak duten gailuetan, azterketa dinamikorako tresnekin memoria-aldagaiak edo erantzun bitarrak aldatzea oso erraza da. Baimena ematea tokiko aldagai baten mende badago, aplikazioa desblokeatu daiteke ordaindu gabe.
• Errepikapen-erasoak (receipt replay): Kontu baterako emandako baliozko ordainagiri bat atzeman eta beste erabiltzaile baten app-era bidal daiteke. Bezeroak ez badu egiaztapenik egiten transakzio-identifikatzailea erabiltzaile autentifikatu jakin bati lotzen dion zerbitzari baten aurka, ordainagiri bakarrak dozenaka lagunentzako zerbitzua desblokeatu dezake.
• Plataforma anitzeko koherentzia eza: Baimena mugikorrean bakarrik badago, bere iPhonean harpidetza ordaindu duen erabiltzaile batek ezin ditu funtzioak erabili webean edo Android tableta batean saioa hasten duenean. Horrek erosketak bikoiztera behartzen du edo bezeroarentzako arreta-zerbitzuan kexak sortzen ditu.

Arkitektura banatua: zerbitzaria egiaren iturri bakarra da

Negozio-eredua babesteko, mugikorreko bezeroak ez du inoiz erabaki behar zein funtzio dauden erabilgarri. Mugikorraren zeregina ordainketa-interfazea erakustea, lortutako ordainagiria backend-era bidaltzea eta baimen aktiboak zerbitzariari galdetzea izan behar da.

Lan-fluxu seguruak urrats hauek jarraitzen ditu:

1. Erabiltzaileak erosketa-prozesua burutzen du mugikorreko aplikazioan.

2. Aplikazioak dendaren (App Store edo Google Play) token edo ordainagiri sinatua jasotzen du eta konexio zifratu baten bidez zure zerbitzariaren APIra bidaltzen du.

3. Zure backend-ak zuzenean jotzen du dendaren baliozkotze-API ofizialetara, ordainagiria benetakoa eta indarrean dela ziurtatzeko, eta transakzio-identifikatzailea lehenago beste kontu batek erabili ez duela egiaztatzeko.

4. Egiaztapena positiboa bada, zerbitzariak entitlement erregistroa sortu edo eguneratzen du bere datu-basean, zure plataformako erabiltzaile-identifikatzaile bakarrari lotuta.

5. Zerbitzariak indarrean dauden baimenen zerrenda bateratua itzultzen dio app-ari.

Eskema horren bidez, babestutako baliabideetara edo datuen sinkronizaziora jotzen duen edozein eskaerak entitlement-a zuzenean baliozkotu behar du backend-ean informazio sentikorra bidali aurretik.

Bizi-zikloaren kudeaketa eta gertaera asinkronoak

Harpidetza modernoak ez dira estatikoak. Denboran zehar egoera askotatik igarotzen dira: berritzeak, baztertutako txartelen ondoriozko grazia-aldiak, aldi baterako etenak, bertan behera uzteak eta itzulketak.

Logika gailuan bertan geratzen bada, app-ak aldizka galdetu beharko lieke dendei txartelak balio duen edo erabiltzaileak Apple edo Google-ren bidez itzulketarik eskatu duen. Horrek atzerapenak eta bateriaren nahiz datuen alferrikako gastua dakar.

Eskubideak zerbitzarian zentralizatzean, banaketa-plataformek eta ordainketa-prozesadoreek denbora errealean jakinarazten dituzte aldaketak, zerbitzarien arteko mezuen bidez edo webhooks firmados y datos de tarjeta que no debes guardar erabiliz. Kobrantza batek huts egiten duenean, renovación automática de suscripciones prozedurak aplikatzen dira; zure backend-ak berehala erabaki dezake entitlement-a adeitasun-egun batzuetan mantendu ala kontua oinarrizko planera jaitsi, aplikazioa dendetan eguneratu beharrik gabe.

Ondorio praktikoa

Erosketa transakzio-gertaera gisa hartzea eta entitlement-a sarbide-eskubide baten emaitza den egoera gisa kudeatzea da aplikazio jasangarriak eta eskalagarriak garatzeko modu fidagarri bakarra. Logika hori backend-ean mantentzeak iruzurraren aurka babesten du irabazia, bezeroen esperientzia bateratzen du ordaindu duten kanala edozein dela ere, eta itzulketei nahiz baja-eskaerei berehala eta zehaztasunez erantzuteko aukera ematen du.