Cztery podsystemy opisane na tej stronie: router, który wybiera dostawców i przełącza się między nimi w razie awarii, księga w systemie podwójnego zapisu rejestrująca każdą operację, mechanizmy ryzyka i przesiewania działające przed autoryzacją płatności oraz narzędzia dla merchantów do onboardingu, kluczy i webhooków. Wszystkie cztery elementy trafiają do Was jako jedna bramka za jednym API, we własnych repozytoriach.

Oba podejścia są powszechne. Większość projektów zaczyna się od opakowania obecnych dostawców w routerze, dzięki czemu pierwszego dnia nic nie zmienia się w produkcji, a kolejne szyny płatnicze są dodawane lub wymieniane zgodnie z roadmapą. Dzięki temu działające przychody pozostają nienaruszone, podczas gdy nowe oprogramowanie bramki płatności powstaje w tle.

Tak. Transakcje kartowe, SEPA, open banking oraz on-chain trafiają do tej samej księgi w systemie podwójnego zapisu, dzięki czemu dział finansowy odczytuje jeden raport i uzgadnia dane względem jednego źródła prawdy. Transakcje kryptowalutowe zawierają dane Travel Rule tam, gdzie jest to wymagane, i korzystają z tego samego mechanizmu przesiewania ryzyka co płatności fiducjarne.

Logika zwolnień SCA oraz step-up jest wbudowana w proces płatności i wypłat — Wasi doradcy ustalają politykę, my dostarczamy kod i dowody zgodności. Dane kart są tokenizowane, dzięki czemu zakres PCI DSS pozostaje minimalny, a hostowane pola i vaulty całkowicie eliminują surowe numery PAN z Waszych systemów.

Wy. TrustChange buduje systemy szyte na miarę, w pełni należące do klienta: bez licencji white label, bez opłat za stanowisko i bez uzależnienia od dostawcy (lock-in). Kod znajduje się w Waszych repozytoriach i podlega Waszym procesom, dane pozostają w wybranych przez Was regionach, a umowy przenoszą prawa własności intelektualnej na Was od pierwszego dnia.

Każda transakcja pozostawia podpisany ślad: decyzję routingu, werdykt ryzyka, wpisy w księdze, dopasowanie w uzgadnianiu oraz zatwierdzenie wypłaty. Raporty można eksportować dla działu finansowego i zewnętrznych audytorów, a dostęp do danych produkcyjnych jest rejestrowany względem konkretnej, imiennej tożsamości, a nie współdzielonego konta serwisowego.