Najčastejšie otázky a odpovede

Kde nájdem prihlasovacie údaje do API?

Prihlasovacie údaje nájdete v klientskom portáli v sekcii „Integrácia“ > „Nastavenia obchodu“ a potom „Prepojenie obchodu“.

Čo je login a čo heslo do API?

Login je identifikátor prepojenia obchodu (vo väčšine prípadov šesťmiestne číslo) a heslo patrí k tomuto identifikátoru. Oba tieto údaje sú uvedené v klientskom portáli v sekcii „Integrácia“ > „Nastavenia obchodu“ > „Prepojenie obchodu“.

Čo je založenie na pozadí vs. založenie presmerovaním a prečo je založenie na pozadí lepšie?

Založenie platby na pozadí slúži na bezpečné a garantované založenie platby s parametrami, ktoré korešpondujú s e-shopovou objednávkou. Platca teda nemôže ovplyvniť napr. cenu a musí ju uhradiť v plnej výške.
Naopak, založenie presmerovaním sa používa napr. pri daroch, kde môže platca ľubovoľne meniť sumu platby.
Vo väčšine prípadov preto odporúčame založenie platby na pozadí (volanie z e-shopu na API Comgate).

Prečo nie je dobré začať implementáciu v SOAP?

SOAP podporujeme z historických dôvodov a už sa nevyvíja, preto nie je vhodné začínať novú implementáciu v SOAP.

Ako nastaviť IP whitelist?

API Comgate je chránené pomocou IP whitelistu. Pri každom e-shope evidujeme IP adresy, z ktorých je možné komunikovať s naším API. Pridanie povolených IP adries môžete vykonať v klientskom portáli v sekcii „Integrácia“ > „Nastavenia obchodu“ > „Prepojenie obchodu“.
Kontaktujte správcu svojho hostingu a získajte všetky odchádzajúce IP adresy, z ktorých môžu vaše servery komunikovať. Poskytovatelia hostingu často zverejňujú zoznam IP adries na svojom webe.
V prípade, že má váš server dynamickú IP adresu, môžete kontrolu IP whitelistu v klientskom portáli vypnúť. Pri takomto nastavení venujte maximálnu pozornosť zabezpečeniu komunikačného hesla.

Čo sa má nastaviť v PENDING, PAID a CANCELLED URL v prepojení obchodu?

Je potrebné vyplniť URL, ak používate HTTP POST alebo REST protokol (pri SOAP-e to nie je nutné). Prvé tri URL slúžia na presmerovanie používateľa, posledná URL slúži na odovzdanie výsledku na pozadí. Bez správne nastavených URL sa e-shop nemusí dozvedieť výsledok transakcie.
Ak nevyplníte „pending URL“, na platobnej bráne sa nebude zobrazovať tlačidlo „Návrat do e-shopu“.
PENDING, PAID a CANCELLED URL sú adresy endpointov v e-shope, kam presmerujeme platcu z platobnej brány (napr. pri úspešnej úhrade). URL pre odovzdanie výsledku platby slúži na komunikáciu nášho API s e-shopom (odovzdanie výsledku platby do e-shopu).

Ako nastaviť URL?

Je potrebné vyplniť URL, ak používate HTTP POST alebo REST protokol (pri SOAP-e to nie je nutné). Prvé tri URL slúžia na presmerovanie používateľa, posledná URL slúži na odovzdanie výsledku na pozadí. Bez správne nastavených URL sa e-shop nemusí dozvedieť výsledok transakcie.
Ak nevyplníte „pending URL“, na platobnej bráne sa nebude zobrazovať tlačidlo „Návrat do e-shopu“.

Ako nastaviť založenie presmerovaním?

Založenie presmerovaním je potrebné najskôr povoliť v prepojení obchodu v klientskom portáli v sekcii „Integrácia“ > „Nastavenia obchodov“ > „Prepojenie obchodu“.
Nie je potrebné vyplňovať IP whitelist a nie je nutné posielať heslo pri zakladaní požiadavky. Tento typ založenia nie je preferovaný a slúži iba pre jednoduché aplikácie typu darovanie peňazí.

Kde nájdem príklady v PHP?

Príklady v PHP nájdete na stránke API dokumentácie.

Čo znamená parameter test?

Parameter test pri platbe rozhoduje, či ide iba o simuláciu úhrady, alebo o reálnu úhradu (napr. platobnou kartou). Typicky sa používa pred nasadením do produkcie na otestovanie funkčnosti platobnej brány na konkrétnej platbe.

Ako nastaviť e-mail na zasielanie chýb?

V klientskom portáli v sekcii „Integrácia“ > „Kontaktné údaje“ je vhodné nastaviť e-mail na zasielanie chýb. Viac adries môžete oddeliť bodkočiarkou.
Developer potom dostane chyby (napr. nesprávnu kombináciu meny a platobnej metódy) z API priamo na e-mail.

