Płatności i merchant services · Realizacja anonimowa

Od terminala do raportu sprzedawcy

Ekosystem łączył oprogramowanie działające przy terminalu, wymianę danych, importy transakcji, bazę oraz portal dla sprzedawców. Rozwijaliśmy portal w miejscach, w których format pliku, precyzja kwoty, strefa czasu lub sposób agregacji wpływały na obraz tej samej transakcji.

Potwierdzony rezultat prac

Jawne reguły importu, kwot i czasu, kontrolowane dopasowanie transakcji acquirerów, rozszerzone filtrowanie i eksport oraz monitoring błędów w zmodernizowanym portalu.

Widok ekosystemu

Sprzedawca widział raport. System musiał zachować drogę każdej transakcji.

Zanim transakcja pojawiła się w portalu, przechodziła przez urządzenie, połączenia i formaty wymiany, import, model danych oraz zapytania raportowe.

Ilustracyjny ekosystem płatniczy pokazujący drogę fikcyjnej transakcji od terminala przez wymianę danych i import do portalu sprzedawcy — Autorska rekonstrukcja przepływu na podstawie zrealizowanego zakresu. Interfejs, terminal, sprzedawca i dane są fikcyjne.

Kontekst

Portal był częścią większego łańcucha płatniczego

Warstwa terminalowa łączyła różne kanały komunikacji i dostawców. Portal przyjmował dane transakcyjne, zestawiał je z danymi acquirerów i udostępniał sprzedawcom filtrowanie, raportowanie oraz eksport.

Kontekst klienta: Duński ekosystem merchant services obejmujący terminale płatnicze, wymianę danych transakcyjnych i portal dla sprzedawców.
Rola CODEVENOM: Realizacja podwykonawcza w wielostopniowym łańcuchu dostaw. Bezpośrednio rozwijaliśmy portal i jego granice danych; aplikacja terminalowa stanowi wyłącznie kontekst architektury.

Wyzwanie

Znaczenie transakcji było rozłożone pomiędzy kilka warstw

Kwota, czas, identyfikator i klasyfikacja musiały pozostać spójne pomimo różnych formatów wejściowych, reguł bazy danych i sposobów prezentacji w portalu.

Format i separator importu CSV wpływały na to, czy rekord został poprawnie odczytany.
Precyzja kwot zależała od typów bazy danych i sposobu normalizacji wartości wejściowych.
Strefa czasu oraz granice dnia wpływały na filtrowanie, agregację i prezentację transakcji.
Dopasowanie RRN, kategorie operacji i dane acquirerów musiały działać spójnie w listach oraz eksportach.

Ilustracyjna mapa ryzyka pokazująca kwotę, czas i identyfikator transakcji przechodzące przez terminal, plik wymiany, import, bazę i raport — Schemat przedstawia klasę problemu potwierdzoną w pracach. Wartości, formaty i nazwy są fikcyjne.

Zakres

Prace objęły miejsca, w których dane zmieniały format albo znaczenie

Koncentrowaliśmy się na portalu: od przyjęcia rekordu, przez model i zapytania, aż po widok oraz plik przekazywany użytkownikowi.

Importy transakcji, parser CSV, nagłówki i zgodność z aktualnymi bibliotekami
Precyzja kwot, strefy czasu, daty i serializacja danych
Dopasowanie transakcji acquirerów, filtrowanie, agregacja i paginacja
Eksporty, monitoring błędów oraz modernizacja aplikacji i procesu wdrożenia

Podejście

Najpierw prześledzić transakcję. Dopiero potem zmieniać raport.

Każdą zmianę odnosiliśmy do drogi konkretnego rekordu: skąd przyszedł, jak został znormalizowany, z czym się połączył i co ostatecznie zobaczył sprzedawca.

01
Określić źródło, identyfikator i format wejściowy rekordu.
02
Normalizować wartość oraz czas na kontrolowanej granicy importu.
03
Zachować precyzję i jednoznaczne reguły dat w modelu oraz bazie.
04
Zweryfikować ten sam rekord w dopasowaniu, filtrach, agregacji i eksporcie.

Pięcioetapowy przepływ od źródła transakcji przez format, normalizację kwoty i czasu oraz dopasowanie do raportu sprzedawcy — Metoda pracy: źródło → format → wartość i czas → dopasowanie → raport.

Wykonane zmiany

Portal otrzymał jawne punkty kontroli nad transakcją

Zamiast traktować błąd w raporcie jako problem jednego ekranu, zmiany obejmowały kolejne granice, przez które przechodziły wartości i identyfikatory.

Aktualizacja obsługi CSV, mapowania nagłówków oraz definicji operacji, schematów i acquirerów
Typy decimal dla wartości finansowych i jawny fallback normalizacji liczb
Kontrolowane reguły stref czasowych w imporcie, filtrach oraz serializacji odpowiedzi
Dopasowanie RRN w ograniczonych partiach, eksport do wielu formatów i monitoring przez Sentry

Rezultat

Portal zyskał spójniejsze punkty kontroli nad danymi transakcyjnymi

Wykonane prace przeniosły krytyczne reguły importu, kwot, czasu i dopasowania do jawnych mechanizmów portalu. Dostępne dowody potwierdzają te zmiany systemowe, ale nie obejmują pomiaru wolumenu transakcji, czasu uzgodnień, uptime’u ani dokładności rozliczeń.

Ilustracyjne porównanie rozproszonych reguł transakcyjnych z kontrolowanym modelem importu, kwot, czasu, dopasowania i raportowania — Rezultat przedstawiony na poziomie wdrożonych mechanizmów, bez niepotwierdzonych metryk finansowych lub operacyjnych.

Powiązana usługa

Gdy portal B2B pokazuje wynik procesu działającego w kilku systemach

Projektujemy i rozwijamy portale oraz dashboardy, które zachowują znaczenie danych od źródła do raportu i dają zespołom operacyjnym czytelne punkty kontroli.

Zobacz portale i dashboardy B2B

Zacznijmy od jednej transakcji

Różne raporty pokazują inne liczby lub statusy?

Pokaż nam źródło transakcji, sposób importu i raport używany przez sprzedawcę. Prześledzimy, gdzie wartość, czas albo identyfikator zaczynają być interpretowane inaczej.

Rozpocznij projekt