GP webpay - praktické scénáře

GP webpay - praktické scénáře

Verze: 2.1 Global Payments Europe, s.r.o. Vytvořeno 8.10.2015 Poslední změna 14.12.2015

GP webpay - praktické scénáře Autor dokumentu

Dimitrij Holovka

Správce dokumentu Schválil Verze

2.1

Stupeň utajení

Důvěrné

Historie dokumentu: Verze 1.0

Datum 1.7.2013

Provedl V. Keřka

2.0

8.10.2015

D. Holovka

2.1

14.12.2015

D. Holovka

Komentář Původní dokument: GP_webpay_Prakticke_scenare_072013_2.doc Nová šablona, verzování Fastpay Opakované platby PUSH platby Drobné opravy

Obsah 1.

Právní doložka ......................................................................................................................... 3

2.

Úvod ........................................................................................................................................ 4 2.1 Účel dokumentu – ukázkové scénáře z praxe ................................................................... 4

3.

Scénáře ................................................................................................................................... 4

3.1 3.2

Scénář 1: Nákup zboží – Vytvoření objednávky s autorizací ............................................. 4

3.3

Scénář 3: Dodání zboží - Převedení částky z účtu držitele karty na účet obchodníka ....... 8

3.4 3.5

Scénář 4: Dodání zboží – Chybně zadaná částka............................................................. 9 Scénář 5: Storno objednávky .......................................................................................... 10

3.6

Scénář 6: Reklamace objednávky držitelem karty ........................................................... 11

3.7

Scénář 7: Uzavření objednávky ...................................................................................... 12

3.8 3.9

Scénář 8: Vymazání objednávky ..................................................................................... 13 Scénář 9: Předvyplnění údajů o platební kartě na platební bráně ................................... 14

Scénář 2: Nákup zboží – Okamžitý požadavek na převod částky z účtu držitele karty ...... 7

3.10 Scénář 10: Opakované platby ......................................................................................... 15 3.10.1 Registrace „master“ platby ....................................................................................... 15 3.10.2 Provedení „následné“ platby .................................................................................... 15 3.11 Scénář 11: PUSH platby – zkrácený platební link ........................................................... 16 3.11.1 Založení PUSH platby.............................................................................................. 16 3.11.2 Provedení platby zákazníkem .................................................................................. 16

Global Payments Europe, s.r.o., V Olšinách 80/626, 100 00 Praha 10 – Strašnice, Česká republika

2 / 16


1. Právní doložka Tento dokument včetně všech případných příloh a odkazů je určen výhradně pro potřeby poskytovatele služeb e-shopu (dále jen „Zákazník“). Informace v tomto dokumentu obsažené (dále jen „Informace“) jsou předmětem duševního vlastnictví a ochrany autorských práv společnosti Global Payments Europe, s.r.o. (dále jen „GPE“) a mají povahu obchodního tajemství v souladu s ust. § 504 zák. č. 89/2012 Sb., Občanský zákoník. Zákazník si je vědom právních povinností ve vztahu k nakládání s Informacemi. Informace nebo kterákoliv její část nesmí být bez předchozího výslovného písemného souhlasu GPE poskytnuty nebo jakýmkoliv způsobem zpřístupněny třetí straně. Informace nesmí být zároveň využity Zákazníkem pro jiné účely, než pro účely ke kterému slouží. Pro vyloučení všech pochybností nesmí být Informace nebo kterákoliv část bez předchozího výslovného písemného souhlasu GPE poskytnuty nebo jakýmkoliv způsobem zpřístupněny ani společnostem poskytujícím služby zpracování plateb v prostředí internetu. GPE si v rozsahu dovoleném platným právem, vyhrazuje veškerá práva k této dokumentaci a k Informacím v ní obsažených. Jakékoliv rozmnožování, použití, vystavení či jiné zveřejnění nebo šíření Informací nebo její části metodami známými i dosud neobjevenými je bez předchozího písemného souhlasu společnosti GPE přísně zakázáno. GPE není jakkoliv odpovědná za jakékoliv chyby nebo opomenutí v Informacích. GPE si vyhrazuje právo, a to i bez uvedení důvodu, jakoukoliv Informaci změnit nebo zrušit.


