Vlákno názorů k článku Kdy evidovat platbu kartou v e-shopu? Zásadní otázka je rozlousknuta od Jenda - > Ještě jednou:Ještě jednou: po zaevidování nemusíte nic...

> Ještě jednou:Ještě jednou: po zaevidování nemusíte nic ukládat. po zaevidování nemusíte nic ukládat.

Nemusím, ale když při kontrolním nákupu vydám účtenku s nějakým FIK a finančák se pak bude dušovat, že takový FIK nikdy neviděl, tak mám smůlu. Je to další možnost zneužití už tak šíleného systému.

> Pokud byste měl pocit, že za vás někdo po nějakou dobu účtoval kradeným certifikátem, nejspíš by šlo v nějakém řízení takové záznamy zneplatnit.

Tím jste porušil povinnost uloženou v § 16 a podle § 29 zaplatíte 50 litrů pokutu ;).

Nemají to vyřešené, protože nevědí jak to třeba řešit v souladu se zákonem. Ďábel je ukrytý ve způsobu používání té knihovny pro propojení s EET a zpracování dat, které poskytne.

Odhaduju, že těch 90 % celého problému už mají obchody vyřešené, neb to je stará věc a nijak to nesouvisí s EET.

EET knihovna je jen ta menší část, která se musí řešit. Zajišťuje odeslání a přijetí zprávy.

V shopu musí být řešeno také kdy, jak a kolik se má odesílat. Musí se řešit ukládání dat, občasná selhání spojení, občasné chyby na straně shopu, různé platební metody, různé sazby daně, MOSS, různé verze shopu, zobrazení informačního oznámení, zašifrované uložení certifikátu a hesla, uložení odesílaných a přijímaných dat a samozřejmě nějaké grafické rozhraní pro všechno to nastavení.

Odhaduju, že samotná knihovna pro EET je asi tak 10% celého problému.

Ukládání zpráv na cizích serverech, službami, které to často nabízejí zdarma jako doplněk ke své hlavní nabídce, to zní na první pohled a před první kontrolou docela lákavě.

Jako hlavní potíž vidím dostupnost těch uložených dat. Některá služba může skončit nebo tu evidenci zruší a po letech mi přijde kontrola a mám problém. Nikdo třetí totiž za nic nebude odpovídat. Vše je jen na provozovateli shopu. Jestli to v dobré víře svěří někomu externě, je to jeho volba. Praxe ukáže, jaké problémy to přinese. Třeba možnost získání stovek certifikátů a hesel u věhlasné služby bude pro hobby hackery určitě lákavá nabídka.

P.S. Ukládání všech odesílaných a taky přijímaných dat je základ. Sám jsem si to takto udělal.

> kdyby nastala, obhájíte libovolný FIK

Pokud o tom budou vědět…

Že by jako online query do nějaké databáze, nad kterou nemám vůbec kontrolu?

Z FIK nejde ověřit, že transakci viděli a že FIK vygenerovali oni, ne?

- a jak teda potom funguje ověření účtenky zákazníkem?

Z FIK nejde ověřit, že transakci viděli a že FIK vygenerovali oni, ne? Takže když ztratí data/někdo jim smaže data/whatever, tak nemáš jak prokázat, že sis FIK nevymyslel. Proto právě potřebuješ tu zprávu, kde je podepsaná dvojice BKP a FIK, přičemž BKP je hash údajů na účtence.

Dulezite je mit FIK, to je defakto jedine co pripadna kontrola bude kontrolovat.

> knihovna od Ondřeje Nováka

Jestli myslíš tohle, tak po zběžném kouknutí do zdrojáku mi přijde, že se zavolá send, to zavolá processData, a to zavolá nějakou WSDL věc, která to postne a pak si z přijatého XML vybereš chyby, varování a FIK. Opět mi tam nějak chybí ověření podpisu odpovědi a její uložení.

Nebo jsem to celé pochopil blbě a ten Babišův podpis nijak důležitý není?

Jasně, PayU mělo určitě připravenou spoustu scénářů, knihoven a hotových řešení - nepochybuju že se na to připravovali se stejnou poctivostí s jakou reagují na požadavky na podporu :-))
Existuje spousta zůsobů jak implementovat EET - jsou dostupné open-source knihovny, z nichž minimálně 3 jsou 100% funkční (viz zmiňovaný slevomat, knihovna od Ondřeje Nováka a podobně), navíc existují služby jako API-EET takže co se týče implementace no problem - obchodníci mají čas a klidně můžou ještě chvilku přešlapovat :-)