To není tak docela pravda. Záleží jak to máte nastaveno.
U nás se peníze stáhnou hned automaticky (v souladu se smlouvou).
Samozřejmě máme možnost je online (a hlavně bezplatně) vrátit (refund) jedním kliknutím. Případně i část peněz, pokud něco není.
Jinak mi ale prijde logictejsi, ze prebrani zbozi potvrdi kupujici, az pak by se transakce mela uzavrit. Tohle by možná fungovalo v ideálnm světě, ale tady bych nechtěl vidět ty tahanice se "šibaly".
Ano to hlasite jako prodavajici. Pokud to osvindlujete, promptne na to prijdou a zaplatite pokutu. Potvrzeni obratem projde pri prodeji software metodou ke stazeni, ale u balenych veci musite pockat minimalne do vecera a teoreticky si to mohou namatkou i overovat. Vetsinou to ale uda zakaznik, ktery vi, ze se penize nesmi strhavat predem a prijde mu divne, ze ma penize strzene a balik nema uz kolikaty den. Vsak si prectete smlouvu.
To hlasim ja jako prodavajici? A bez toho mi zadne penize na ucet neprijdou? Tak to bych si na to udelal robota, ktery to potvrzuje obratem, prinejhorsim i jako makro, ktere klika na predem urcena mista te jejich aplikace. Jeste nez se podivam, jestli to zbozi mam skladem.
Jinak mi ale prijde logictejsi, ze prebrani zbozi potvrdi kupujici, az pak by se transakce mela uzavrit. Jeho banka by mu nekde pi zobrazeni pohybu na jeho uctu mela ukazat checkbox, ktere transakce jeste nejsou ukoncene a on by ty, kde jiz zbozi ma, odfajfknul.
Jenze u 3D Secure dostanete zaplaceno po odeslani zasilky. Takze musite pomoci te aplikace nahlasit bance, ze zasilka byla odeslana, ona vam provede transakci a sdeli vysledek. Tam neni zadne html, mailbox ani nic podobneho. S rozhranim pro uzivatele to nema ani zbla spolecneho.
Nechapu, o cem je rec. Kdyz si delam tu svoji html stranku, neni problem php skriptem odeslat CSV, XML nebo kline i DBF soubor do nejakeho mailboxu, odkud si to i automaticky muzu importovat, kam chci. Tak to delam odjakziva, jen mi tam chybi udaje o zaplaceni a dokud bude CSOB chtit 13 tisic, tak jeste dlouho budou.. :-(
Implementace platby je naprosto primitivni. Tragedie je implementace propojeni s ucetnictvim. Na to totiz dostanete akorat windows aplikaci do ktere prepisete rucne informace, ona provede transakci a vysledek si potom zase rucne prepisete do ucetnictvi. Platba pres klasickou platebni branu ebanky je radove jednodussi na zpracovani na strane obchodu.
Nesouhlasim s autorovym tvrzenim, ze implementace je narocna. Popisu, jak si to predstavuji ja. Jeste jsem to ale nedelal, tak mne opravte, kdyz se mylim:
Na strance eShopu se pod tlacitkem Platit spusti script na serveru banky eShopu, kteremu odevzda castku a cislo transakce. Banka eShopu na strance s vyberem typu karty spusti jiny skript na serveru vydavatele karty, co zobrazi klientovi okno, kde se klient smluvenym zpusobem autentizuje a hned i "provede" (rezervuje penize). Server vydavatele karty odevzda (pres prohlizec kupujiciho) serveru banky eshopu podepsane potvrzeni a ta spusti skript na serveru eshopu, ve kterem odevzda vysledek overeni.
"slozitost" spociva akorat v tom, ze ten vysledek je podepsan bankou eShopu a server eShopu jej musi umet overit. A od bank a vydavatelu karet se pozaduje, aby jejich servery mezi sebou (skrze prohlizec zakaznika a https) umely komunikovat.
ČLÁNKY DO MAILU