3 / 16


2. Úvod 2.1 Účel dokumentu – ukázkové scénáře z praxe Tento dokument popisuje nejčastěji řešené případy manipulace s objednávkami v aplikaci GP webpay. Dokument neobsahuje striktní doporučení pro manipulaci s objednávkami – je pouze přiložen jako doporučení, jak pracovat s objednávkami v GP webpay. Dokument byl zpracován na základě dosavadních praktických zkušeností uživatelů GP webpay.

3. Scénáře 3.1 Scénář 1: Nákup zboží – Vytvoření objednávky s autorizací Vytvoření objednávky s autorizací – tzn. blokování požadované částky na účtu držitele karty. O tento typ platby se jedná v případě nákupu fyzického zboží. V okamžiku přijetí objednávky GP webpay automaticky zažádá o autorizaci objednávky – po úspěšné autorizaci bude částka na účtu držitele karty zablokována. V okamžiku expedice zboží obchodník zašle on-line požadavek processDeposit(), příp. prostřednictvím administrativního webového rozhraní GP webpay zvolí pro danou objednávku příkaz “Úhrada“ resp. “Deposit“ – scénář Dodání zboží. Postup: 1)

Držitel karty zvolí na stránkách obchodníka způsob placení pomocí GP webpay;

2)

Obchodník přesměruje internetový prohlížeč držitele karty na stránky GP webpay. V požadavku na vytvoření objednávky (CREATE_ORDER) zašle parametr DEPOSITFLAG s hodnotou 0;

3)

Na stránkách GP webpay držitel karty vyplní citlivé informace;

4)

Po zadání údajů a potvrzení požadavku na platbu ověří GP webpay u Directory Serveru příslušné asociace (MasterCard, VISA, DC, AMEX), zda je pro použitou platební kartu požadována 3D Secure autentikace;

5)

Jestliže je požadována 3D Secure autentikace držitele karty, bude držitel karty přesměrován na stránky Access Control Serveru své banky, kde bude ověřena jeho totožnost;

6)

Dle výsledku autentikace držitele karty GP webpay pokračuje/nepokračuje žádostí o autorizaci objednávky: 

pokud byl držitel karty plně ověřen, následuje žádost o autorizaci;



v případě neúspěšného ověření držitele karty (nesprávné vyplnění informací požadovaných k autentikaci držitele karty), není možné pokračovat. Obchodník


4 / 16

GP webpay - praktické scénáře bude informován o neúspěšné autentikaci držitele karty, a to zasláním odpovědi na URL adresu uvedenou v CREATE_ORDER s příslušnými parametry;  7)

jestliže banka držitele karty nebo držitel karty nejsou zapojeni v 3D Secure, potom systém pokračuje v autorizaci objednávky v bance zákazníka.

Dle výsledku autentikace je do autorizace zasílán indikátor označující výsledek ověření držitele karty v 3D Secure. Indikátor je jedním z faktorů, na základě kterých banka držitele karty povolí/zamítne žádost o autorizaci. Zde záleží na nastavení jednotlivých bank, zda neověřenou 3D transakci v tomto kroku banka příjme, anebo zamítne. Pokud při zamítnutí žádosti o autorizaci bude banka informovat, že důvod zamítnutí spočívá v neověření v 3D Secure, bude tato informace přeposlána obchodníkovi, který může držiteli karty zobrazit informaci “Vaše transakce byla zamítnuta z důvodu nemožnosti ověření držitele karty v 3D Secure. Zažádejte svoji vydavatelské banku o zpřístupnění této služby.“

8)

O výsledku autorizace je obchodník informován formou vyvolání URL adresy uvedené v CREATE_ORDER s příslušnými parametry, které potvrzují úspěch, anebo uvádějí příčiny neúspěchu;

