Idempotentzia ordainketetan: nola saihestu birsaiaketen eta webhook bikoitzen ondoriozko kobrantza bikoitzak

Merkataritza digitalean, sare-konexioek huts egiten dute ezinbestean. Bezeroak checkout gunean ordaintzeko botoia sakatu, nabigatzaileak agindua bidali eta ordainketa-pasabideak zordunketa arrakastaz prozesatzen du; hala ere, konexioa erantzuna nabigatzailera iritsi baino milisegundo bat lehenago eten daiteke. Ziurgabetasunaren aurrean, erabiltzaileak berriro klik egiten du edo backendak deia automatikoki birbidaltzen du. Sistemak babes-mekanismorik ez badu, bigarren dei horrek bigarren transakzio berdin bat sortuko du.

Arazoa biderkatu egiten da jakinarazpen asinkronoak jasotzean. Ordainketa-hornitzaileek birsaiatze-sistemak erabiltzen dituzte gertaeren entrega bermatzeko. Saltzailearen zerbitzariak HTTP arrakasta-kode batekin erantzuten denbora gehiegi behar badu, pasabideak jakinarazpena berriro bidaliko du minutu batzuk geroago. Integrazio sendo bat diseinatzeko, ezinbestekoa da idempotentzia zer den ulertzea eta bai irteerako eskaeretan bai sarrerako gertaeren kudeaketan nola aplikatu jakitea.

Zer da idempotentzia eta zergatik da hain garrantzitsua ordainketetan

Matematikan eta konputazio-zientzietan, eragiketa bat idempotentea da parametro berberekin jarraian zenbat aldiz exekutatzen den kontuan hartu gabe emaitza bera sortzen badu. Lineako ordainketen testuinguruan, kobratzeko agindu bera hamar aldiz bidaltzeak transakzio ekonomiko bakarra eta hamar erantzun berdin sortu behar dituela esan nahi du.

Idempotentziarik gabe, komunikazio-akatsek berehalako marruskadura sortzen dute. Ondorioak ez dira eroslearen haserrera mugatzen: kobrantza bikoitz batek ezusteko banku-komisioak eragiten dizkio saltzaileari, eskuzko laguntza-kudeaketak sortzen ditu eta, askotan, itzulketak eta chargebackak ekartzen ditu, txartel-sareen aurrean negozioaren ospea kaltetuz.

Idempotentzia-gakoak irteerako eskaeretan

Saltzailearen zerbitzaria API bidez ordainketa-pasabidearekin komunikatzen denean kobrantza bat bideratzeko, ohiko teknikak HTTP goiburu espezifiko bat bidaltzea eskatzen du, identifikatzaile esklusibo batekin batera; horri idempotentzia-gakoa (`Idempotency-Key`) esaten zaio.

Lan-fluxu estandarrak urrats hauek jarraitzen ditu:

• Jatorrian sortzea: kobrantza-eskaera bidali aurretik, saltzaileak identifikatzaile bakar bat sortzen du (normalean 4 bertsioaren UUID bat), erosteko asmoari edo saskiaren barne-identifikatzaileari lotuta.
• Erregistroa pasabidean: eskaera jasotzean, pasabideak egiaztatzen du gako berarekin aldez aurretik eskaerarik prozesatu ote den epe jakin batean (normalean 24 eta 48 ordu artean).
• Gordetako erantzuna errepikatuz gero: gakoa lehendik badago eta jatorrizko eragiketa amaitu bada, pasabideak ez du kargu berririk egiten txartelean. Horren ordez, lehen aldian sortu zuen erantzun zehatza itzultzen du, egoera bera eta transakzio-identifikatzaile bera mantenduz.
• Konkurrentziaren kontrola: gakoa erregistratuta badago baina aurreko eragiketak martxan jarraitzen badu, pasabideak aldi baterako errore bat edo konkurrentzia-blokeo bat itzultzen du lasterketa-baldintzak saihesteko, bezeroari itxaron dezala adieraziz.

