Bertsio honen garapenak 2.800 euro kostatu du. Aurten pilatutako kostua 13.350 euro da. Lehen bertsioaren hasieratik pilatutako kostua 212.080 euro da, baina zuretzat kostua lizentzia bakarrik da 79€.
WooCommerce-ren Redsys pluginaren 31.0.0 bertsio berria WooCommerce.com.
31.0.0
Berria:
- A2A (Agent2Agent) protokoloaren azalera berria. Aukerakoa eta lehenetsita desaktibatuta. Agent Card bat argitaratzen du /.well-known/agent-card.json-en 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 probetarako sandbox bat behin-behineko bearera bat).
- Server-Sent Events stream-a /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream-en, bizitzako eguneratzeetarako, Last-Event-ID bidez berreskuratzeko eta 15s-ean bihotz-txistua (heartbeats) izateko.
- Bezeroak erregistratutako push_url batera sinatutako push jakinarazpenak. X-A2A-Signature: 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 (ordainketa itzulketak edo gelditutako kargak onartzea input-required-en).
- Gaititako muga: max_amount muga zorrotza da, eta lanaren porrotak limit_exceeded-ekin; sensitive_threshold lanaren gelditzea input-required-en administratzaile batek berretsi arte. Biak mugarik gabe daude lehenetsita (aukera).
- Audit log-a soilik gehitzeko (append-only) wp_redsys_a2a_audit_log-en. Inprimakiak inoiz ez dira 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 larri bat eragiten.
- IA erosle agenten laguntza (ChatGPT, Claude, Gemini, Perplexity eta beste batzuk). IA agentek orain zure produktuak aurkitu, saskiak osatu, ordainketak egin eta zure dendetako eskaeren eguneratzeak jaso ditzakete. OpenAI/Stripe-ren ACP estandarra eta Google, Shopify eta beste batzuek babestutako UCP estandar irekiak onartzen dira, eta bakoitza independente aktibatu edo desaktibatu daiteke.
- Redsys Aurreratuaren ezarpenetan 'Agentic Commerce' azpialdea berria, funtzioaren iragazkiak (saskiak, deskontuak, betetzeak, eroslearen baimena, bezeroen erregistro dinamikoa, etab.) eta agenten aurkikuntza, OAuth eta webhook fluxuak probatzeko klik bateko botoiak.
- Webhooken sinadura 'Sinadura gakoa biratu' botoi batekin. Biratutako gakoak 7 egun iraun dezakete integrazioek aldaketa bitartean funtzionatzen jarraitzeko.
- Express-en pertsonalizatutako eremuen modalak (Apple Pay / Google Pay) 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 independenteki.
- Aukerako ekintza masiboa 'Aprobatzea aurreautorizazioa' eskaeren zerrendarako (Redsys Bideratzea). Lehenetsita desaktibatuta segurtasunarengatik; aktibatu pasareta ezarpenetan soilik aurreautorizatutako eskaerak masiboki baieztatu behar badituzu.
Oharrak:
- Edozein laguntza aktibatzea ez du esan nahi IA laguntzaileek zure dendan erosketa osatzen hasiko direnik lehen egunean. Agentek gidatutako checkout fluxu osoa oraindik ez da ezarri, batez ere Europan, non SCA/3DS, PSD2 eta RGPD baimenaren eskakizunek gehieneko agentek produktuen aurkikuntzan edo aurre-saskian gelditzen diren eta azken ordainketa bezeroari itzultzen dioten. Zure denda prest dago egun bakoitzak agentek zure merkatuan fluxu osoa aktibatzeko.
Eguneratuta:
- Express-en pertsonalizatutako eremuen modalak orain bere konfigurazioa kargatzean aurrez kargatzen du eta Apple Pay abiarazten du klik egitean sinkronoki, iOS Safari-k ordainketa orria bertan behera uzten zuen kasuak konpontzen.
- Express-en pertsonalizatutako eremuak produktuen orrian modal lehenetsira itzuli dira. 30.4.1-en sartutako online inprimakia orain aukera da iragazki baten bidez.
Konpondu:
- [Kritikoa] Harpidetzak berritzeko prozesuak porrot egin dezake Redsys SIS0502 errorearekin ('Id Oper ez da bat etortzen') Redis, Memcached edo beste objektu iraunkorren cachekin dituzten hostingetan. Berritze bi lan paraleloak bi eskaera erreferentzia desberdin bidali ditzakete Redsys-i harpidetza berean, berritzeak porrot eginez eta behin eta berriz saiatu. Ordainketa bikoitzaren blokeoa eta eskaera erreferentzia orain fidagarri gordetzen dira cache atzealdearen independentean. Bideratze eta InSite Redsys pasaretei eragiten die.
- InSite-ren harpidetzak ez zuen inolako lehiaketa babesteko (blokeoa akatsak gertatzen zirenean ezabatzen zen baina inoiz ez zen sortzen). Orain InSite-ren berritzeetan bideratze pasareta erabiltzen duen lehiaketa babesa aplikatzen da.
- Checkout-ean erabiltzen den cacheatutako egoera (3DS datuak, gordetako txartelaren identifikatzailea, sinadura cachea, OAuth egoera, IMAP egoera aldi baterako, etab.) orain funtzionatzen du objektu iraunkorren cachekin dituzten hostingetan. Lehen, cacheek gaizki jokatzen zutenean, egoera hau isilean desagertu zitekeen checkout-en erdian eta SIS0502 erroreak eragiten zituen.
- Apple Pay eta Google Pay Express botoiek (blokeen checkout eta produktuen orria) 'Must create a new ApplePaySession from a user gesture handler' errorea ematen zuten iOS Safari-n Express-en pertsonalizatutako eremuen modalak aktibatuta zegoenean. Modalak ez du erabiltzailearen klikaren aurretik Apple Pay abiarazten.
- Premium autonomoen IRPF-a gaizki kalkulatzen zen Pago Express-en (Apple Pay / Google Pay) produktuen orrian bezeroak modaleko erabiltzaile mota hautatzen zuenean, modalaren gordetzea Apple Pay zerbitzariaren lehen deiarekin lehiatzen baitzen. Erabiltzaile mota orain Express Pay eskaera bakoitzarekin bidaltzen da, beraz, totala beti zuzena da.
- Produktu birtualak dituzten produktuen orrietan, Apple Pay orriak laburki erakusten zuen guztira zuzena (subtotala + zerga) eta gero produktuen prezioari itzultzen zen. Bidalketa callback-ak orain zerbitzariak itzuli duen azken guztira mantentzen du.
- Agentic Commerce ezarpenak gordetzean 'Aldaketak gorde' bidalketa isilean baztertzen zen WooCommerce-ren HTML inprimaki anidatuen erruagatik. Ezarpen orria berrantolatu da eta ekintza bakarreko botoi guztiak (aurkikuntza probatu, OAuth probatu, webhook ekintzak, etab.) orain funtzionatzen dute 'Gorde' botoi nagusiaren ondoan.
- Produktu orrian Apple Pay eta Google Pay Express botoiek bidalketa zona okerra esleitzen zuten bezeroaren eskualdea probintzian murriztuta zegoenean. Apple/Google Pay-k estatuaren izena lokalizatua (adibidez, 'Bartzelona') administrativeArea-n bidaltzen dute, baina WooCommerce-ren bidalketa zonak estatu kodearen arabera bat etorri behar dute (adibidez, 'B'); estatu-eskualdeko zona ez zen bat etortzen eta saskia garestiagoa zen (adibidez, 'Europako gainerakoa'). Estatu izenak orain WooCommerce-ren estatu kodeetara normalizatzen dira bidalketa zona bilaketa eta eskaera sortu aurretik.
- InSite-ko Bloqueen checkout-ak eskaera bikoitzak sor zitzakeen Redsys-ek token ordainketa postMessage bera behin eta berriz igortzen bazuen (edo gordetzea aldi berean exekutatuz). Orain babesa eskaera bikoitzak/konkurrentesak sortzea saihesten du eta berriro hasten da ordainketa inprimakia errore baten ondoren freskatzen denean.
- InSite-ren REST debug log-ak okerreko objektua erabiltzen zuen debug bandera irakurtzeko, beraz, 'REST trataPeticion' payload-a erregistratu zitekeen (edo saltatu) pasareta debug ezarpenaren arabera. Orain pasareta debug bandera erabiltzen du.
31.0.1
Eguneratuta:
- Bizum modalaren kontagailuak orrian 7 minutu erakusten zituen. Orain 5 minutu erakusten ditu zuzenean, eta checkout-a birbideratzen duen zerbitzari aldetiko denbora kontrola egokitu da (60 iterazio * 5 segundo = 5 minutu).
Konpondu:
- Bizum orda orda orda (Bizum InSite) ez zuen deskribapena Redsys-era bidaltzen. Modaletik egindako kargua API REST bidez egiten da (trataPeticionREST), eta eskaera horrek ez zuen DS_MERCHANT_PRODUCTDESCRIPTION parametroa barne, beraz, konfiguratutako "Redsys Deskribapena" (adibidez, "Order ID") hutsik iristen zen Redsys panelera. Deskribapena orain hautatutako doikuntzatik kalkulatzen da eta eskaera REST-ean bidaltzen da.
31.0.2
Segurtasuna:
- Merkataritzaren SHA-256 gako sekretua ez da gehiago idazten plano testuan WooCommerce-ko debug erregistroetan. Debug sarrera guztiak orain gakoa maskatzen dute, azken 4 karaktereak soilik erakutsiz, WCRed()->mask_secret() laguntzaile berriaren bidez. Pasareletan aplikatua (Redirección, InSite, Bizum, Google Pay, Apple Pay, PayGold, Domiciliación Bancaria eta Blocks-en laguntza klaseak).
- Redsys-en IPN jakinarazpenen sinadurak orain hash_equals() (denbora konstanteko konparazioa) bidez egiaztatzen dira jakinarazpenen kudeatzaile guztietan, InSite eta REST bezeroak erabiltzen zuten egiaztapenarekin bat eginez. Denbora erasoen aurkako indartzea.
- Token bakar baten ezabatze AJAX kudeatzaileak orain manage_woocommerce gaitasuna eskatzen du noncearekin batera, ezabatze masiboaren kudeatzailearekin parekatuz.
Eguneratuta:
- redsys_modify_data_to_send iragazkiak orain 'context' => 'add_payment_method' eta 'user_id' jasotzen ditu datu arrayan "Ordainketa metodoa gehitu" fluxurako, beraz, snippet pertsonalizatuak eta arau baldintzatuak tokenizazioa terminal egokira bidera dezakete (terminal + SHA256) eskaera hau ez dagoen agindu baten menpe egon gabe.
- Itzulpen guztiak eguneratu dira.
Konpondu:
- Nire Kontutik txartela gehitzea ("Ordainketa metodoa gehitu") moneta anitzeko dendetan Redsys-ek monetaren errore batekin baztertu zitekeen. Eskaera bezeroaren saioaren monetarekin (adibidez ARS, 32) bidaltzen zen baina terminal lehenetsia erabiliz, beste moneta baterako konfiguratutako (adibidez EUR, 978). Txartelaren tokenizazioa zenbateko zero bateko operazioa da agindu baten atzean, beraz, ez badago iragazki edo arau baldintzaturik eskaera beste terminal batera bideratzen, orain denda oinarrizko monetarekin bidaltzen da, beti terminal lehenetsiko konfigurazioarekin bat etorriz.
- Nire Kontutik txartela gehitzea (edo profilaren email estekaren bidez) beti txartela Redsys-en one-click (DS_MERCHANT_COF_TYPE 'C') gisa erregistratzen zen, bezeroak harpidetza aukera hautatzen bazuen ere. Token mota gako barne okerretik irakurtzen zen, beraz, 'R' inoiz ez zen bidaltzen. Tokena zuzenean gorde zen R gisa WooCommerce-n, baina COF akordioa C gisa sortzen zen Redsys-en, eta horrek zenbait emisorek harpidetza berritzeak (MIT) baztertzea eragin zezakeen token horiekin. Harpidetza aukera duten txartelak orain behar bezala bidaltzen dute DS_MERCHANT_COF_TYPE 'R'. Akatsak egon ziren bitartean sortutako tokenak ez dira berriz sailkatu daitezke; berritze bat baztertzen bada, bezeroari txartela berriro gehitzeko eskatzen zaio.
- Gordetako txartel batekin (token R) egindako ordainketek eta harpidetza berritzeek aurreautorizazio doikuntzak ez zituzten errespetatzen. "Agindu guztiak aurreautorizatu" aktibatuta (edo aurreautorizatzeko markatutako produktu bat), karga salmenta normal gisa (tipo 0) exekutatzen zen baina agindua "Aurreautorizatua" bezala markatzen zen, beraz, aurreautorizazioa beranduago baieztatzeko Redsys-en SIS0059 errorea ematen zuen ("Ez dago baieztatzeko operaziorik"). Bi fluxu horiek orain benetako aurreautorizazio bat bidaltzen dute tipo 1 gisa, gero baieztatu daitekeena, eta agindu bat "Aurreautorizatua" bezala markatzen da benetako aurreautorizazio bat exekutatu denean. Honek aurreautorizatutako harpidetzak ahalbidetzen ditu (adibidez, pisuaren arabera saltzen diren ondasunak, non karga amaitu aurretik doikuntza egiten den).
31.0.3
Berria:
- Redsys Aurreratua -> Redsys Aurreratuen Doikuntzak barruan "Apps eta Plugins" atala. MacOS-erako kudeaketa aplikazioaren irakurtzeko orri bat (deskargarekin, eskakizunekin eta "laster" plataformekin) eta gainerako plugin doako eta premiumen zerrenda, webguneak eta atariak, Claude-ren skillak eta José Conti-ren garatzaile profilen zerrenda, bakoitza motaren arabera taldekatuta lotura batekin. Zerrenda bakoitza iragazgarria da (redsys_apps_plugins_mac_app, redsys_apps_plugins_free, redsys_apps_plugins_premium, redsys_apps_plugins_webs, redsys_apps_plugins_skills, redsys_apps_plugins_profiles).
Segurtasuna:
- Jakinarazpen sinaduraren egiaztapen bide bat ezabatuta geratu da, anonimo bat eskaera bat ordainduta markatzeko aukera ematen zuena SHA-256 gakoa hutsik edo gaizki konfiguratu zenean. Redsys-en IPN entzuleak (publiko wc-api amaiera) heredatutako fallback bat zuen, ez zegoen gako konfiguraturik, jakinarazpen bat onartzen zuen soilik merkataritzako Ds_MerchantCode bat bidaltzen bazen, merkataritzako FUC-rekin bat etorriz, balio publiko eta ez sekretu bat, erasotzaile batek emateko aukera zuen. Merkataritzako kodean oinarritutako onarpen hori guztiz ezabatu da pasareletatik (Redirección, Bizum, Bizum InSite, Google Pay checkout eta redirekzioa, Apple Pay, PayGold, Domiciliación Bancaria, MasterPass eta Transferencia Bancaria): ez dagoen gako bat HMAC egiaztatzeko, eskaera orain segurtasunez porrot egiten du (HTTP bazterketa) konfiantza izan beharrean. Gainera, egiaztapen partekatuaren errutina (WooRedsysAPI::verify_signature_notif) orain false itzultzen du merkataritzako gakoa edo jasotako sinadura hutsik daudenean, beraz, check_ipn_request_is_valid() ez da posible izango successful_request() HMAC hutsik kalkulatuz ordaintzea. InSite-k sinadura baliozkoa eskatzen zuen (merkataritzako kodearen fallback gabe) eta Inespay-k ez du eraginik (bere payin id propioarekin lotzen ditu aginduak). Denda errealei ez die eragiten, gako bat konfiguratu izana derrigorrezkoa baita kobratzeko.
Konpondu:
- Bizum-en jakinarazpenak sinaduraren egiaztapen errore batekin baztertzen ziren, agindua ordainduta ez markatuz, nahiz eta ordainketa Redsys-en baimenduta egon. Merkataritzako gakoa eta aginduko zenbakia zuzena ziren (eskaeraren sinadura perfektuki bat etorri zen), baina jakinarazpenaren sinadura HMAC bat zen, Ds_MerchantParameters katean kalkulatuta jasotzen zen bezala, eta Bizum-en jakinarazpenak azken "=" base64 padding-a ezabatuta iristen ziren, bitartean Redsys-ek balioaren gainean padding kanonikoa sinatzen zuen, beraz, lokaleko kalkulatutako HMAC-a inoiz bat ez zen etorriko. Jakinarazpen partekatuaren errutina (create_merchant_signature_notif WooRedsysAPI-n) orain payload-a lau multiplo batera berriro betetzen du hashear baino lehen, eta egiaztapenak (verify_signature_notif) orain bi sinadurak konparatzen ditu azken "=" padding-a alde batera utzita (ez du entropiarik ematen, beraz, konparazioa denbora konstantean mantentzen da). Txartelaren payload-ak orain kanonikoak dira eta intact mantentzen dira, beraz, gainerako pasarelek aldaketarik gabe funtzionatzen jarraitzen dute. Errutina hau jakinarazpen kudeatzaile guztiek partekatzen dute (Redirección, Bizum, InSite, PayGold, Google Pay, Apple Pay, Domiciliación Bancaria, Transferencia Bancaria eta REST/A2A bezeroak).
- Txartelen eta wallet-en jakinarazpenak "sinadura desadostasun" batekin baztertu zitezkeen, beraz, eskerrak ordaintzeko orrira itzultzen zen bezeroak (eta IPN zerbitzuz zerbitzura) agindua ordainduta markatzeko aukera ez zuen lortzen, IPN-ren hurrengo saiakera arrakastatsua kasualitatez lortzen zen; itzulketa eta PayGold-en loturak beranduago ordainduta geratu zitezkeen. Bi padding arazo daude inplikatuta: Bizum-en aurreko payload-aren paddingaz gain, Redsys-ek jakinarazpen sinadura (Ds_Signature) base64 URL-segurtasunez entregatzen du azken "=" ezabatuta, bitartean lokaleko kalkulatutako sinadurak mantentzen du, beraz, konparazio estu bat ere porrot egiten du txartel ordainketa normala. Padding-a tolerantzia konparazioa verify_signature_notif()-en bizi da, baina kudeatzaile gehienek sinadura linean konparatzen jarraitzen zuten hash_equals()/!== estu batekin, zeinak sentikortasuna berreskuratzen zuen. Orain kudeatzaile guztiek verify_signature_notif()-en delegatzen dute, beraz, konponketa guztietara iristen da: Txartelaren Redirección (IPN eta REST-SOAP atzitzeko/itzultzeko bi egiaztatzaileak), Bizum, Bizum InSite, InSite (IPN, successful_request eta bi REST erantzun egiaztatzaileak), PayGold, Google Pay (checkout eta redirekzio), Apple Pay, Domiciliación Bancaria, Transferencia Bancaria, MasterPass eta InSite-ren REST bezeroa. Regresioa sinadura egiaztapenak pasareletan unifikatu zirenean sartu zen verify_signature_notif()-en konparazio estu eta padding sentikor batekin.
- Bizum-en jakinarazpenak denda anitzeko / terminal bikoitzekoetan (eskaera bakoitza terminal desberdinetara bideratzen dutenak bizum_modify_data_to_send iragazkiaren bidez edo arau baldintzatu baten bidez) orain sinadura gako benetakoa eskaeraren arabera ebazten dute sinadura egiaztatu aurretik (bezeroak doikuntzen gakoa, ordainketa formularioa sortu zenean gordetako transient-a, edo aginduaren meta _redsys_secretsha256), eta ez da egiaztatzen den jakinarazpen bat HTTP 400-rekin baztertzen da.
- InSite-ko txartelarekin egindako ordainketek 3DS challenge bat behar zutenean, Safari-n (iPhone/Mac) egiaztapen orri zuria agertzen zen, bezeroak SMS/PIN kodea sartu ezin zuelarik eta ordainketa huts egiten zuen (fluxu bera Chrome-n funtzionatzen zuen). Challenge-a berak orri oso bat eta maila altuko nabigazioa zen, baina aurretik pluginak nabigatzailea ematzailearen 3DS Method URL-ra (threeDSMethodURL) birbideratzen zuen nabigatzailearen hatz-markaren hartzeko, eta Safari-ren Inteligentzia Jarraipena (ITP) hirugarrenen cookieak blokeatzen zituen urrats horrek behar zuen, ACS orri zuria utziz (sintoma: ACS URL-a “;jsessionidpa=”rekin iristen da, cookieak ez direlako fluxuan). 3DS Method urratsa nabigatzailean aukerakoa da, beraz pluginak ez du nabigatzailea threeDSMethodURL-ra birbideratzen: beti threeDSCompInd = 'N' bidaltzen du eta zuzenean autentikazioari jarraitzen dio. InSite-ren fluxu guztietara aplikatua -txartel berria eta gordetako txartela (one-click/token), bai blokeen checkout-ean bai klasikoan (shortcode)- eta Redirekzio pasarelen REST/token fluxuetara (pay_with_token_c, receipt_page eta successful_request), izan ere, orri zuria gordetako txartelaren tokena kobratzean ager zitekeen.
- InSite-ko txartelarekin egindako ordainketa bat huts egiten zuen checkout-eko beharrezko eremu bat falta zenean edo datuak bat etorri ez zirenean (adibidez, abizen huts batek “signature mismatch” sortzen zuen), errore-mezuak txartela egotzi zuen (“…berriro sartu zure txartelaren datuak”), beraz bezeroek pentsatzen zuten beren txartela baztertu egin zela eta eskaera uzten zuten. Orain mezu neutroa da eta lehenik checkout-eko eremuetara bideratzen du: bezeroari eskatzen dio checkout-eko eremu guztiak (izena, abizenak, helbidea, etab.) eta txartelaren datuak ondo beteta daudela egiaztatzeko, berriro saiatzen hasi aurretik. Klasiko eta blokeen checkout-ei (Blocks) aplikatua.
- Handiak diren eskaeren ID-ak dituzten ordainketa itzulketak eta atzeratutako ordainketak (checkout instantan zuzendutako “mil milioi bug” jada konponduta) eskaera oker baten kontra erregistratzen ziren, edo ez ziren erregistratzen. Redsys-en notifikazioa (IPN) WooCommerce-ren eskaera ID-a eskaeraren zenbakiaren bidez berreskuratzen du clean_order_number() erabiliz, lehenik eskaera zenbakia sortu zen unean gorde zen transient bat bilatzen duena eta, horren falta, 10 edo gehiagoko ID-en goiko digituei uko egiten dien substr/ltrim heuristika erabiltzen zuena. Transient horrek 1 orduko TTL-a du, beraz fallback-a aktibatuta geratzen zen notifikazioa eskaera zenbakia sortu zenetik ordu bat baino gehiago igaro denean iristen denean: itzulketak (egun edo aste batzuk geroago prozesatuak) eta PayGold-en ordainketa loturak (bezeroak beranduago ordaindutakoak), besteak beste. Hiru aldaketa hauek egiten dute orokorra ordainketa metodo guztietarako: (1) ordaintzeko rutina partekatua (ask_for_refund) orain eskaera ID benetakoa -> benetako eskaera ID-a mapatzen du itzulketaren unean 24 orduko TTL batekin; (2) clean_order_number(), transient-a ez dagoenean, orain eskaera atzera bilatzen du eskaera zenbakiaren meta iraunkorraren bidez (_payment_order_number_redsys / _redsys_transaction_id2) heuristika galduarekin inoiz erabili aurretik; eta (3) PayGold orain eskaera zenbakia meta-n iraunkortzen du lotura sortzen denean, beraz, beranduago ordaindutako lotura zehazki eskaerara iristen da. Pasarelen guztietan aplikatua (Redirekzio, InSite, Bizum, Bizum InSite, Google Pay, Apple Pay, PayGold eta Domiciliación Bancaria). Inespay-k ez du eraginik (eskaerak bere payin id propioarekin lotzen ditu).
- InSite-ko txartelarekin egindako ordainketek blokeen checkout-ean (Blocks) LEHENENGO aldiz huts egiten zuten “msg18”rekin (bezeroak “egiaztatu checkout/txartelaren eremuak beteta daudela” ikusten zuen) eta bigarren saiakeran funtzionatzen zuten bakarrik. Redsys-en InSite SDK-k orriak “domain” mezua bidali behar du txartelaren iframe-ra, Redsys-ek merkataritza balioztatzeko; SDK-k onload=
- InSite checkout de bloques: se ha hecho más robusto el manejo del postMessage de Redsys y se han añadido diagnósticos de extremo a extremo. El manejador ahora acepta mensajes de cualquier subdominio de Redsys (sis.redsys.es, sis-t.redsys.es, sis-d.redsys.es) en lugar de exigir una coincidencia exacta de host/puerto (Redsys publica desde más de un host), elimina cualquier listener dejado por un renderizado anterior para que un único token no pueda disparar múltiples envíos, y limpia los campos de token/error tras leerlos para que un re-disparo obsoleto no pueda reenviarlos. Cuando el registro de depuración de InSite está activado, todo el paso de tokenización del lado del cliente (número de pedido, postMessage de Redsys, token/código de error, guardado y place-order) se refleja en el log "insite" de WooCommerce, de modo que los fallos del primer intento que nunca llegan a PHP puedan diagnosticarse.
- Los pagos con tarjeta de InSite en el checkout de bloques (Blocks) eran rechazados por Redsys con SIS0574 ("operación de autenticación EMV3DS rechazada, browserUserAgent no indicado"): la huella 3DS del navegador (user agent, tamaño de pantalla, idioma, profundidad de color, zona horaria) nunca llegaba al pedido, porque el hook que normalmente la copia al pedido (woocommerce_checkout_create_order) no se ejecuta en el checkout de la Store API (Blocks). El formulario de InSite de Blocks ahora recoge la huella y la envía junto con el token de operación, y se escribe en el pedido real (junto al token) antes de que se ejecute process_payment, de modo que la autenticación EMV3DS tiene los datos que necesita.
- Los pagos con tarjeta de InSite en el checkout de bloques (Blocks) eran rechazados con un "código de error sin token" (mostrado al cliente como "comprueba que los campos del checkout/tarjeta están rellenados"), de modo que la tarjeta ni siquiera podía tokenizarse tras unos pocos intentos. Como el pedido todavía no existe en el checkout de Blocks (id de pedido 0), el número de pedido de Redsys preparado se generaba a partir del id 0, lo que producía un valor casi constante -solo ~999 números posibles, todos terminados en nueve ceros- y Redsys rechaza un número de pedido reutilizado ("pedido repetido", SIS0051). Cuando el id del pedido borrador todavía no está disponible, el formulario de InSite de Blocks ahora usa el mismo número de pedido temporal que el checkout shortcode de InSite (create_checkout_insite_number: siempre empieza por 1, globalmente único mediante un contador incremental compartido), así que nunca colisiona; cuando el id del pedido borrador está disponible, el número de Redsys se construye a partir de él. El número se vuelve a vincular al id real del pedido cuando el pedido se realiza.
- Los pagos con tarjeta de InSite en el checkout de bloques (Blocks) fallaban: el cliente veía un mensaje engañoso "comprueba que los campos del checkout/tarjeta están rellenados" y el pedido nunca se pagaba (la consola del navegador mostraba un 404 en la petición save_order_data). La causa es que el WooCommerce actual ya no crea el pedido hasta que el cliente pulsa "Realizar el pedido" -durante la introducción de la tarjeta el store del checkout de Blocks devuelve id de pedido 0- así que el token de operación de InSite (idOper) y el número de pedido de Redsys preparado no podían persistirse: el flujo anterior los enviaba a una ruta REST (save_order_data) que intentaba adjuntarlos al pedido 0 y devolvía "Invalid order" (404), y el número de pedido generado se mapeaba al pedido 0 (de modo que ni siquiera una notificación posterior podía encontrar el pedido). Ahora, cuando la tarjeta se tokeniza, el token y el número de pedido preparado se guardan en la sesión de WooCommerce mediante admin-ajax (la sesión de WC no está disponible en rutas REST personalizadas, razón por la cual el enfoque REST anterior no podía usarla), y se trasladan al pedido real mientras WooCommerce lo crea a partir de la petición del checkout (woocommerce_store_api_checkout_update_order_from_request), antes de que se ejecute process_payment, de modo que process_payment_block() encuentra _insite_token y _payment_order_number_redsys como en el checkout clásico. El transient del número de pedido también se vuelve a mapear al id real del pedido para que la notificación (IPN) resuelva el pedido. Los datos de huella del navegador (3DS) ya usaban esta misma ruta de sesión. El checkout clásico/shortcode no se ve afectado.
Desarrollo:
- Eliminada la ruidosa salida de depuración console.log de los scripts de frontend de producción (minificados): Apple Pay, Google Pay, capture-order-id y los modales de express-checkout. El script de Apple Pay Express en particular registraba en cada cambio del DOM (vigila todo el documento en busca de su botón), lo que inundaba la consola del navegador en el checkout de Blocks. Los archivos minificados ahora eliminan console.log/console.warn/console.info/console.debug manteniendo console.error; las fuentes sin minificar quedan sin cambios para desarrollo.
31.0.4
Arreglado:
- Harpidetzako berritzeak (edozein harpidetza-pluginekin) orain errespetatzen dute konfiguratutako Redsys-en eskaera zenbakiaren mota eta ez dute gehiago huts egiten "eskaera zenbaki errepikatua" (SIS0051) errorearekin. Bi arazo konpontzen dira.
- Lehenengoa: berritze karguak Redsys-en eskaera zenbakia sortzen zuen "Eskaera zenbakiaren mota" (redsysordertype/subfix) ezarpena ignoratuz; beti joaten zen pasareta konfiguratuaren motaren ordez, hasierako ordainketaren kasuan bezala. Orain pasareta igarotzen da berritzeek checkout-eko eskaera zenbakiaren mota bera errespetatzeko.
- Bigarrena: eskaera zenbakia eskaeraren bizitzan zehar mantentzen zen, beraz, berritze karga bat baztertzen zen eta harpidetza-pluginak berriro saiatzen zen berritze eskaera berean, zehazki DS_MERCHANT_ORDER bera bidaltzen zen eta Redsys-ek legitimoa den berriz saiakera blokeatzen zuen bikoiztutzat. Orain "fluxu" eta "berriz saiakera" arteko bereizketa esplizitua da: ordainketa fluxu bakar bat (bere pareko iniciaPeticion/trataPeticion, berritze prozesu paraleloak eta Action Scheduler bidez erdibidean hil zen prozesu baten berriz exekuzioa) eskaera zenbaki bera mantentzen du Id Opers (SIS0502) gurutzatzea saihesteko eta karguen bikoiztuen aurrean idempotente izateko; baina Redsys-ek bazterketa bat baieztatzen duenean (baieztapen kodea gabe sinatutako erantzuna, hau da, diru mugimendurik gabe), zenbakia askatzen da hurrengo saiakera berri eta bakar bat sortzeko konfiguratutako motaren errespetatuz. Berrezartzea BAIEZTATUTAKO bazterketa baten aurrean bakarrik gertatzen da, ez garraio edo denbora itxaroteko akatsen aurrean, non emaitza ezezaguna den, beraz, erantzun galdu baten bidez berriz exekuzio batek inoiz ez du kargua bikoiztuko.
- Redirekzio eta InSite pasaretei eta horiek erabiltzen dituzten harpidetza-plugin guztiei aplikatzen zaie (WooCommerce Harpidetzak, WooCommerce-rako Harpidetzak, YITH, WebToffee, SUMO, Harpidetzak Aurreratuak; Google Pay eta Apple Pay Redirekzio pasaretan delegatzen dute).
- Segurtasun sare gisa, eskaera zenbaki baliodun bat ez badago konfiguraturik (hutsik edo heredatutako edo ezagutzen ez den balioa), generatorrek BETI joaten dira "3 zenbaki aleatorio + zeros + eskaera id" lehenetsira, berriz saiakeren artean inoiz talka egiten ez duen bakarra. Oharrak: "eskaera zenbaki sinple" motak ez du aleatorio osagairik, beraz, diseinuagatik ez da bateragarria harpidetza berriz saiakerekin eta ez da erabili behar harpidetzak aktibo daudenean.