9)

Jestliže držitel karty v některém kroku neukončil zadání údajů, zpracování končí. Vyvolání URL adresy obchodníka s parametry o výsledku nelze zaručit. V tomto případě je zapotřebí se o výsledku přesvědčit, a to zasláním požadavku getOrderState() s uvedeným číslem objednávky nebo zkontrolovat stav objednávky v administrativním uživatelském rozhraní GP webpay;

10)

Pokud byl požadavek úspěšně autorizován, avšak obchodník nakupujícímu zboží nedodá/nedodal, je pro odblokování částky na účtu držitele karty nezbytně nutné zaslat požadavek processAuthorizationReverse(). Když obchodník nezašle požadavek processAuthorizationReverse(), zůstane částka na účtu držitele karty zablokovaná po dobu specifikovanou bankou držitele karty. Po uplynutí této doby bude blokace částky automaticky uvolněna;

11)

Po vyvolání URL adresy obchodníka obchodník informuje držitele karty

12)

Na základě výše uvedených kroků je v GP webpay zavedena objednávka (ORDER). Jednoznačným identifikátorem objednávky je pole ORDERNUMBER. Objednávka se může nacházet ve stavu: 

Requested – objednávka je inicializována. Když držitel karty nevyplní citlivé údaje a ukončí komunikaci, zůstává objednávka v tomto stavu;



Pending – po odeslání požadavku na 3D Directory Serveru dané finanční asociace;



Created – po obdržení kladné odpovědi z 3D Directory Serveru, následuje autorizace objednávky;



Declined – po obdržení záporné odpovědi z 3D Directory Serveru, nelze pokračovat autorizací objednávky;



Approved - v případě úspěšné autorizace objednávky;


5 / 16

GP webpay - praktické scénáře  13)

Unapproved – v případě neúspěšné autorizace objednávky.

Při ověřování stavu objednávky zasláním požadavku getOrderState() je nutné počítat s jistou časovou prodlevou, zapříčiněnou interakcí s 3D systémy a autorizačním centrem. Mezi další faktory možného prodlení, které nelze ovlivnit, je nutné počítat: 

doplnění citlivých údajů držitelem karty na stránkách GP webpay;



doplnění autentikačních údajů držitele karty na 3D Secure Access Control Serveru;

14)

Vyvolání URL adresy obchodníka s výsledkem požadavku CREATE_ORDER bude provedeno až po určité časové prodlevě, zapříčiněné stejnými důvody jako v bodě 13);

15)

Dotaz getOrderState() nemá význam zasílat okamžitě po přesměrování držitele karty na GP webpay. S jistotou lze tvrdit, že po uplynutí 60 minut po přesměrování držitele karty na GP webpay, držitel karty ukončil veškerou komunikaci a stav objednávky po této době je definitivní. Totéž se týká ověřování stavu objednávky pomocí webového grafického rozhraní.


6 / 16


3.2 Scénář 2: Nákup zboží – Okamžitý požadavek na převod částky z účtu držitele karty O tento typ platby se jedná při nákupu okamžitě dodaného zboží - distribuce souborů, pojištění, registrace apod. U objednávek zašle obchodník v požadavku na vytvoření objednávky (CREATE_ORDER) parametr DEPOSITFLAG s hodnotou 1. Scénář 2 má podobný průběh jako scénář 1, liší se pouze v kroku 10. Jestliže proces neskončí vyvoláním URL adresy obchodníka s výsledkem zpracování, mohla být případná chyba zapříčiněna problémy v internetové komunikaci. Zpracování objednávky mohlo proběhnout korektně, vzhledem k hodnotě DEPOSITFLAG následoval za autorizací objednávky ihned i požadavek na zaúčtování objednávky. Objednávka se nalézá ve stavu Deposited_batch_open a při následujícím zaúčtování bude zaslán požadavek na převod částky z účtu držitele karty na účet obchodníka. Pokud obchodník nedostal zprávu o úspěchu/neúspěchu, a proto zboží nedodal, je nutné ověřit stav objednávky, a to zasláním požadavku getOrderState(). Jestliže je objednávka ve stavu Deposited_batch_open, musí být odeslán požadavek processDepositReverse() (scénář 4) na zrušení zaúčtování objednávky, a poté ještě požadavek processAuthorizationReverse() (scénář 5) pro následné odblokování částky na účtu držitele karty. Pokud dávka s transakcí byla mezitím uzavřena (došlo k zaúčtování), je k dispozici požadavek processCredit() (scénář 6) pro převod finančních prostředků z účtu obchodníka na účet držitele karty.


