WooCommerce Redsys Gateway 32.1.x

Berreskurapen honek 2.300 euroko kostua izan du. Aurten metatutako kostua 37.430 eurokoa da. Lehenengo bertsioaren metatutako kostua 236.160 eurokoa da, baina zuretzat kostua lizentzia bakarrik da 79€.

Redsys pluginaren 32.1.x adarra WooCommerce-rentzat WooCommerce.com-etik.

Adar bertsioak

• 32.1.0

32.1.0

Berria:

• WooCommerce-ren egoera txostenak (WooCommerce – Egoera) orain Redsys-en “Ajustes avanzados” fitxan aktibatuta dagoena ere zerrendatzen du: push jakinarazpenak, faktura sekuentzialak, QR kodeak, gordetako txartelak, eskaeren egoerak gainditzea, baldintza arauak, harpidetzak, posta elektroniko bidezko kontabilizazioa, merkataritza agenteen protokoloak eta kudeaketa aplikazioaren APIa. Kredentzialak inoiz ez dira inprimatzen: bakoitzari soilik konfiguratu den ala ez adierazten zaio. Txostena laguntzera bidaltzeko kopiatzean sartzen da, zehazki hori da helburua: laguntza eskaera konfigurazioarekin iristen da.
• Orain erabaki dezakezu zure bezeroei “Gordetako kreditu-txartela gehitu harpidetzetarako” eskaintzen zaien ala ez, Nire kontua – Ordainketa metodoak atalean. Orain arte aukera hori bakarrik agertzen zen aktibatuta zegoen harpidetza plugin bat zegoenean, kendu gabe, eta hori ez da denda guztiek nahi dutena: harpidetzako txartela beti erosketa prozesuan jasotzen den denda batean, bezeroa txartela gordetzera gonbidatzen zuen, inoiz kobratuko ez zen txartela. Orain Redsys – Ajustes avanzados – Gordetako txartelak atalean aktibatuta dago, denda horiek eskaintzen jarraitzeko, eta desaktibatuz gero, 1-click txartela bakarrik geratzen da. WooCommerce-ren egoera txostenean ere informatzen da.

Segurtasuna:

• Pluginak bere log fitxategian “eskaera jaso” orriaren helbidea idazten zuen, ordainketa guztietan, eta helbide horrek eskaeraren giltza du: WooCommerce-k eroslearen ordainketa loturan jartzen duen testigantza pribatua eta plugin honek eskaera bat erakutsi aurretik eskatzen duena. Log fitxategian irakurtzeko sarbidea duen edonork, beraz, eskaera horiek ireki eta izena, posta, telefonoa eta helbideak ikusi zitzakeen. Hori gertatzen zen denda batean depurazio loga aktibatuta egon ala ez, puntu zehatz horrek logean idazten zuen egiaztatu gabe. Orain depurazio egokitzapena errespetatzen du pluginak idazten dituen log guztietan, eta giltza “[redacted]”-rekin ordezkatzen da ezer idazten aurretik, beraz, logean ez da inprimatzen, loga aktibatuta egon arren. Ordezkapen hori pluginaren log lerro guztietan aplikatu da, eta ez bakarrik salatu zen lerroan: ia ehun lerro gehiago pasareletan zehar idazten ziren, depurazio loga aktibatuta zegoenean, bankuari bidalitako mezua osorik islatzen zutenak barne. Jadanik idatzitako log fitxategiek helbide horiek jarraitzen dituzte: badituzu, ezabatu.
• Erabiltzaileari Redsys-era (eta Bizum-era) birbidaltzen dion orriak eskaera zenbaki bat idazten zuen bere helbidean, eskaera hori egin zuen pertsona izan zen ala ez egiaztatu gabe. Eskaera zenbakiak sekuentzialak direnez, norbaitek horiek zeharkatu eta pluginak bankuari bidaltzen dizkion bestelako bezeroen eskaeren datuak irakur zitzakeen: izena, posta, telefonoa eta fakturazio eta bidalketa helbideak, zenbatekoa eta erositakoaren deskribapena. Inola ere ez zen txartel zenbaki bat, segurtasun kode bat edo sinadura giltzarik agerian jarri, eta bide horretatik ez zen ezer ordaindu edo aldatu zitekeen. Orain orriak WooCommerce-k eroslearen ordainketa loturan sartzen duen eskaeraren giltza eskatzen du, beraz, eskaera bat ez den eskaera bat jasotzen denean, “Forbidden” orri batekin erantzuten da, eta ez da atenditzen. Erosketa orriaren ordainketa leihoan ere egiaztapen bera gehitu da. Tivify (TVUP Streaming Media) segurtasun taldeak salatu zuen, arazoa argi deskribatu zuen eta publiko egin aurretik zuzentzeko denbora eman zigun. Eskerrik asko.
• Eskaera pantailako hiru baimena aurreko botoiek (baimena, ezeztatu eta zati bat kobratu) eta PayGold-en bezeroen bilaketak segurtasun testigantzarik gabe onartzen zuten. Baimen egiaztapena bere tokian zegoen, beraz, denda kudeatzaile edo administratzaile batek bakarrik erabil zitzakeen eta inork ez zuen exekutatu ahal izango, baina saioa irekita zuen administratzaile bat engainatu zitekeen beste web batetik abiarazteko. Orain lauak WordPress-en segurtasun testigantza bat eramaten eta egiaztatzen dute, bide hori itxiz.
• Merkataritza Agenteen Protokoloa aktibatuta amaitu zitekeen inork aukeratu gabe, automatikoki eguneratzen diren dendetan. Makinek hitz egiteko helbideak argitaratzen ditu, beraz, desaktibatuta egon behar du, zuk aktibatu arte, eta orain desaktibatuta dago. Aktibatuta bazenu, ez da ezer aldatzen zuretzat.
• Pluginaren barnean Google liburutegia eguneratu da, sareko eskaerak egiten dituen atalean bi akats zuzentzen dituena.

