Gaur egun Stripe eta Redsys asko dira antzekoak, checkout-ean bertan ordaindu ahal izateko aukera barne, nire adibide dendan InSite bidez probatu dezakezue, eta jende askok etengabe esaten badu Stripe hobea dela ordaintzeko, ordaintzeko amaiera handiagoa dagoelako, ez da egia. Beno, zehaztu dezagun, egia da Redsys-en (benetan PSD2) eta Stripe-n nola funtzionatzen duen ezagutzen ez badugu, izan ere, Redsys-ek ordaintzean Stripe-k duen abandonu tasa baxoa berdindu dezakegu (oso murriztua da) eta are murriztu (bai, murriztu), baina aukera ezagutzea eta horrek merkataritzarako zer esan nahi duen jakin behar da. Eta ez, ez du zerikusirik Stripe-ren “teknologia aurreratuarekin”, jende askok etengabe errepikatzen duen bezala mantraren moduan.
Baina hori guztia ulertzeko hasieratik hasi behar da. 2018ko amaieran PSD2 araudia aplikatzen hasi zen progresiboki. 2019ko irailaren 1ean indarrean sartu zen eta eskatzen zuenak bere terminaletan erabiltzen hasi zitekeen, eta 2020ko abenduaren 31n betebeharrezkoa izan zen, nahiz eta kasu batzuetan 2021ean enpresen eskaerak direla eta terminaletan PSD2 fluxua aktibatzen hasi ziren, “denbora izan ez zutelako”. Hori esaten dut, ia 3 urte izan zituztelako hori egiteko, beraz, denbora ez izatearen baino, uztea izan zen (nire iritziz). Nire Redsys plugin premiuma 4 hilabetez egokitzen ibili nintzen, presarik gabe, 2020ko irailan PSD2-ri laguntza ematen zion beta bertsio bat askatuz, erabiltzaileen feedback-a lortzeko, derrigorrezkoa izan baino 4 hilabete lehenago. Izan ere, une horretan, hainbat enpresari lagundu nien beren webguneen kodea PSD2-ra egokitzen, eta garapen ezagunen hainbat enpresari aholku eman nien, izan ere, egia da ez dela erraza eta norbaitek araudi berri hau aplikatzen laguntzen bazuen, hasieratik informazioa bilatzea baino askoz errazagoa zela.
Zeintzuk dira PSD2-ren benetako ezaugarriak? Orokorrean, erosketa bikoitzaren autentifikazioa da. PSD2 indarrean sartu aurretik, autentifikazioa CVV/CVC-n eta kasu batzuetan SMS bat bidaltzean oinarritzen zen, bankuan aktibatzeko eskatzen bazenuen (zenbait bankok aktibatzen zuten, nahiz eta ez eskatuta), jende askok ez zekien edo ez zuen aktibatu nahi “erosoagoa” zelako. PSD2 indarrean sartu zenean, bigarren autentifikazio hori, oro har, bankuaren aplikazioaren bidez operazioa baimentzea zen, Europan derrigorrezkoa izan zen. Honek segurtasuna handitu zuen, baina baita ordaintzeko konplexutasuna ere, jende askorentzat, hainbeste, gaur egun oraindik ez dute amaitzen, ez dakitelako nola egin, edo adibidez, telefonoa eskura ez dutelako.
Eta hemen hasten da garrantzitsua den puntu bat, beraz, gogoan izan eta argi izan. Segurtasun hau bi norabidetan da. Zer esan nahi du? Segurtasuna ematen dio bezeroari, merkataritzan bere txartela erabiliz erosten duenari, baita merkataritzari ere, nor erosten duen benetan txartelaren jabea den eta banku sistemak bermatzen duena, hau da, erosten duenak segurtasuna du, bikoitzaren autentifikazioa izateagatik merkataritzak ezin izango duela bere txartela erabiliz kobratu, eta merkataritzak badaki, eskaera ordaindu badute, kobratuko duela, banku sistemak bermatzen baitu erosi duen pertsona txartelaren jabea dela, beraz, txartela lapurtzen bada (adibidez), kobratuko duzu hala ere, operazioa autentifikatuta badago.
Hasieratik ikusten al duzu nondik doazen tiroak? Hori da, funtsean, Stripe eta Redsys arteko desberdintasuna. Stripek autentifikazio askoz gutxiago eskatzen ditu (praktikan ia ezer ez) eta Redsys-ek, berez, ia operazio guztietan autentifikazioa eskatzen du. Hori da, Stripe-n ordaintze amaiera askoz gehiago izatea eragiten duena Redsys baino. Baina, nola izan daiteke hori, PSD2-k autentifikazioa eskatzen badu? Eta zer gertatzen da Stripe-n autentifikatu gabeko operazio guztiekin? Seguru asko, bi galdera horiek egin dituzu, eta ez badituzu egin, egin beharko zenituzke, orain arte azaldu dudan guztiarekin.
PSD2 direktiban salbuespenak daude, SCA (Strong Consumer Authentication edo kontsumitzaileen autentifikazio indartsua) bezala ezagutzen direnak. SCA batzuk daude, baina hiru bereziki garrantzitsuak dira arlo honetan. Bat MIT da, kasu honetan ez da aplikatzen, hau subskripzioen esklusiboa delako. Ezagutu behar ditugun eta kontuan hartu beharrekoak LWV eta TRA dira.
LWV SCA bat da, eskaera kostu baxikoa denean aplikatzen dena. Hau da, 30€ baino gutxiagoko zenbatekoa denean, kobratzeko eskaeran bidali daiteke eta autentifikazioa eskatuko ez da. Stripek zuzenean aplikatzen du eskaera prezio tartean sartzen bada, eta Redsys-en eskatzen da aktibatzeko eta SCA eskaera momentuan bidaltzeko, baldin bada. Mundu offline-ra eramanda, denda fisiko batean txartelarekin ordaintzen duzunean, eta erosketa balioaren arabera pin-a eskatzen ez dizute ordaintzeko, noski, hori ez da hain nabarmena, telefono bidez NFC bidez ordaintzen baduzu, segurtasunagatik ordaintzeko metodoaren sarbidearen hatz-markaren eskaera beti eskatzen baitu, gutxienez erabiltzen dudan aplikazioarekin (CaixaBank).
TAR, “arriskutsua” dena, LWV-rekin antzekoa da, baina desberdintasunarekin, zenbateko askoz handiagoetarako da. TRA (Transaction Risk Analysis) esan nahi du. SCA TRA-ren aplikazio maximoa bankuaren araberakoa da Redsys-en kasuan, baina oro har, oso erresistenteak dira 250€-ko zenbatekoak aktibatzeko/ontzeko. Redsys-en TRA aktibatuz gero, eskatuko duzu aplikatzea eta Redsys-ek balorazioa egingo du bidali ala ez emitzailerako, baina kontuan izan arriskua zuena izango dela (geroago azalduko dudan bezala). Stripek zuzenean aktibatuta du eta 500€-ko zenbatekoetarako. Stripek arrisku analisia egingo du, eta ezer nabarmenik ikusten ez badu, TRA emitzailerako ordaintzeko eskaera bidaliko du, beraz, autentifikaziorik ez da egingo (bezeroaren emitzailak onartzen badu). Hurrengo taulan aurki dezakezun irudian hemen, arrisku analisia nola aplikatzen duten ikusi dezakezu TRA bidali ala ez.
Hori guztia oso interesgarria iruditu daiteke eta norbaitek pentsa dezake, ¡Ah, fantastikoa, beti TRA bidaltzen dut! Pentsamendu hori burura etor daiteke, ezta? Autentifikazio gutxiago, konbertsio gehiago, salmenta gehiago ¡Fantastikoa! «Orain ulertzen dut zergatik Stripe-n ordaintzean ez den hainbeste abandonu, oso gutxi autentifikatu behar direla».
Bai, arrazoia izango zenukete, arrazoia da, LWV edo TRA bidaltzen duela transakzio gehienetan, eta horrek ia kasu guztietan autentifikazioa eskatzen ez duela, bezeroaren emitzailak onartzen badu, izan ere, agian emitzailak/bankuak TRA onartzen ez du edozein arrazoirengatik eta autentifikazioa eskatzen du. Eta aurretik esan dudan bezala, Redsys-i eskatzen ahal diozue aktibatzea. LWV ia berehala izango litzateke, eta TRA-k agian denbora gehiago behar du. Baina adi, SCA hauek aktibatzeak zer ondorio izango dituen jakinaraziko dizute eta agian ez duzu ideia ona irudituko, ezagutza botere da, batez ere erabakia hartzeko.
SCA-etan sakonduz, SCA bidaltzen duen entitateak (merkataritza edo bankua), LWV edo TRA izan, iruzur/lapurreta kasuetan ardura hartu behar du. PSD2/SCA-n sakonduz, iruzur kasuetan ardura hartu behar duenak TRA-ren onarpena bidaltzen duenak izan behar du ( Adyen-en sarrera honetan oso ondo azaltzen dute guztia) Azken finean, hau jartzen du:
2. Arrisku baxuko transakzioak – TRA (Transaction Risk Analysis)
Banku emitzailiek zenbait transakzio arrisku baxukoak izan daitezke. Horretarako, emitzaileren, eskuratzaileren edo biak aldi berean iruzur mailen mailen arabera oinarritzen dira. Kasu hauetan, salbuespena merkataritzak edo banku emitzailak eskatu dezake.
Kontrako kargu kasuetan ardura emitzailaren gain izango da, salbuespena eskatu badu, edo merkataritzaren gain, salbuespena eskatu badu.
Garrantzitsuena azken parrafoa da. Beraz, bankuak esango dizunaren pista bat duzu. LWV edo TRA aktibatu ahal dizkizute terminalean operazioa autentifikatzeko eskatzen ez duzun, baina txartela lapurtu bada (adibidez) eta banku emitzailak TRA onartzen badu, produkturik gabe geratuko zara (jadanik bidali baduzu) eta dirurik gabe, itzuli beharko duzulako. Autentifikazioa badago, nahiz eta pertsonak txartela eta telefonoa lapurtu badizkio eta zure webgunean erosi badu, inork ez du ezer erreklamatzeko. Dirua mantentzen duzu, txartelaren jabea eta banku emitzailaren arazoa da, argituko dute nor den erruduna, bankuak txartela azkar ezeztatzeko denbora izan ez duelako, edo txartelaren jabeak lapurreta berehala salatu ez duelako. Baina ziur nago ez zarela.
Eta orain pentsatzen ari zara, “Ah, Stripe da TRA bidaltzen duena, ¡Esan beharko du!”. Eta logikoa litzateke kasu honetan, zeren zure izenean TRA bidaltzen ari da, baina hau da guztia arazoa. Ez, zure izenean TRA bidaltzen ari da, horretaz jakin gabe eta 500€-ko eskaeretan dituen ondorioak ezagutzen ez dituen bitartean, eta iruzur kasuetan arazoa zuena izango da disputa bat irekiz, hau da, jendeak autentifikatu ez dezan egiten ari da, merkatariei horren ondorioak azaldu gabe, baina arazo bat izanez gero, merkataritzak arriskua onartu gabe jasan beharko du. Horregatik diot arazoa dela. Hau da, txartel lapurreta/klonatze mafiek zure webgunean pasatzen badute eta erabiltzaile eta txartel desberdinekin 10.000€-ko balioa duten produktuak erosten badituzte, ez duzu ezer gertatuko Stripe-rekin, TRA bidaliko du, ez dira autentifikatu, eta disputa bidez pasatuko dizute arazoa, txartelak lapurtu edo klonatu direla eta erosketa autentifikatu gabe geratu direla salatzean. Baina ez duzu dirua itzuli beharko, baita kontrako kargu izeneko tarifarik ere, hau da, ez duzu dirurik eta produkturik izango, horretarako ordaindu beharko duzu. Stripe-ren kasuan, galduko duzun disputa bakoitzeko 15€ izango dira (pentsa 10.000€-ko horietan ehunka eskaera desberdin egon daitezke) + 20€ dirua itzultzeko (berdina, ehunka bezero/eskaera izan daitezke), eta ez dakit zein % izango den isunaren balioan. Baina 15€ + 20€ transakzio/bezero bakoitzeko, zenbatu. Agian, kargu guztiekin, 10.000€-ko iruzurra baino gehiago ordaindu beharko duzu, produktuen galera kontuan hartu gabe.
Hau guztia Stripe-ren aurkako alegatua da? Ez, besterik gabe, ez dute kontatzen, egun batean sorpresa oso desatsegina izan ez dezazun. Orain, gutxienez, jokoa nola den jakin duzu, eta datu guztiak eskuan dituzula erabaki dezakezu.
Stripek onura batzuk ditu Redsys-en aldean, kontratazio erraztasuna, transakzioen kudeaketa panelak, fakturazioa, etab. Balio gehigarria izan daiteke bere erabilera bultzatzeko. Baina kontrako aldetik, Redsys-ek segurtasun handia eta tasak oso baxuak ditu.
Une honetan agian pentsatzen ari zara, “Niri inoiz ez zait horrelakorik gertatu”, egun batean gertatu daiteke eta aurreko egoera antzeko batean aurkitzen zara. Baina orain ezin duzu esan ez zenuela espero edo ez zenuela ezagutzen, baina hala ere TRA arriskua onartzeko prest bazaude, eta askoz gutxiago LWV, Redsys-en ere izan dezakezu eta Stripe-k aplikatzen dituen komisioetatik askoz baxuagoak (eta are gehiago egin zuten igoerarekin), eta nire Redsys plugin WooCommerce-rako LWV eta TRA eskatzea ahal izango duzu (arriskua onartzeko prest bazaude) Redsys-i (terminalean aktibatuta badituzte) eta baita checkout-ean webgunea utzi gabe kreditu txartelaren formularioa izatea ere, Redsys-ekin ere egin daiteke, nire adibide dendan egiaztatu dezakezue.
LWV aktibatzea oso interesgarria izan daiteke terminalean 30€-ko ordaintze guztiak autentifikatu ez daitezen, baina TRA-rekin arduratsu izan behar da. Dudarik gabe, TRA bidaltzeak, Redsys-ekin ere egin dezakezun bezala, salmentak handituko ditu, autentifikazioa hainbeste eskatzen ez duelako, baina iruzur egiteko aukera handituko du.
Orain benetan PSD2-ren funtzionamenduari buruzko informazio guztia duzu. Uste dut SCA-rekin funtzionamenduari eta arriskuei buruzko iruzkin argi hau baino gehiago ez duzula aurkituko. Une horietan, irakurri duzunaren ondoren, benetan erabaki dezakezu zer nahi duzun helburu bat lortzeko, ondorioak kontuan hartuta. Orain baloratu dezakezu nola ordaintzeko modua jorratuko duzun, autentifikazio gehiago ez erabiltzeko SCA inolako erabiliz lasai bizitzeko, LWV aplikatuz segurtasun eta arrisku baxuaren arteko oreka izateko, edo TRA erabiliz salmentak maximizatzeko autentifikazioak murriztuz, baina arriskuak maximizatuz.
Ikusten duzunez, Redsys-ekin ere autentifikazioak gutxira murriztu eta Stripe-ren moduan ordaintze abandonuaren bidez salmentak maximizatu ditzakezu, LWV eta TRA SCA eskatuz eta aktibatuz, baina Redsys-en arriskua onartzeko erabakia zurea da, eta Stripe-n ezagutzarik gabe, merkatarien gehiengoak onartzen duen arriskua da. Eta okerrena da, gehienek interpretatzen dutela Stripe-k salmenta gehiago dituela teknologia hobea duelako.
Pues muy interesante y tiene sentido. También para explicar a los comerciantes el porqué de tantos pasos, autenticaciones,etc. que a veces se reclama para hacerles más fácil el camino a los compradores, pero no tienen en cuenta que los pasos de seguridad tienen su porqué…
Está claro que según el tipo de negocio se puede plantear más uno el tomar una u otra alternativa. Para tiendas de productos como comentas donde de pronto pudieran hacerte grandes cantidades de pedidos pues igual hay que andarse con más ojo.
Lo que creo que para poco volumen de ventas, es más económico Stripe y pagar por cada transacción que Redsys que creo que funciona por cuotas mensuales y adicionalmente algo por transacción, o según condiciones del banco ¿no? La verdad, esperaba ver incluido algo en cuanto a comparativa de costes.
Hola Taisa, gracias por comentar 🙂
Stripe funcina con un fijo por transacción (0,25€) más un porcentaje de esta (1,5%), mientras Redsys en solo un porcentaje por transacción que no suele superar el 0’45%, y mucha gente incluso ha conseguido mediante negociación con su banco rebajarlo hasta el 0’20%. No hay cuota de mantenimiento en Redsys siempre y cuando llegues a un mínimo facturado, que cada banco pone el suyo. Por regla general suele estar sobre los 300-400€ de facturación.
En esta entrada me he enfocado más al tema técnico que no al económico, porque creo que hay muchísmo más desconocimientom por no decir nulo de como funciona la PSD2 y de los «trucos» que hay para que haya más «frictionless» (sin autenticación) pero asumiendo sus posibles peligros y consecuencias.
Saludos
Buen artículo sin embargo hay una parte que probablemente no conozcas. El motor de riesgo de stripe está basado en cientos de variables sobre la transacción, machine Learning e inteligencia artificial. Y sabe cuando enviar la exención y cuando no. Ten en cuenta que todos pagamos varias veces al mes a través de stripe y nos conocen. Todo eso Redsys ni se lo huele. Bastante tienen con poner reglitas estáticas que para algunos comercios pueden valer y para otros no. Y no son sólo las exenciones a la psd2. También al dotar de mucha mayor información a las operaciones, el emisor no siempre pide el challenge y las operaciones tienen el mismo nivel de protección que si se hubiera producido.
Muy posiblemente, Martin.
Muchas gracias por tu aporte 🙂
Sí y no. Por ejemplo, CaixaBank con Redsys (Cyberpac) tiene un completo que cuesta entre 2cts y 0,5 cts por transacción (Addon Sales Conversion) donde la empresa global payments (bastante reputada a nivel mundial) es la encargada de hacer el análisis de riesgo. Yo, de las operaciones que van via tarjeta (no cuento Apple Pay y Google Pay) solo tengo que autenticar un 8% aproximadamente, y normalmente es debido a que es de un importante bastante grande la operación a la vez que es de un país de fuera de Europa, ha hecho muchas compras …
Si tu banco tiene algo parecido entonces es importante considerar si sale a cuenta un Stripe o mejor pelearse unas semanas con bancos, romperse un poco (bastante) la cabeza integrando todo y pagar comisiones de hasta el 0,05% o 0,01% cuando es entre comercio-tarjeta del mismo banco.
Stripe lo que mas me gusta es todas las opciones de pagos incluidas que tiene, ya que no tienes que abrirte cuentas en cada sistema de pagos, solo Paypal, tiene klarna, sepa, etc incluidos en tu cuenta de Stripe, ademas que solia obtener mas conversion dado que no falla tanto como redsys, que veo denegación todos los días, y de altas compras importantes en mi tienda, lo peor que tiene Stripe he incluso Paypal, en mi opinión y experiencia de comerciante por casi 5 años, es que puedes levantarte un día y te inhabilitaron la cuenta sin retorno, todo el dinero que tenias estará bloqueado por 4 meses y con el riesgo muy alto de que Stripe & Paypal lo reembolse a los clientes.