IngenicoServer transakcja

pierwsza transakcja

Niestety każdy provider (eSerice czy Polacrd) posiada własny standard przeprowadzania transakcji, stad w aplikacji IngenicoServer nie jesteśmy w stanie przygotować uniwersalnego procesu, jednak dołożyliśmy wszelkich starań aby proces był najbardziej jak to możliwe uniwersalny.

Transakcję przeprowadza się w 3 krokach:

1. Sprawdzenie czy terminal nie jest w trakcie przeprowadzania innej transakcji
2. Rozpoczęcie transakcji
3. Pobranie wyniku

Za każdy z 3 kroków odpowiedzialny jest inny RESTpoint, a przykładowy film ilustrujący ich użycie można obejrzeć tu:

INGENICO SERVER – eService RESTful API – INTEGRACJA

EService

W tym artykule pokażemy jak przeprowadzić transakcję w przypadku eService. Wszystkie kroki opisane poniżej znajdują się w postaci skryptów w katalogu /docs w paczce dystrybucyjnej.

Na początku weryfikujemy czy terminal jest gotowy na przyjęcie nowej transakcji:

Jeśli status to “Idle“, wówczas możemy rozpocząć transakcję, np na 20zł

Terminal w danej chwili może być w jednym z wielu stanów. O ile większość z nich jest czysto informacyjna, o tyle kilka z nich może wymagać obsługi po stronie aplikacji (pełen proces zamodelowany jest w skrypcie: /docs/eservice/transaction_simple.sh)

• Idle – gotowy do rozpoczęcia transakcji,
• WaitCard – oczekiwanie aż klient użyje karty,
• WaitPIN – oczekiwania na podanie kodu PIN,
• WaitEMVApp –
• WaitHost – komunikacja z eService,
• WaitSign – oczekiwanie na potwierdzenie podpisu,
• WaitTrEnd – oczekiwanie na zakończenie transakcji. Terminal zakończył transakcję i należy odczytać jej status metodą /eservice/v1/ingenico_transaction_end
• WaitNoCard – oczekiwanie aż klient usunie kartę z terminala,
• WaitBusy – terminal zajęty (inne operacje są wykonywane); należy poczekać aż status się zmieni
• InProgress – transakcja w trakcie procesowania,
• WaitCopy – oczekiwanie na akceptację wydruku kopii,
• WaitAuthCode – oczekiwanie na podanie kodu autoryzacyjnego,
• WaitAction – oczekiwanie na akcję klienta (polecenie pojawia się na wyświetlaczu terminala)
• BatchCompleted – zestawienie gotowe, terminal oczekuje aż dane zostaną odczytane. Należy odczytać status po przesłaniu transakcji do rozliczenia. Używamy do tego metody /eservice/v1/ingenico_batch_recon_info. Uwaga, dane zwracane są w “paczkach”, stąd metodę /eservice/v1/ingenico_batch_recon_info należy wykonywać tyle razy aż terminal nie zwróci statusu “idle” (przykład znajduje się w pliku /docs/eservice/clearbatch.sh)
• DCCCurrency – użytkownik wybiera walutę sprzedaży,
• CashBackAmount – oczekiwania na podanie kwoty caskback,
• TransactionAccepted – status pojawia się w zależności od konfiguracji i tylko wówczas gdy terminal wie, że transakcja została zatwierdzona.
• WaitingForAmount – oczekiwanie na wprowadzenie kwoty. Status pojawia się w przypadku: cashback, transakcjach DCC lub napiwkach.
• WaitingForSelection – oczekiwanie na wybór pozycji z listy,
• AskingEcrToPrintData – terminal oczekuje na to że klientowi zostanie wyświetlony odpowiedni tekst. Tekst do wyświetlenia zwracany jest razem ze statusem.
• PresentingZenCardOffer – oczekiwanie na wyświetlenie oferty ZenCard,
• WaitingForFid
• AskingEcrToReceiveData – terminal oczekuje na pobranie danych. Status używany podczas obsługi ZenCard,
• ZencardContinue – status ten jest wysyłany po zakończeniu transakcji ZenCard; terminal kontynuuje przetwarzanie ZenCard
• ApplicationInErrorState – inne błędy, np gdy odczyt kart nie jest możliwy,
• AskingEcrToPrintDataStop
• TransactionAborted
• WaitPromptEnd
• WaitCutoffEnd
• WaitReportEnd
• ReconciliationNeeded – oczekiwanie na zamknięcie dnia. Należy zamknąć dzień roboczy i wysłać transakcje do rozliczenia (przykład znajduje się w skrypcie /docs/eservice/reconciliation-close_business_day.sh). Polecenie zamknięcia dnia:

Teraz co pewien czas, np co 1s sprawdzamy status naszej transakcji:

Jak tylko status zmieni się na “WaitTrEnd“, wówczas możemy odczytać status naszej transakcji:

W response zwracanym w powyższym zapytaniu znajdują się informacje o numerze transakcji, jej typie (blik, contactless, itp.) oraz jej statusie, czyli czy płatność została poprawnie przeprocesowana.

Jest kilka możliwych wariantów zakończenia transakcji. Jeśli atrybut “ok” ma wartość “true”, wówczas uznaje się transakcję za poprawnie zakończoną i z pozostałych atrybutów można odczytać szczegółowe informacje. Jeśli atrybut “ok” ma wartość “false”, wówczas pole “error” zawiera szczegółowe informacje w postaci:

• Transaction refused
• No connection
• Transaction interrupted by the user
• Card is blacklisted

SPECJALNE INTEGRACJE

Terminale często używane są w specjalnych integracjach np. z systemami parkingowymi i z systemami obsługującymi transport publiczny. Wówczas przy rozpoczęciu transakcji należy wykorzystać dedykowane temu flagi. W typowych integracjach nie są one wykorzystywane. Aktualnie obsługiwane flagi to:

• Enable Token Generation – włączenie flagi przy wysłaniu kwoty sprzedaży spowoduje, że finalnie w odpowiedzi terminal wykona sprzedaż i przekaże ten token
• Enable Reference Number Generation – terminal podczas transakcji generuje dodatkowy numer referencyjny i zwraca go w zakończeniu transakcji w polu “referenceNumber”.
• Enable Transit Transaction Indicator – wspomaga integracje w środkach transportu publicznego. Terminal wówczas akceptuje nie tylko karty płatnicze ale również bilety elektroniczne (https://www.eservice.pl/aktualnosci/tag/transit-transaction)

Share This