Mekanismo honek bikoizketak saihesteko ardura prozesatze-geruzara eramaten du, sare-akatsen edo denbora-mugen aurrean azpiegituraren birsaiaketa automatikoek kargu bikoitzik ez sortzea bermatuz.

Bikoiztutako webhookak kudeatzea saltzailearen zerbitzarian

Idempotentziak ez du norabide bakarrean jarduten. Irteerako eskaerek kobrantzaren sorrera babesten duten bitartean, saltzailearen backendaren barne-prozesamenduak babes berdinak behar ditu webhook bidez gertaeren jakinarazpenak jasotzean.

Ohiko akats bat da jasotako webhook bakoitzak gertaera bakar bat adierazten duela pentsatzea. Praktikan, sare banatuek gutxienez behin entregatzeko semantikak aplikatzen dituzte (*at-least-once delivery*). Horrek esan nahi du gertaera bat bi edo hiru aldiz entregatu daitekeela latentzia-arazoengatik edo igorlearen birsaiaketengatik. Sinatutako webhookak eta txartel-datuak prozesatzean gertatzen den bezala, hartzaileak mezuaren benetakotasuna zein berezitasuna balioztatu behar ditu.

Gertaerak jasotzean idempotentzia ziurtatzeko, datu-basean eredu hau aplikatzea komeni da:

• Gertaera-identifikatzailea gako bakar gisa: pasabideak igorritako gertaera bakoitzak identifikatzaile aldaezin bakar bat du. Saltzaileak identifikatzaile hori prozesatutako gertaeren taula batean gorde behar du, gako primarioaren edo indize bakar baten murrizketarekin.
• Datu-baseko transakzioak: gertaera-identifikatzailea txertatzea eta eskaera eguneratzea (adibidez, ordainduta gisa markatzea eta stocka askatzea) datu-baseko transakzio atomiko beraren barruan gertatu behar dira.
• Bikoiztuak baztertzea errorerik itzuli gabe: datu-baseak gako-bikoiztasunagatik txertaketa baztertzen badu, zerbitzariak geroko merkataritza-ekintzak bertan behera utzi behar ditu (bidalketa edo kontuko kreditu bikoitzak saihestuz) eta pasabideari HTTP 200 kode batekin erantzun behar dio berehala. Errore-kode bat itzuliko balitz, pasabideak entregan hutsegite bat gertatu dela interpretatuko luke eta bidalketa birsaiatzen jarraituko luke.

Blokeo baikorrak eta eskaeraren egoerak

Konkurrentzia handiko inguruneetan, checkout-aren erantzun sinkronoa eta webhook asinkronoa backendera ia aldi berean irits daitezke. Bi prozesuek produktuaren entrega edo fakturaren sorkuntza aldi berean exekutatu ez dezaten, online ordainketen arkitekturak egoera-makina zorrotzak izan behar ditu.

Eskaera «prozesatua» edo «ordaindua» egoeran badago jada, kobrantza beretik abiatuta egoera aldatzen saiatzen den ondorengo edozein prozesu modu garbian gelditu behar da. Blokeo baikorrak (eguneratu aurretik erregistroaren bertsio-zenbaki bat egiaztatuz) edo datu-basearen mailako blokeo ezkorrak erabiltzeak eragozten du bi hari paralelok betetze-logika aldi berean exekutatzea.

Hutsegiteei aurre egiteko jardunbide egokiak

Transakzio-koherentzia bermatzeak irmotasuna eskatzen du sistemaren geruza guztietan. Eskaeratik eratorritako identifikatzaile deterministak ezartzea komeni da, nabigatzailearen ustekabeko freskatze batek backendarekin harremanetan jarri aurretik UUID berri bat sor ez dezan. Era berean, funtsezkoa da eragiketa kritikoak lan-ilaratan bakartzea, eskaerako prozesamendu sekuentzialarekin.

Idempotentzia ez da alferrikako optimizazio bat, baizik eta fakturazioak eta kobrantza-operatibak informatika-sareen ezinbesteko akatsen aurrean zehaztasuna mantentzeko beharrezko oinarria.