Eguneratuta:

• Harpidetzaren berritze bat huts egiten duenean, eskaerari gehitzen zaion oharrak orain zehazki zein pausok huts egin duen eta zein merkataritza kode eta terminalekin egin den saiakera adierazten du. Orain arte, posible ziren sei hutsak oharraren berdina idazten zuten, informazio gutxirekin, eta horrek ia ezinezkoa egiten zuen denda batera sarbiderik gabe huts egin duen berritze bat diagnostikatzea, bereziki loga idazten ez den dendetan.
• Apple Pay-k denda Apple-rekin balidatu ezin duenean, logak orain Apple-ren azalpena eta ziurtagiriaren fitxategiak irakur daitezkeen adierazten ditu. Apple-k “Expectation Failed” generikoa erantzuten du eta benetako arrazoia bere erantzunaren gorputzean jartzen du, inola ere logatu ez zen, beraz, huts horiek irteera bat izan ziren.
• Banatutako pluginak ez ditu jadanik proiektuaren garapen eta konpilazio scriptak, probako ingurune konfigurazioa, editore eta git hook direktorioak, garatzaileentzako README-a eta segurtasun berrikuntza dokumentu bat. Horiek guztiak ez ziren kargatu pluginak exekutatzean, baina ez dute denda baten zerbitzarirako baliorik. Orain paketean dagoen guztia automatikoki egiaztatzen da, argitalpen bakoitzaren aurretik, pluginak benetan banatzen duenaren zerrenda baten aurka, beraz, etorkizunean proiektuan gehitzen den ezer zip barruan bidaiatu ezin du inork konturatu gabe.
• Posta elektronikozko kontabilizazio lanak orain funtzio hori aktibatuta dagoen bitartean bakarrik existitzen da, eta behin bakarrik. Aurretik denda guztietan sortzen zen eta bost minutero esnatzen zen ezer egin gabe.
• Itzulpen guztiak berriro osatu dira. Azken bertsioek gehitutako berrogeita bederatzi testu ingelesez agertzen jarraitzen zuten: doikuntzen etiketak, egoera txostena eta erosle batek ikus ditzakeen mezu batzuk. Espainiera, katalana, euskara, galego, frantsesa eta portugesa ehuneko ehunean daude berriro.
• “Txartela gehitu” lotura babesteko testigantza orain denbora konstantean alderatzen da, plugin honek alderatzen dituen gainerako sekretuekin. Interneten bidez alderaketa horren denbora neurtzea ez da erasorik praktikoa, beraz, ezer ustiatzeko ez zen ezer; akatsa desberdintasuna zen, izan ere, hau zen sinadura lanetan beste guztiak migratu ziren bitartean atzean geratu zen alderaketa bakarra.

