> 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 ;).
Ještě jednou: po zaevidování nemusíte nic ukládat. Leda krátkodobě, data k opakovanému odeslání, v případě neúspěchu. Ani taková data teoreticky memusíte ukládat, pokud by je obsluha později zadala znovu.
Kontrola "po letech" se nepředpokládá. Kontrolovat se bude leda účtenka z kontrolního nákupu.
Cerifikát lze zneplatnit, pak už s ním nikdo nic nezaeviduje. 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.
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.
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.
> 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 :-)