Bertsio honen garapenak 2.800 euroko kostua izan du. Aurten metatutako kostua 13.350 eurokoa da. Lehen bertsioaren hasieratik metatutako kostua 212.080 eurokoa da, baina zuretzat kostua da lizentzia bakarrik 79€.
WooCommerce-ren Redsys pluginaren 31.0.0 bertsioa WooCommerce.com.
31.0.0
Berria:
- A2A (Agent2Agent) protokoloaren azalera berria. Aukerakoa eta lehenetsita desgaituta. Agent Card bat argitaratzen du /.well-known/agent-card.json-n eta JSON-RPC 2.0 amaiera bat /wp-json/wc-redsys-a2a/v1/rpc-n zazpi gaitarekin: query_payment_status, create_payment, capture_payment, refund_payment, list_payments, tokenize_card eta recurrent_charge. Autentifikazioa UCP-ren OAuth 2.1 + PKCE baimena erabiltzen du a2a:payments:* (eta WP_DEBUG azterketarako aukera bat) eskatuz.
- Server-Sent Events stream-a /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream-n bizitzako eguneratzeetarako, Last-Event-ID bidez berreskuratzeko eta 15 segundoko bihotz-txartelak (heartbeats) izateko.
- Bezeroak erregistratutako push_url batera sinatutako push jakinarazpenak. X-A2A-Signature burua: sha256=<hmac> <timestamp>.<body> gainean, 1m/5m/30m/2h (maximo 4) berriz saiatu, Action Scheduler bidez entregatuta.
- Redsys Aurreratua -> Agentic Commerce barruan 'A2A (Agent2Agent)' administrazio fitxa berria, Egoera / Bezeroak (sortu / baliogabetu / sandbox bearers biratu) / Muga eta moduak (max_amount, sensitive_threshold eta ordainketa moduak) / Berrespenak (ordainketak edo errepikaketen karguak onartzea input-required-en).
- Gaititako muga: max_amount muga zorrotza da, eta lanak limit_exceeded errorearekin amaitzen du; sensitive_threshold lanak input-required-en gelditzen da administratzaile batek berretsi arte. Biak mugarik gabe daude lehenetsita (aukera).
- Audit log-a soilik gehituta (append-only) wp_redsys_a2a_audit_log-en. Inprimakiak ez dira inoiz gordetzen: SHA-256 hash bat eta PAN, token, sekretu eta emailen tokiko zatia ezkutatzen duen lerro bat baino ez.
- Auto-berreskuratzeko biltegiratzea. A2A-ko lau taulak eskaeraren arabera sortzen dira ensure_table() bidez, beraz, taula bat ezabatzeak ez du inoiz errore larria eragiten.
- IA erosteko agenteen laguntza (ChatGPT, Claude, Gemini, Perplexity eta beste batzuk). IA agenteek orain zure produktuak aurkitu, saskiak sortu, ordainketak osatu eta zure dendetako eskaeren eguneratzeak jaso ditzakete. OpenAI/Stripe-ren ACP estandarra eta Google, Shopify eta beste batzuek babestutako UCP estandar irekia biak aktibatu edo desgaitzeko aukera dago.
- Redsys Aurreratuko ezarpenetan 'Agentic Commerce' azpialde berria, funtzio bakoitzeko etengailuak (saskiak, deskontuak, betetzeak, eroslearen onespena, bezeroen erregistro dinamikoa, etab.) eta agenteen aurkikuntza, OAuth eta webhook fluxuak probatzeko botoi bat.
- Webhooks sinadura 'Sinadura gakoa biratu' botoi batekin. Biratutako gakoek 7 eguneko balioa dute integrazioek aldaketa bitartean funtzionatzen jarraitzeko.
- Express (Apple Pay / Google Pay) modalaren pertsonalizatutako eremuak orain ere Blocks API bidez erregistratutako eremuak jasotzen ditu klasikoak diren checkoutetan, beraz, NIF/DNI eta antzeko eremuak beti agertzen dira erabiltzen duzun checkout-ean.
- Aukerako 'Aprobatzea aurreordainketa' ekintza masiboa eskaeren zerrendarako (Redsys Bideratzea). Lehenetsita desgaituta segurtasunarengatik; aktibatu pasareta ezarpenetan, aurreordainketa masiboa behar baduzu.
Oharrak:
- Edozein laguntza aktibatzeak ez du esan nahi IA laguntzaileek zure dendan erosketa osatzen hasiko diren lehen egunean. Agenteen gidatutako checkout fluxua oraindik ez da ezarri, batez ere Europan, non SCA/3DS, PSD2 eta RGPD onarpenaren eskakizunek gehieneko agenteak produktu aurkikuntzan edo aurre-saskian gelditzen diren eta azken ordainketa bezeroari itzultzen dioten. Zure denda prest dago egun bakoitzean agente bakoitzak zure merkatuan fluxu osoa aktibatzeko.
Eguneratuta:
- Express modalaren pertsonalizatutako eremuak orain bere konfigurazioa kargatzean aurrez kargatzen du eta Apple Pay abiarazten du klik egitean sinkronoki, iOS Safari-k ordainketa orria eteteko kasuak zuzentzen ditu.
- Produktuen orrialdean Express pertsonalizatutako eremuak modal lehenetsira itzultzen dira. 30.4.1ean sartutako lineako inprimakiak orain aukera da filtro baten bidez.
Konpondu:
- [Kritikoa] Harpidetzaren berritzeek Redsys SIS0502 errorearekin porrot egin dezakete ('Id Oper ez da bat etortzen') Redis, Memcached edo beste objektu iraunkorreko cachekin dituzten hosteetan. Bi berritze lan paraleloek bi eskaera erreferentzia desberdin bidali ditzakete Redsys-i harpidetza berberarentzat, beraz, berritzeak porrot egiten du eta askotan berriro saiatu behar da. Ordainketa bikoitzaren blokeoa eta eskaera erreferentzia orain fidagarri gorde dira cache atzealdearen arabera. Bideratze eta InSite Redsys pasaretei eragiten die.
- InSite-ren harpidetzaren berritzeek ez zuten inolako lehiaketa babesteko (blokeoa akatsetan ezabatzen zen baina inoiz ez zen sortzen). Orain InSite-ren berritzei bideratze pasareta erabiltzen duen lehiaketa babesa aplikatzen zaie.
- Checkout-ean erabiltzen den cacheatutako barne egoera (3DS datuak, gordetako txartelaren identifikatzailea, sinadura cachea, OAuth egoera, IMAP egoera aldi baterako, etab.) orain gorde egiten da objektu iraunkorreko cachekin dituzten hosteetan funtzionatzen duen moduan. Lehen, cacheek gaizki jokatzen zutenean, egoera hau isilean desagertu zitekeen checkout-ean eta SIS0502 erroreak eragin zitzakeen.
- Express Apple Pay eta Google Pay botoiek (blokeen checkout eta produktuen orrialdea) 'Must create a new ApplePaySession from a user gesture handler' errorearekin porrot egiten zuten iOS Safari-n Express pertsonalizatutako eremu modalak aktibatuta zegoenean. Modalak ez du erabiltzailearen klikaren kontsumorik egiten Apple Pay abiarazteko aurretik.
- Autónomos Premium-en IRPF gaizki kalkulatzen zen Express Ordainketan (Apple Pay / Google Pay) produktuen orrialdean bezeroak Express modaleko erabiltzaile mota hautatzen zuenean, modalaren gordetzea Apple Pay zerbitzariaren lehen deiarekin lehiatzen zelako. Erabiltzaile mota orain Express Pay eskaera bakoitzean bidaltzen da, beraz, totala beti zuzena da.
- Produktu birtualak dituzten produktuen orrialdeetan, Apple Pay orriak laburpen zuzena (subtotala + zerga) erakusten zuen eta ondoren produktuaren preziora itzultzen zen zergarik gabe. Bidalketa callback-ak orain zerbitzariak itzuli duen azken totala mantentzen du.
- Agentic Commerce ezarpenak gordetzean 'Aldaketak gorde' bidalketa isilean baztertzen zen WooCommerce-ren HTML inprimaki anidatuen erruz. Ezarpen orria berrantolatu da eta ekintza bakarreko botoi guztiak (aurkikuntza probatu, OAuth probatu, webhook ekintzak, etab.) orain funtzionatzen dute 'Gorde' botoi nagusiaren ondoan.
- Produktuaren orrialdean Apple Pay eta Google Pay Express botoiek bidalketa zona okerra esleitzen zuten bezeroaren eskualdea probintzian murriztuta zegoenean. Apple/Google Payk estatuko izena lokalizatuta bidaltzen dute (adibidez, 'Bartzelona') administrativeArea-n, baina WooCommerce-ko bidalketa zonak estatuko kodearen arabera bat etorri behar dute (adibidez, 'B'); estatuko herrialde-zona ez zen bat etorri eta saskia garestiagoa zen (adibidez, 'Europako gainerakoak'). Estatuko izenak orain WooCommerce-ko estatuko kodeetara normalizatzen dira bidalketa zona bilatzeko eta eskaera sortzeko aurretik.
- InSite-ko Bloqueen checkout-ak eskaera bikoitzak sor zitzakeen Redsys-ek token ordainketa postMessage bera behin baino gehiagotan igortzen bazuen (edo gordetzea lehiatzen zen). Orain babesa eskaera bikoitzak/lehiatuak sortzea saihesten du eta berriro hasten da ordainketa formularioa errore baten ondoren freskatzen denean.
- InSite-ren REST debug log-ak okerreko objektua erabiltzen zuen debug flag-a irakurtzeko, beraz, 'REST trataPeticion' payload-a irakur zitekeen (edo saltatu) pasareta debug ezarpenaren arabera. Orain pasareta debug flag-a erabiltzen du.
31.0.1
Eguneratuta:
- Bizum modalaren atzera kontua ordainketa orrian 7 minutu erakusten zuen. Orain 5 minutu erakusten ditu, eta checkout-a bideratzen duen zerbitzari aldetako denbora kontrola egokitu da (60 iterazio * 5 segundo = 5 minutu).
Konpondu:
- Bizum ordainketa orrian (Bizum InSite) ez zuen deskribapenik bidaltzen Redsys-era. Modaletik benetako karga REST API bidez egiten da (trataPeticionREST), eta eskaera horrek DS_MERCHANT_PRODUCTDESCRIPTION parametroa ez zuen barnean, beraz, 'Redsys Deskribapena' ez zen iritsi (adibidez, 'Eskaera ID'). Deskribapena orain hautatutako ezarpenetik kalkulatzen da eta REST eskaeran bidaltzen da.
31.0.2
Eguneratuta:
- redsys_modify_data_to_send iragazkiak orain 'testuingurua' => 'add_payment_method' eta 'user_id' jasotzen ditu datu arrayan 'Ordainketa metodoa gehitzeko' fluxurako, beraz, snippet pertsonalizatuak eta arau baldintzak tokenizazioa terminal egokira bideratu dezakete (terminal + SHA256) eskaera bat ez dagoen fluxu honetan.
- Itzulpen guztiak eguneratu dira.
Konpondu:
- Nire kontutik txartela gehitzea ('Ordainketa metodoa gehitu') denda anitzetan Redsys-ek diruaren errore batekin baztertu zitekeen. Eskaera bezeroaren saioaren diruarekin (adibidez, ARS, 32) bidaltzen zen baina terminala beste diru batean ezarrita zegoen (adibidez, EUR, 978). Txartela tokenizatzea zero kopuru bateko operazioa da eskaera bat gabe, beraz, iragazki edo arau baldintzarik ez badu eskaera beste terminal batera bideratzen, orain denda oinarrizko dirua bidaltzen da, beti terminalaren ezarpenarekin bat etorriz.
- Nire kontutik txartela gehitzea (edo profilaren email loturaren bidez) beti Redsys-en one-click gisa erregistratzen zen (DS_MERCHANT_COF_TYPE 'C'), bezeroak harpidetzak hautatzen zituen arren. Token mota okerreko barne gako batetik irakurtzen zen, beraz, 'R' inoiz ez zen bidaltzen. Tokena zuzenean gorde zen WooCommerce-n R gisa, baina COF akordioa C gisa sortu zen Redsys-en, eta horrek zenbait emisorek harpidetza berritzeak (MIT) baztertzea eragin zitzakeen. Harpidetzak hautatuta gehitutako txartelak orain zuzenean bidaltzen dute DS_MERCHANT_COF_TYPE 'R'. Akatsak gertatu ziren bitartean sortutako tokenak ez dira birkalifikatuko; berritze bat baztertzen bada, eskatzen zaio bezeroari txartela berriro gehitzeko.
- Gordetako txartel batekin egindako ordainketek (token R) eta harpidetza berritzeek aurreordainketa ezarpenak errespetatzen ez zituzten. 'Aldatu guztiak aurreordainketa' aktibatuta (edo aurreordainketa markatutako produktua), karga normalean (motako 0) exekutatzen zen baina eskaera 'Aurreordainketa' gisa markatzen zen, beraz, aurreordainketa berreskuratzeko saiakera Redsys-en SIS0059 errorearekin porrot egiten zuen ('Ez dago operaziorik berreskuratzeko'). Bi fluxuek orain benetako aurreordainketa motako 1 bat bidaltzen dute, berreskuratu daitekeena, eta eskaera 'Aurreordainketa' gisa markatzen da benetako aurreordainketa exekutatu denean. Honek harpidetza aurreordainketak ahalbidetzen ditu (adibidez, pisuaren arabera saltzen diren produktuak, non karga azkena aurreordainketa egin aurretik egokitzen den).
Segurtasuna:
- Merkataritzako SHA-256 gako sekretua ez da gehiago idazten debug logetan testu planoan. Debug sarrerak orain gakoa ezkutatzen dute, azken 4 karaktereak erakutsiz, WCRed()->mask_secret() laguntzaile berriaren bidez. Pasareta guztietan aplikatua (Bideratzea, InSite, Bizum, Google Pay, Apple Pay, PayGold, Domiciliación bancaria eta Blocks laguntza klaseak).
- Redsys-en jakinarazpenen (IPN) sinadurak orain hash_equals() (denbora konstanteko konparaketa) bidez egiaztatzen dira jakinarazpenen manejatzaile guztietan, InSite eta REST bezeroarekin erabiltzen zuten egiaztapenarekin bat etorriz. Denbora erasoen aurka indartzea.
- Token bakar baten ezabatze AJAX manejatzaileak orain manage_woocommerce gaitasuna behar du noncearekin batera, ezabatzeko masiboko manejatzailearekin parekatuz.
