Bertsio honen garapenak 1.700 euro kostatu du. Aurten metatutako kostua 5.234 euro da. Lehen bertsioaren metatutako kostua 40.724 euro da, baina zure kostua da lizentzia bakarrik 79€-tik aurrera.

Redsys PrestaShop Premium moduluaren 2.0.0 bertsioa Redsys PrestaShop Premium. Bertsio nagusia da: PrestaShop 1.7, 8 eta 9 (PHP 7.4 edo goragoko) bateragarritasuna handitzen du eta, batez ere, ordainketa baieztapenaren segurtasuna indartzen du.

Tabla de contenido

2.0.0

Berria:

PrestaShop 1.7 (PHP 7.4+) bateragarritasuna. Moduluak orain instalatu eta funtzionatzen du PrestaShop 1.7-n PHP 7.4 edo goragokoan, PrestaShop 8 eta 9 / PHP 8.x-rekin guztiz bateragarri mantenduz. PHP-ren gutxieneko eskakizuna 8.1-tik 7.4-ra jaitsi da instalazio guardan, ps_versions_compliancy (orain gutxienez 1.7.0.0) eta composer.json. PHP 7.1, 7.2 eta 7.3 ez dira bateragarriak bizitzako amaieran daudelako; 1.7.7.x denda batek oraindik bertsio horiek erabiltzen baditu, bere PHP 7.4-ra eguneratu behar du instalatu aurretik.

Hobetu:

PHP 8.0-ren hizkuntza eraikuntzak PHP 7.4-rekin bateragarriak diren baliokideekin ordezkatu dira, jokabide aldaketarik gabe: adierazpen guztiak match() aldatu dira switch (8 kasu), mota mixed ezabatu da eta docblock-ean dokumentatu da (4 kasu) eta baterako motak metodo sinaduratik kendu dira eta docblock-era pasatu dira (6 kasu). PHP 7.4-ren ezaugarri modernoak (tira funtzioak, tipatutako propietateak, nullable motak eta strict_types) osorik mantentzen dira.
Ordainketa akatsak orain beti erregistratzen dira. Laguntza berri bat, Ps_redsys_gateway::persistPaymentError(), akatsaren arrazoia eskaeraren pribatua mezua gisa gordetzen du, eta log luzatuan sarrera bat, eta IPN eta baieztapenaren akats bideek orain arrazoia ez engainagarria idazten dute (adibidez, «baimena kodea baimen kodea gabe; ordainketa EZ baieztatuta» edo «jakinarazpenik gabe Ds_Response»). Ordainketa akatsik ez da isilduko.

Segurtasuna:

[Kritikoa] Eskaera bat Redsys-en baimendutako baimenik gabe PAGATUTAKO gisa markatu zitekeen. Urrezko araua «inongo eskaera Redsys-ek benetan ordainketa baimendu ez badu, ez markatu ordainduta» orain iturri bakar baten bidez aplikatzen da, Ps_redsys_gateway::isRedsysPaymentAuthorised(), zeinak eskatzen duen Ds_Response present egotea eta zorrozki [0,99] tartean egotea eta ez hutsik dagoen Ds_AuthorisationCode egotea. Honek itxura itxi egiten du (int) null === 0 (erantzun kode bat falta denean 0 = arrakasta bezala interpretatzen zen) eta baimen kodearen falta kasua (ordainketa baimendu zen baina baimen zenbakirik gabe). Egiaztapena IPN-n aplikatzen da (controllers/front/ipn.php), URL bidezko baieztapenean (controllers/front/confirmation.php), Paygold-en (PaygoldService) eta REST baimen kontrol puntuan (RedsysRestService::trataPeticion), Apple Pay, Google Pay, Bizum, InSite, OneClick, gordetako txartela eta Paygold barne. Konpondu beharreko sintoma: Apple Pay eskaerak ordainduta agertzen ziren dirua kobratu gabe eta Redsys-en panelean ezer agertu gabe.
[Kritikoa] AJAX publikoaren amaiera expresspay?action=createOrder eskaera zuzenean ordainduta sortzen zuen (REDSYS_ORDER_STATE_COMPLETED) bezeroak emandako transaction_id batekin eta Redsys-en egiaztapenik gabe. Orain behartzen du pendingState=true, beraz, eskaera bat pendente edo ordainketa itxaroten sortu dezake; ordaindutako egoera IPN egiaztatua sinaduraren bidez aplikatzen da. Defentsa sakon gisa, ExpressCheckoutService::createOrderFromExpressPay ordaindutako egoera baztertzen du baimen erreferentziarik ez dagoenean eta segurtasunez pendentean erortzen da.
[Kritikoa] Inespay IPN (controllers/front/inespayipn.php) eskaera PAGATUTAKO bat sortzen zuen, autentifikatu gabeko jakinarazpen baten (sinadurarik gabe, HMAC gabe, zerbitzarian baieztapenik gabe) eremuan fidatuz, benetako banku ordainketarik gabe eskaera bat baieztatzeko aukera emanez. Orain codStatus sinadura egiaztatzen du Inespay API v2.2-k zehazten duen moduan: HmacSHA256 InespayApiService::validateCallback() Base64-en kodifikatuta kontuaren API KEY-rekin, hexadigito txikietan adierazita eta gero Base64-en kodifikatuta, dataReturn konparatuz. Itxura itxia: jakinarazpen bat signatureDataReturneta baliozko dataReturn bat ez da onartzen eta eskaera inoiz ez da markatzen ordainduta. Fidagarritasun signatureDataReturn sinadura (OK / SETTLED) sinatutako payload-etik irakurtzen da, ez POST gorputz hutsetik. codStatus de confianza (OK / SETTLED) se lee del payload firmado dataReturn, no del cuerpo POST en bruto.