7 / 16


3.3 Scénář 3: Dodání zboží - Převedení částky z účtu držitele karty na účet obchodníka Jedná se o situaci, kdy zákazník objednal u obchodníka zboží a úspěšně proběhl scénář 1. Objednávka je ve stavu Approved (Autorizována). Obchodník dodává zákazníkovi požadované zboží, a proto požaduje převedení částky, která je na účtu zákazníka blokována v jeho prospěch, na svůj účet. Postup: 1)

Obchodník zašle na webService rozhraní GP webpay metodu processDeposit(), nebo prostřednictvím administrativního webového rozhraní zvolí u dané objednávky příkaz “Úhrada“ nebo “Deposit“;

2)

Pro objednávku se v této chvíli vytvoří platební transakce, která se stává součástí dávky obchodníka. Stav objednávky se změní na “Deposited_batch_open“. Na konci dne se všechny otevřené dávky všech obchodníků automaticky uzavřou.

3)

Zaúčtování transakcí v dávkách probíhá jednou denně. Všechny dávky, které jsou ve chvíli tvorby exportního souboru uzavřené, ale dosud nebyly zaúčtovány, se stanou součástí exportu dat následně zaúčtovaných v bance. Na zaúčtování transakcí (čas, ano/ne…), nemá obchodník žádný vliv, zaúčtování probíhá automaticky;

4)

Po uzavření dávky s danou objednávkou je objednávka ve stavu Deposited_batch_closed;

5)

Tím je splněn standardní scénář pro většinu nákupů, ze strany obchodníka není požadována žádná další akce.


8 / 16


3.4 Scénář 4: Dodání zboží – Chybně zadaná částka Jestliže administrátor obchodníka, který má na starosti GP webpay rozhraní zjistí, že při zadání úhrady (scénář 2.) došlo k chybě, a to buď volbou nesprávné objednávky, anebo chybným zadáním částky, může svoji chybu opravit. Postup: 1)

Pokud je chyba objevena před uzavřením dávky a objednávka byla založena bez požadavku automatického převodu částky (DEPOSITFLAG s hodnotou 0), je objednávka stále ve stavu Deposited_batch_open, může být zaslán požadavek processDepositReverse(), případně lze v administrativním webovém rozhraní zvolit “reverze úhrady“. Stav objednávky se změní zpět na “Autorizována“, resp. Approved. Následně bude možné opět zaslat požadavek processDeposit(), anebo prostřednictvím administrativního webového rozhraní zadat příkaz “Deposit“;

2)

Jestliže byla dávka s objednávkou uzavřena nebo byla založena s finální částkou (DEPOSITFLAG s hodnotou 1), je objednávka ve stavu Deposited_batch_closed a úhradu již není možné zrušit. Pokud je požadováno vrátit částku držiteli karty, lze zaslat požadavek processCredit(), anebo prostřednictvím administrativního webového rozhraní zvolit “Credit“.


9 / 16


3.5 Scénář 5: Storno objednávky Když držitel karty nakoupil na stránkách obchodníka (scénář 1), byl úspěšně autentikován v 3D systémech a výsledek autorizace byl kladný, je objednávka je ve stavu Approved, anebo Autorizována. V této situaci může zákazník požádat o storno objednávky, nebo se obchodník rozhodne zboží nedodat (např. zboží nebude možné v budoucnu dodat). Administrátor obchodníka, který má na starosti GP webpay, zašle na webService rozhraní GP webpay metodu processAuthorizationReverse() nebo zvolí prostřednictvím administrativního webového rozhraní příkaz “Approve reversal“ pro danou objednávku. Stav objednávky se změní na “Approve reversed“ neboli “Autorizace reverzována“. Pro touto objednávku již není možná žádná další autorizace.


