Vlákno názorů k článku Payment Request API: informace o platební kartě bezpečně v prohlížeči od martin - V článku je chyba - obchodník se k...
-
V článku je chyba - obchodník se k údajům o kartě dostane, je na něm, aby pak nějak z karty peníze strhl. Viz výš nebo screenshoty na https://ispis.cz/sandbox
Jinak přijde mi, že je to primárně namířeno proti VISA / MasterCard, resp. na jejich zisky z poplatků za platbu kartou (které platí obchodníci). Takhle uživatelé začnou platit přes AndroidPay nebo ApplePay a poplatky si naúčtuje Google/Apple.
Osobně proti tomu nic nemám - v kamenném obchodě je jednodušší platit mobilem, než někde lovit kartu, a na webu asi taky radši zaplatím přes AndroidPay, i když to vyzkoušené ještě nemám, protože to musí podporovat moje banka, což zatím v ČR nehrozí...
-
Kolemjdouci (neregistrovaný)
Jestli to chapu spravne, tak pri placeni pres AndroidPay ma ve finale Google informace o mnou zaplacenych sluzbach a zbozi, coz je asi posledni kousek skladacky, ktery jim chybi k dokonalemu cileni reklam.
Dost bylo velkeho bratra, radeji si pockam na implementaci plateb pres NFC od moji banky. -
Je to ještě horší, google má i offline payment data - https://www.bleepingcomputer.com/news/google/google-will-track-your-offline-credit-card-payments-to-make-advertisers-happy/
Píše se tam, že to platí pro US, ale zbytek je jen otázkou času.
-
Míra (neregistrovaný)
Myslím si že to chápete naprosto správně a zcela jistě se najde spousta těch kteří budou nadšeně odesílat svoje údaje o platbách a kartě do googlu protože je to cool a trendy.
Zároveň tím budou "bojovat" proti těm "zlým komerčním bankám", které si účtují poplatky za transakce a sledují uživatele. Zatímco google dělá všechno zadarmo a nikoho nijak nesleduje.Jinými slovy: Na světě je mnoho hrozných havárií ale nejhorší je srážka s blbcem ;o(.
-
V článku je chyba - obchodník se k údajům o kartě dostane, je na něm, aby pak nějak z karty peníze strhl. Viz výš nebo screenshoty na https://ispis.cz/sandbox
Jak jste na tohle přišel? V požadavcích se zadává platební metoda, která se má pro platbu použít – typicky platební brána. Prohlížeč pak platební údaje předává přímo té platební bráně, webová stránka dostane až výsledek platby. Jinak by celé to API nedávalo žádný smysl – předvyplnit údaje o platební kartě do webového formuláře umí prohlížeče už dnes, není k tomu potřeba žádné API. -
Obchodníkovi se platební údaje předají jedině v případě, kdy se použije platební metoda
basic-card(která je použitá v tom odkazovaném příkladu). Což je zjevně fallback aby to fungovalo i tehdy, když se obchodník s prohlížečem neshodnou na žádné jiné podporované metodě. Ale určitě to není smysl celého API – to je naopak právě to, aby se obchodník údaje o kartě vůbec nedozvěděl. -
No jo, ale žádné advanced-card tam není, ani zmíňka, ani náznak.
Jinak ono ten problém s číslem karty a CVV není tak žhavý - kromě použití na jiném webu moc s těmi údaji nadělat nejde. Aby je mohl obchodník použít, musí být PCI DSS certifikován, což není žádná sranda a v ČR to má jen pár subjektů.
V ČR je, soudě i podle reakcí tady v diskuzi, nemyslitelné dát někam to číslo karty, ale jak říkam, v cizině je to poměrně běžné, asi jako když dáte kreditku někomu v krámu.
Podle mne je smyslem začít platit přes AndroidPay/ApplePay (čemuž osobně fandím). Možná API zapracují klasické platební brány, kdy přes ty third party payment methods zapracují např. platbu na dobírku, bankovními "tlačítky", QR kódy apod. A i kartou, kdy budou strhávat peníze z karty za obchodníka tak, jak doposud.
-
Ne, žádné
advanced-cardtam opravdu není. Ony tam totiž vůbec nejsou platební metody vyjmenovány, ani tabasic-card, protože se počítá s tím, že budou postupně přibývat. Místo toho je tam napsané, že platební metoda je určená ID a je tam odkaz na standard o těch ID. Metodabasic-cardje uvedená jenom v příkladech a na závěr je uveden odkaz na standard definující tuto metodu mezi informativními odkazy.Takže to tvrzení, že při použití tohoto API dostane obchodník údaje o kartě, není pravdivé. API je obecné a konkrétní platební metody záměrně neřeší, a záměrně je navržené tak, aby bylo možné platební metody navrhnout tak, že se obchodník ke kritickým údajům platby nedostane.
Podle mne je smyslem to, aby se citlivé údaje nezadávaly do webového formuláře, často navíc na webu obchodníka. Pokud se ten standard ujme, klasickým platebním branám nezbyde nic jiného, než to implementovat, pokud budou chtít přežít.
-
Mně by se také moc líbilo, kdybych jako obchodník tomu API řekl moje číslo účtu a prohlížeč se nějak magicky postaral o zbytek. Ale tak to nefunguje.
Souhlas, že metody budou přibývat, ale nemyslím si, že ta basic-card je jenom příklad a že nepřežije. Našel jsem ještě toto: https://blog.midkemia.fr/web-payments-paymentrequest-api/ podle kterého existuje varianta, že obchodník dostane certifikaci na to, že ta čísla může zpracovávat. (A získat tu certifikaci je tak obtížné, že zneužívat a riskovat reklamace a ztrátu certifikace ho ani nenapadne.)
Ano, tím "obchodníkem" můžou být klasické platební brány, to jsem psal také, v tom se shodneme. Ale také si umím představit spoustu malých obchodníků, kteří budou podporovat např. jen AndroidPay/ApplePay nebo jinou lokální platební metodu (bankovní tlačítka nebo QR kódy u nás, WeChat v Číně apod), kde příjem peněz bude jednodušší a obchodník nebude odkázán na platební bránu.
Jinak ještě k těm kartám - obchodník za přijetí platby kartou platí poplatek několik procent z částky, minimálně však cca 25 centů. Pro větší částky nebo pro mikroplatby jsou tak platby kartou nepoužitelné.
-
Vy jako obchodník API řeknete: „Podporuju tyhle metody platby. Tady je seznam položek s cenami, které chci zaplatit, celková částka, podporuju tyhle způsoby dopravy a požaduju, aby uživatel zadal e-mail a adresu pro doručení. Zobraz uživateli požadavek na zaplacení.“ Prohlížeč to zpracuje, z podporovaných metod platby vybere ty, které sám podporuje, dá uživateli na výběr, nechá ho vybrat způsob dopravy, doplnit e-mail a doručovací adresu, pak proběhne uživatelem vybraný způsob platby (třeba z mobilu odešle prémiovou SMS) a obchodníkovi se vrátí informace „Platba úspěšně proběhla, tady jsou identifikační údaje platby.“
Souhlas, že metody budou přibývat, ale nemyslím si, že ta basic-card je jenom příklad a že nepřežije.
Psal jsem, že je to uváděné jako příklad v dokumentaci – což vůbec neznamená, že by to byla jediná možná metoda. V dokumentaci se často uvádějí i vymyšlené příklady… Nepsal jsem, že nepřežije – jenom že je to fallback, poslední možnost, aby se používání vůbec rozjelo. Ale jakmile budou dostupné jiné způsoby plateb, uživatelé budou nabádáni, aby basic-card nepoužívali, protože je to nebezpečné a poskytují tím údaje o kartě přímo obchodníkovi.Pro malé obchodníky je dnes naopak výhodnější použít platební bránu než implementovat jednotlivá bankovní tlačítka a nejspíš ještě platbu kartou. QR kód pro tohle není varianta, protože tam nemáte to zpětné potvrzení, že platba proběhla. QR kód je jenom snazší způsob, jak dát klasický offline příkaz k úhradě. Do toho API by to samozřejmě také šlo zapojit, ale nebude tam ta výhoda online potvrzení platby.
-
U basic-card se nevrátí identifikační údaje platby, ale karty (to je fakt). U jiných metod to možná můžou být identifikační údaje platby, ale to UI pro zadání čísla karty už nebude tak hezké - nebude zaintegrované v prohlížeči / nastavení telefonu.
Jako zprovozňovat basic-card abychom pak tvrdili, že je nebezpečný a že ho nemáte používat, mi nezní jako plán ;-). Ale OK, možná se pletu.
Jinak podepsat smlouvu s platební bránou taky není jen tak (musí proběhnout Know Your Customer - fyzicky ověřit klienta,..). Těm malým může stačit, že se to jen nějak napřímo napojí na jejich PayPal / Google / AppleID účet a fungují, i když bez karet...
-
U jiných metod bude UI takové, jaké ho autor pluginu pro daný typ platby udělá. Dá se předpokládat, že třeba platební brány budou mít UI stejné, jaké mají na webu platební brány. Pokud to nebude platba kartou, nebo se nebude číslo karty do prohlížeče zadávat, políčko pro zadání čísla karty v UI vůbec nebude…
basic-cardbudou potřebovat minimálně ty weby, které potřebují znát číslo karty, např. proto, že si u nich kupujete předplatné a částka je pak strhávána opakovaně. Takže je dost nepravděpodobné, že by tenhle způsob platby úplně zanikl. Ale rozhodně to není důvod, proč celé to API vzniklo – nedává smysl vymýšlet a implementovat takhle komplexní API, které by ve výsledku umělo to samé, co obyčejný webový formulář a předvyplněné údaje v prohlížeči. -
Co má tedy obchodník uloženého, aby mohl za rok strhnout z mé platební karty částku, která odpovídá ročnímu předplatnému? Ta částka ani nemusí být stejná jako u první platby. To obchodník vydavateli karty řekne jenom „zopakuj transakci XY, akorát změň částku na Z“? Z hlavy si vybavuji dva nebo tři případy předplatného, určitě Microsoft a JetBrains, nejspíš i Google, a ve všech případech tam musí být zadané údaje o mé platební kartě – takže možná teoreticky mají možnost udělat to jinak, ale prakticky předplatné realizují pomocí zapamatování údajů o kartě.
-
VISA a MasterCard má API pro PCI DSS compliant subjekty (platební brány, Amazon, PayPal, Microsoft, Google,...) a v rámci toho API jde strhnout z karty peníze, i opakovaně.
Platební brána pak má API, kde obchodník řekne autorizuj mi částku X, případně autorizuj mi částku X jednou za rok apod.
Na recurring payments tedy obchodník nepotřebuje znát číslo karty.
-
Když chcete strhnout nějakou částku, musíte nějak identifikovat, odkud se má ta částka strhnout. Např. při převodu z bankovního účtu je to identifikováno buď IBAN, nebo tím, že jde o českou banku, číslem účtu a kódem banky. Na způsob identifikace toho, odkud se má ta částka strnout, jsem se ptal, a vy jste na to ve své odpovědi zapomněl.
Např. u JetBrains mi bude v lednu končit předplatné, které jsem zaplatil cca před dvěma roky za nějakou zaváděcí cenu. Mám nastavené automatické obnovování předplatného po roce, teď už se obnoví za standardní cenu. Mezi tím mi vypršela platnost platební karty, se kterou jsem to předplatné před těmi dvěma roky zaplatil, o čemž mi přišel e-mail a já jsem zadal údaje o nové platební kartě. Údaje o kartě prý neukládá přímo JetBrains, ale zprostředkovává to Adyen. Já si myslím, že v lednu ta platba proběhne na základě toho, že jsem jim dal a oni mají uložené číslo mojí karty, měsíc expirace, jméno držitele karty a bezpečnostní kód (CVV). Při zadání údajů o kartě jí ověří tak, že zablokují 1 dolar, ale pak částku zase uvolní. Podle vás to číslo karty už znát nepotřebují a tu částku by si mohli v lednu strhnout jinak, na základě jiných údajů, tak by mne zajímalo, na základě jakých a jak je získali.
-
Způsobů plateb kartou je několik, to, kde se používá CVV a případně zadává kód z autorizační SMS jsou internetové platby. Další typ plateb jsou platební terminály, kde se transakce ověřují PINem, a pak existuje úplně ten nejstarší typ plateb, který pochází z USA a je založený na důvěře – k provedení platby stačí jen znát číslo karty.
-
Jaký typ služby konkrétně používají nevím. Ale myslím, i vzhledem k jejich zaměření, že nemají poskytovatele zaměřeného na český trh, ale spíš nějakého globálního poskytovatele (Adyen apod.). A všechny ty bezpečnostní nadstavby u karet jsou vlastně volitelné… To přijímání transakcí s nižším stupněm ověření bude určitě vyváženo cenou (ať už přímo, nebo schovanou v objemu transakcí), protože provozovatel takové služby na sebe bere větší riziko, že strhne nějakou platbu neoprávněně a banka mu jí nezaplatí.
ČLÁNKY DO MAILU