Kde nájdem zoznam povolených metód v API?

Odporúčame aktuálne metódy sťahovať vždy pri vygenerovaní košíka platcovi. Môžete ich získať API volaním – pozrite túto dokumentáciu.

Ako môže správca organizácie vytvoriť pre svojho vývojára prihlasovacie údaje?

Správca organizácie môže vytvoriť pre vývojára prihlasovacie údaje v klientskom portáli v sekcii „Správa používateľov“ a potom „Pridať používateľa“.

Je e-mail pri založení transakcie povinný? Aké inštrukcie prídu platcovi na e-mail?

Pri každej platbe vyžadujeme vyplnenie e-mailu – buď zo strany e-shopu pri zakladaní platby, alebo následne od platcu pri zobrazení platobnej brány.
Pre zjednodušenie úhrady odporúčame vyplniť e-mail priamo z e-shopu. Platcovi pošleme e-mail s odkazom na zobrazenie stavu jeho platby. Zároveň môže pomocou zaslaného odkazu znova skúsiť predchádzajúcu neúspešnú úhradu.

Ako sa dá overiť stav platby?

Jediný bezpečný spôsob, ako overiť stav platby, je zavolať príslušnú API metódu – pozrite túto dokumentáciu.

Ako sa dostanem do testovacích logov / testovacích platieb?

Testovacie logy / testovacie platby sú prístupné, ak má používateľ rolu Tester (po nastavení nových práv je potrebné sa znovu prihlásiť).

Čo sa stane, ak nie je potvrdené prevzatie výsledku na pozadí HTTP kódom 200?

Ak nie je potvrdené prevzatie výsledku na pozadí HTTP kódom 200, vyvolá to opakovanie odovzdania až do maximálneho počtu 1000 pokusov.
Ak sa ani po 1000 pokusoch (rozložených v čase) nepodarí odovzdať stav platby do e-shopu, vygenerujeme chybový e-mail a odošleme ho e-shopu.

Ako postupovať pri opakovaných platbách?

Pri opakovaných platbách je kód 1500 spoločný pre nezaplatenie aj chybu. Odporúčame opakovať pokus o zaplatenie maximálne 5× s určitým časovým odstupom (napr. kvôli dennému limitu na účte) a potom vytvoriť novú iniciačnú platbu.
Opakované platby nemusia byť realizované z rôznych dôvodov – nedostatok prostriedkov na karte platcu, prekročený limit úhrad a pod.

Kto iniciuje opakovanie platby pri opakovaných platbách?

Pri opakovaných platbách iniciuje opakovanie platby vždy e-shop. Prvá platba je iniciačná a musí ju uhradiť platca. Následne už opakovaná platba prebieha bez jeho účasti.

Ako postupovať, ak má e-shop viac jazykových mutácií?

Ak má e-shop viac jazykových mutácií na viacerých URL adresách (napr. cz.eshop.com a sk.eshop.com), môže si vytvoriť viac prepojení obchodu a tam definovať odlišné návratové URL.
Každá mutácia e-shopu musí byť nahlásená kartovým asociáciám. Ak sa všetka komunikácia s platobnou bránou odohráva v jednom e-shope, stačí iba jedno nahlásenie kartovým asociáciám.
Viac prepojení obchodu je možné použiť napr. aj pri migrácii e-shopu na novú e-shopovú platformu alebo pri vytvorení testovacej verzie e-shopu.

Prečo nepodporujete IPv6?

IPv6 nie je možné zadať. Používame IPv4 whitelist, kde je uvedené, z akej IP adresy môže e-shop komunikovať s naším API.

Podporujete Google Analytics?

Google Analytics nepodporujeme. Viac informácií nájdete v tomto článku.

Kedy prebieha presmerovanie do e-shopu na URL pre stav PAID?

Presmerovanie do e-shopu na URL pre stav PAID prebieha do jednej hodiny od založenia platby. Ak platca pristúpi na platobnú bránu neskôr než hodinu od založenia platby, brána ho už do e-shopu sama aktívne nepresmeruje.
Dôvodom je, že platca často pristupuje z iného zariadenia (napr. z telefónu) na stav platby aj po dlhšej časovej prestávke. V e-shope už preto nemusí byť aktuálna session s objednávkou.

Do ktorého parametra sa má ukladať číslo objednávky z e-shopu?

Do parametra refId ukladajte ideálne číslo objednávky, aby bolo možné vykonať párovanie CSV/ABO do účtovníctva.

Je možné implementovať platobnú bránu v PHP 5? TODO stiahnuteľný zip

K dispozícii na stiahnutie je aj táto ukážka zastaralej implementácie v PHP 5. Ak je to možné, odporúčame použiť SDK (vyššie).