10 / 16


3.6 Scénář 6: Reklamace objednávky držitelem karty Zákazník úspěšně reklamuje zboží nebo služby a obchodník požaduje převod finančních prostředků v původní (příp. částečné) výši zpět na účet držitele karty. Vzhledem k tomu, že úhrada objednávky již proběhla, nelze použít reverzi úhrady. V tomto případě administrátor obchodníka zašle na webService rozhraní GP webpay metodu processCredit() nebo v administrativním webovém rozhraní zadá příkaz “Kredit“ resp. “Credit“ pro danou objednávku, která je ve stavu Deposited_batch_closed. Při zadání návratu finančních prostředků administrátor stanoví částku určenou k návratu, která nesmí překročit původně uhrazenou částku. Pro jednu objednávku je možné vytvořit několik návratů. Součet navrácených částek nesmí převýšit původně uhrazenou částku. V případě chybného zadání návratu je možné, až do doby uzavření dávky s požadovaným návratem, zaslat na webService rozhraní GP webpay metodu processCreditReverse(), anebo zvolit prostřednictvím administrativního webového rozhraní příkaz “CREDIT_REVERSAL“. Pokud pro objednávku existuje v daný okamžik alespoň jeden návrat v otevřené dávce, pak se objednávka nalézá ve stavu Credited_batch_open. Když jsou všechny návraty dané objednávky v již uzavřených dávkách, je objednávka ve stavu Credited_batch_closed.


11 / 16


3.7 Scénář 7: Uzavření objednávky Když obchodník nepředpokládá žádný další pohyb v rámci objednávky a považuje objednávku za uzavřenou, může administrátor obchodníka zaslat na webService rozhraní GP webpay metodu processOrderClose() nebo prostřednictvím administrativního webového rozhraní zadat pro danou objednávku příkaz “CLOSE_ORDER“, resp. “Uzavření objednávky“. Objednávka bude ve stavu Closed. Jediná povolená operace pro objednávku ve stavu Closed je DELETE, tj. vymazání objednávky.


12 / 16


3.8 Scénář 8: Vymazání objednávky Jestliže je objednávka je ve stavu Closed nebo Declined nebo Unapproved, anebo Approve_reversed a obchodník požaduje odstranění objednávky (objednávka se nadále nebude zobrazovat), může administrátor obchodníka zaslat na webService rozhraní GP webpay metodu processOrderDelete(), anebo prostřednictvím administrativního webového rozhraní zadat pro danou objednávku příkaz “Delete“ nebo “Odstranit“. Tímto příkazem se stav objednávky změní na “Deleted“. Objednávka se již nebude zobrazovat, avšak z účetních důvodů zůstává v systému. Její jednoznačný identifikátor ORDERNUMBER nelze opakovaně použít.


13 / 16


3.9 Scénář 9: Předvyplnění údajů o platební kartě na platební bráně Pro zlepšení komfortu platby pro zákazníka, je možné, aby byly na platební bráně předvyplněny údaje o platební kartě. Pro předvyplnění údajů, pokud jej má obchodník povoleno – záleží na souhlasu banky, stačí při založení nové objednávky vyplnit pole „FASTPAYID“ hodnotou jakékoli předchozí úspěšně zaplacené objednávky zákazníka. Na platební stránce je zobrazeno vyhvězdičkované číslo karty, doba platnosti karty a popisný text vysvětlující bezpečnostní hledisko. Zákazník je požádán pouze o zadání hodnoty CVV/CVC2. Dále následuje zpracování objednávky standardním způsobem.


14 / 16


