GP webpay: Praktické scénáře

GP webpay: Praktické scénáře červenec 2013

OBSAH:

SCÉNÁŘ 1: NÁKUP ZBOŽÍ – VYTVOŘENÍ OBJEDNÁVKY S AUTORIZACÍ .................................. 4 SCÉNÁŘ 2: NÁKUP ZBOŽÍ – OKAMŽITÝ POŽADAVEK NA PŘEVOD ČÁSTKY Z ÚČTU DRŽITELE KARTY ......................................................................................................... 6 SCÉNÁŘ 3: DODÁNÍ ZBOŽÍ - PŘEVEDENÍ ČÁSTKY Z ÚČTU DRŽITELE KARTY NA ÚČET OBCHODNÍKA ................................................................................................................... 7 SCÉNÁŘ 4: DODÁNÍ ZBOŽÍ – CHYBNĚ ZADANÁ ČÁSTKA ...................................................... 8 SCÉNÁŘ 5: STORNO OBJEDNÁVKY .................................................................................... 9 SCÉNÁŘ 6: REKLAMACE OBJEDNÁVKY DRŽITELEM KARTY ................................................ 10 SCÉNÁŘ 7: UZAVŘENÍ OBJEDNÁVKY ................................................................................ 11 SCÉNÁŘ 8: VYMAZÁNÍ OBJEDNÁVKY ............................................................................... 12

© Global Payments Europe, s.r.o. Global Payments Europe, s.r.o., V Olšinách 80/626, 100 00 Praha 10 - Strašnice

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

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.


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 DEPOSIT, 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 DEPOSIT_FLAG 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), 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 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;  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.

7)

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 QUERY_ORDER_STATE 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 APPROVE_REVERSAL. Když obchodník nezašle požadavek APPROVE_REVERSAL, 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 ORDER_NUMBER. 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;  Unapproved – v případě neúspěšné autorizace objednávky. 13) Při ověřování stavu objednávky zasláním požadavku QUERY_ORDER 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 QUERY_ORDER_STATE 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í.


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 DEPOSIT_FLAG 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ě DEPOSIT_FLAG 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 QUERY_ORDER_STATE. Jestliže je objednávka ve stavu Deposited_batch_open, musí být odeslán požadavek DEPOSIT_REVERSAL (scénář 4) na zrušení zaúčtování objednávky, a poté ještě požadavek APPROVE_REVERSAL (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 CREDIT (scénář 6) pro převod finančních prostředků z účtu obchodníka na účet držitele karty.


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 deposit (), 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.


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, je objednávka stále ve stavu Deposited_batch_open, může být zaslán požadavek DEPOSIT_REVERSAL, 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 DEPOSIT, anebo prostřednictvím administrativního webového rozhraní zadat příkaz “Deposit“; 2)

Jestliže byla dávka s objednávkou uzavřena, 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 CREDIT, anebo prostřednictvím administrativního webového rozhraní zvolit “Credit“.


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 approveReversal() 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.


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 credit() 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 creditReversal(), 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.


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 closeOrder() 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.


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 delete(), 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 ORDER_NUMBER nelze opakovaně použít.


GP webpay: Praktické scénáře

Recommend Documents