Konpondu:

• InSite-rekin, erosleak gordetako txartel batekin ordaintzean dirua kobratu zitekeen eta hala ere eskaera huts gisa agertzen zen. Bankuak ordaintza hori onartzen duenean erosleari bere banku aplikazioarekin baieztatzeko eskatzen ez dionean, gordetako txartel batekin gertatzen dena, pluginak emaitza okerrean bilatzen zuen, ezer ez aurkitzen eta “ezer” hori ukatutzat jotzen zuen. Karga jadanik egin zen, beraz, ordaintzen zela esaten zitzaien erosleei bigarren aldiz ordaintzen zitzaien eta bi aldiz kobratzen zitzaien. Emaitza orain bankuaren sinatutako erantzunaren beraren irakurtzen da, ordainketa gainerakoan erabiltzen dena. Hori klasiko eta blokeetako checkout-ei eragiten zien, eta baita harpidetzaren berritzei ere. Bi denda desberdinek salatu zuten, egun gutxiren artean, horietako batek lerro zehatzera jarraitu zuen. Eskerrik asko.
• Txartel pasarekan, gordetako txartel batekin egindako ordainketa baimenduta ematen zen baimena zenbakia bakarrik, bankuaren benetako erantzuna ondoan egiaztatu gabe. Huts egin zuen ordainketa, hala ere, horretan zerbait egon zitekeenak eskaera ordainduta markatzen zuen, eta denda salgaiak bidaltzen zituen kobratuta izan gabe. Orain biak bat etorri behar dira eskaera bat osatzeko. Bankuaren erantzuna guztiz falta bada, ordainketa ez da osatzen, ez dagoelako onartua izan zela esaten duen ezer; bankuak benetan horretan huts egiten duen denda batek aurreko portaera berreskuratu dezake redsys_allow_payment_without_ds_response iragazkiaren bidez, dokumentatua eta bankuak ukatutako ordainketa bat onartzeko erabili ezin dena.
• Harpidetzaren amaiera prozesatzeko zenbait plugin erabiltzen dituzten dendetan, Fluid Checkout barne, ordainketa guztiak Redsys-ek SIS0574 akatsarekin ukatzen zituen. Bankuak eroslearen nabigatzailearen deskribapen labur bat eskatzen du ordainketa bakoitzean (bere hizkuntza, pantailaren tamaina eta antzekoak), pluginak checkout-ean gehitzen dituen ezkutuko eremuak erabiliz. Eremu horiek txartel pasarela eraikitzen den momentuan gehitzen ziren, denda horietan WooCommerce-k checkout-eko eremu zerrenda definitiboa eskatzen duen momentuan, eta WooCommerce-k zerrenda hori behin bakarrik eraikitzen du eta ez gehiago. Beraz, eremu horiek ez ziren sortzen, ez ziren betetzen eta ez ziren bidaltzen, eta bankuak ordainketa ukatzen zuen. Orain pluginak kargatzen denean gehitzen dira, inork zerrenda eskatzen hasi aurretik, eta horrek behar duten pasareletako guztiei eragiten die, txartela, Bizum eta walletak, eta ez InSite-ri bakarrik. InSite-n nabigatzailearen deskribapena orain ordainketa datuen gainerakoarekin bidaltzen da, eskaeraren menpe egon beharrean, beraz, auto-berregituratzen den checkout batean iraun dezake. Diagnostikoa frogatuta ekarri zuen integratzaile batek salatu zuen. Eskerrik asko.
• Ordainketa bat ezeztatzen edo ukatzen bazen, eroslea dendara itzultzen zen baina eskaera pendente geratzen zen eta saskia berreskuratu gabe. Pluginak bankuari eroslea itzultzeko ematen zion helbidea web orri baten barruan loturak egiteko erabiltzen den moduan idatzita zegoen, benetako helbide bat erabiltzen den moduan ez, beraz, denda itzulera jasotzen zuen eskaeraren erreferentziarik gabe, bere zenbakirik gabe eta segurtasun testigantzarik gabe, eta ezer ezeztatzeko ez zuen ezer. Bizum, Google Pay, Apple Pay, banku ordainketa, transferentzia, InSite eta txartel pasarela eragiten zion, “itzuli” ezarpenak eskaera ezeztatzeko jarrita zegoenean. MasterPass-en helbide hori zuzenean hutsik bidaltzen zen, karaktere bakar baten idazketa akats batengatik hiru lerroetan errepikatuta. Orain dena kode zati bakar baten bidez pasatzen da, beraz, etorkizunean gehitzen den pasarela batek ez du berriro akatsik egingo.
• Modal moduan ordainketa prozesatzerakoan, ordainketa ezeztatzeak ezer ez egiten zuen eta eroslea saskian geratzen zen eskaera pendentearekin. Pluginak nabigatzaileari bidaltzen zion helbidea orri batean idatzita zegoen, nabigatzaileak dokumentu baten barruan lotura gisa interpretatzen duen moduan, eta lehen parametroaren ondoren doan guztia baztertzen zen: eskaeraren erreferentzia, bere zenbakia eta segurtasun testigantza desagertzen ziren, eta WooCommerce-k ezer ezeztatzeko ez zuen ezer. Akats berbera eragiten zuen erosleari ordainketa egin ondoren itzultzen zaion helbidean, non jarraipen parametro bat isilean galtzen zen. Biak konpondu dira, txartel pasarekan eta InSite-n, eta konpondu den portaera benetako nabigatzaile batean egiaztatu da.
• Checkout-ak akats kritiko batekin hil zitekeen, eroslea bankura bidali beharrean, bezero erregistratu batekin, bere bezero fitxan inoiz aldaketarik egin gabe. Pluginak bankurako segurtasun datu multzo bat eraikitzen du ordainketa bakoitzean, eta horietako bat bezeroaren kontua azken aldiz noiz aldatu zen data da, WooCommerce-k inoiz ukitu ez den kontu batean hutsik uzten duena, normalean inportazio, migrazio edo beste plugin batek automatikoki sortutako kontua. Pluginak data huts hori data benetako gisa irakurtzen zuen eta ordainketa orria bertan gelditzen zen. Orain kontuaren sortze data erabiltzen du, “inoiz aldatu gabe” esan nahi duena, eta segurtasun berme hori gehitu da harpidetzak erabiltzen dituzten kode baliokideetara, non data huts hori isilean bankura “egun honetan aldatu” gisa jakinarazten zen, informazio okerra bere iruzurraren kontrolerako.
• Redsys eta gainerako pasarelak checkout-ean desagertu zitezkeen denentzat, normalezko erosleak barne, denda horietan probako moduan “erakutsi soilik erabiltzaile hauei” zerrenda inoiz bete ez zenean. Pluginak ezarpen huts hori irakurtzen zuen “erakutsi erabiltzaile bati, id-a ezer”, inork ez baitzuen bat etortzen, beraz, ordainketa metodoa bisitari guztientzat ezkutatuta geratzen zen. Hori bakarrik eragiten zuen

• Denda batzuk, konfigurazioak ez ziren ezarpen pantailatik, inportazio batetik, migrazio batetik edo pluginaren kudeaketa APItik idatzita, balio huts bat gordetzen zuten, eta hori ez zen inoiz gertatzen. Hori konpondu da kode bera partekatzen zuten bederatzi pasareletan.
• Apple Pay edo Google Pay bidez ordaindutako harpidetzak, konturik ez zuen bezero batek, bankutik ez zuen inoiz baimenik jasotzen, beraz, lehen berritzeak huts egiten zuen txartelik ez zegoela esanez. Hori gertatzen zen