3.10 Scénář 10: Opakované platby Systém GP webpay umožňuje pracovat s tzv. opakovanými platbami. Celý proces probíhá tak, že je nejprve potřeba vytvořit tzv. registrační („master“) objednávku přes standardní HTTP rozhraní a později je možné k této registrační objednávce zakládat prostřednictvím web services (WS) další následné platby.

3.10.1 Registrace „master“ platby Aby mohla být objednávka považována za registrační, je potřeba při jejím zakládání naplnit a zaslat na vstupní rozhraní parametr „USERPARAM1“ s hodnotou „R“. Tímto krokem je objednávka považována za registrační a je v systému označena za tzv. „master“ (vzorovou/registrační) objednávku. Další zpracování probíhá již standardním způsobem jako u každé jiné objednávky. Registrační objednávku není možné, z důvodu omezení karetní asociací Master Card, zaplatit pomocí Maestro karty. V tomto případě platební brána zobrazí hlášení o nepodporovaném typu karty a vyžádá si jinou platební kartu.

3.10.2 Provedení „následné“ platby Následná platba již probíhá prostřednictvím WS, protože již není potřeba přítomnost držitele karty. Než bude možné vytvořit následnou platbu, je nutné, aby objednávka byla úspěšně autorizována a zaúčtována – tj. musí dojít k fyzickému zaplacení (z pohledu systému GP webpay musí dojít k uzavření dávky s touto objednávkou). Zneplatnění registrační platby je možné dvěma způsoby: 1. zneplatnění provede vydavatel platební karty prostřednictvím speciálního návratového kódu z autorizačního procesu 2. automaticky po roce nečinnosti – tj. k registrační objednávce nebyla více než 1 rok vytvořena žádná následná platba Následná/opakovaná platba je uskutečněna pomocí WS metody „processRecurringPayment()“, kde jedním ze vstupních parametrů je ORDERNUMBER „master“ objednávky.


15 / 16


3.11 Scénář 11: PUSH platby – zkrácený platební link PUSH platba umožňuje obchodníkovi iniciovat platby kartou. Ten může iniciovat jednotlivé platby prostřednictvím aplikace GP webpay. GP WebPay pro požadovanou platbu založí objednávku a vytvoří krátký, opakovatelný link, který může být odeslán na e-mail zákazníka. Výhodou tohoto způsobu zakládání objednávek je, že je možné platební link zapracovat do emailu, elektronické faktury … Platební link lze využít pro opakované otevření platební stránky a je možné provést až 3 pokusy o zaplacení (zadání platebních dat).

3.11.1 Založení PUSH platby Pro založení PUSH objednávky je rozšířeno grafické rozhraní GP webpay – v menu aplikace je nabídka „Založit PUSH platbu“. Po stisknutí této volby je zobrazen formulář s požadovanými údaji o platbě a po jejich vyplnění je možné odeslat notifikační e-mail zákazníkovi, popř. vzniklý link nakopírovat do vlastního e-mailu či dokumentu. PUSH platbu je také možno založit pomocí WS metody createPaymentLink(). Parametry metody jsou identické s formulářem v GUI. Návratovou hodnotu tvoří link na založenou objednávku. Platnost odkazu je max. 3 měsíce a může být zkrácena nastavením platnosti v GUI, popř. v parametru WS. Jednou vytvořený link je neměnný, pouze lze v GUI tento link zneplatnit (v případě, že k němu již nebyla provedena platba).

3.11.2 Provedení platby zákazníkem Zákazník obdržel e-mail ve znění schváleném obchodníkem, popř. je link součástí elektronické faktury. Pokud se rozhodne využít obdržený link pro úhradu, je po kliknutí na tento link • v případě, že objednávka je nalezena a platná – přesměrován na platební bránu GP webpay. Zde může platbu provést. Platba probíhá zcela standardním způsobem a obchodník je informován o úspěšné platbě. • v případě, že objednávka je nenalezena nebo ji nelze provést – informován o nemožnosti provést platbu.


16 / 16

GP webpay - praktické scénáře

Recommend Documents