Architektura platformy

Jeden rdzeń, wiele powierzchni — jak naprawdę działa platforma.

Przegląd platformy od księgi głównej w górę: konta, KYC, karty i krypto na wspólnym rdzeniu z księgowaniem podwójnym, droga pojedynczej płatności od utworzenia do uzgodnienia oraz miejsce warstwy aplikacji, konsoli operatora i linii regulowanej.

Porozmawiaj z nami Zobacz produkty

Rdzeń platformy

Jedna księga pod wszystkim.

W centrum platformy jest jedna księga kont. Każde konto — portfel klienta, saldo merchanta, konto prowizyjne, konto rozliczeniowe — jest węzłem tej księgi, a każdy ruch wartości to zapis podwójny: jedno konto obciążone, drugie uznane, obie strony zawsze równe. Księga jest tylko do dopisywania (append-only). Wpisów nigdy się nie edytuje ani nie usuwa; korekta to nowy, przeciwny wpis, więc pełną historię dojścia salda do obecnej wartości zawsze można odtworzyć. Konta, status KYC, wydane karty i adresy krypto podpinają się do tego samego modelu konta, dlatego autoryzacja kartowa, przelew bankowy i wpłata on-chain mogą księgować się na jednym saldzie bez warstwy uzgadniania, która łączyłaby osobne systemy.

01Zapis podwójny: każde księgowanie się bilansuje, debety równają się kredytom
02Append-only: korekty to nowe wpisy, nigdy edycje
03Jeden model konta dla fiat, kart i krypto
04Status KYC podróżuje z kontem, a nie w osobnej tabeli

Płatność od początku do końca

Jedna płatność, od utworzenia do uzgodnienia.

Płatność to nie jedno wywołanie, lecz krótki cykl życia, a każdy etap jest stanem widocznym zarówno dla księgi, jak i dla Twoich systemów. Każda zmiana stanu wysyła webhook, a każdy zapis jest idempotentny — ten sam klucz odtwarza ten sam wynik, więc ponowione żądanie nigdy nie obciąży dwukrotnie.

01
Utworzenie
Otwierana jest intencja: kwota, waluta, zaangażowane konta. Nic jeszcze się nie przesunęło — księga zapisuje wpis oczekujący.
02
Autoryzacja
Szyna sprawdza środki i ryzyko i zakłada blokadę. Dla karty to autoryzacja; dla przelewu — rezerwacja debetu.
03
Capture
Zablokowana kwota zostaje zatwierdzona. Księga zapisuje podwójny wpis, który faktycznie przenosi wartość między dwoma kontami.
04
Rozliczenie
Środki są rozliczane przez bazową szynę — system kartowy, bank lub łańcuch — a konta rozliczeniowe uzgadniają się z prawdziwymi pieniędzmi.
05
Uzgodnienie
Platforma porównuje własne księgowania z raportem rozliczeniowym szyny; wszystko, co się nie zgadza, jest oznaczane, a nie ukrywane.

Webhooki i idempotentność działają na każdej krawędzi tego przepływu. Twoje systemy dowiadują się o ruchu płatności z otrzymanego zdarzenia, a nie z odpytywania, a każde żądanie ponowione po przekroczeniu czasu daje ten sam wynik, o ile ma ten sam klucz idempotentności — więc powtórka nigdy nie obciąży dwukrotnie. Usługa obsługująca autoryzację i capture to bramka płatnicza.

Warstwa aplikacji

Aplikacje whitelabel na wierzchu, jedna platforma pod spodem.

Rdzeń udostępnia możliwości, a warstwa aplikacji zamienia je w produkty. Każda aplikacja dla klienta — webowa i mobilna — to klient whitelabel, który pokazuje te same konta, płatności i karty pod własną marką. Motywy oparte są na tokenach: kolory, typografia, zaokrąglenia i odstępy pochodzą z systemu design tokenów (PDS), więc operator zmienia wygląd całego interfejsu, zmieniając tokeny, a nie forkując aplikację. Tę samą platformę można skierować w bardzo różne strony — neobank konsumencki, aplikację acquiringową dla merchantów, program wydawania kart, on/off-ramp krypto czy wewnętrzne narzędzie operacyjne — bez rozpadu na pięć osobnych produktów. To jedna platforma w różnych skórkach, każda skonfigurowana, a nie budowana od nowa.

01Klienty whitelabel web i mobile na wspólnych API
02Motywy oparte na tokenach (PDS): zmiana wyglądu konfiguracją, nie forkiem
03Pięć przykładowych kierunków — neobank, acquiring, issuing, ramp, ops
04Nowe powierzchnie się konfiguruje, nie buduje od nowa

Operacje

Zarządzaj z konsoli, z uzasadnieniem w zapisie.

Za każdą aplikacją stoi konsola operatora. To tam konsultant wsparcia sprawdza konto, analityk ryzyka blokuje kartę, a szef operacji odwraca księgowanie. Dostęp do odczytu jest szeroki; do działań uprzywilejowanych — nie. Każda czynność, która rusza pieniądze, zmienia limity lub dotyka środków klienta, wymaga podania powodu przed wykonaniem i zapisuje niezmienny wpis audytowy — kto, na czym, kiedy i dlaczego. Dostęp opiera się na zasadzie najmniejszych uprawnień, więc każdy operator widzi i robi tylko to, na co pozwala jego rola. Tak działa Protocore Center, konsola operatora, i to samo podejście jest wbudowane w każdy system platformy: wrażliwe działania są świadome, przypisane do osoby i możliwe do zweryfikowania po fakcie.

01Szeroki odczyt, ograniczony zapis — działania uprzywilejowane to wyjątek
02Wymagane uzasadnienie przed każdą operacją na środkach
03Niezmienny ślad audytowy: kto, co, kiedy, dlaczego
04Najmniejsze uprawnienia dla każdej roli operatora

Most krypto

Krypto i fiat w jednej księdze.

Krypto nie jest na platformie osobnym silosem; adres krypto to po prostu kolejne konto w tej samej księdze. On/off-ramp przelicza fiat na aktywa cyfrowe i z powrotem na krawędzi systemu — klient zasila saldo kartą lub przelewem i otrzymuje krypto albo sprzedaje krypto i wypłaca na konto bankowe. Wartość on-chain może się rozliczyć aż do szyny bankowej: przychodząca płatność on-chain jest uznawana na koncie, przewalutowana i wypłacana na IBAN, więc odbiorca widzi zwykłe pieniądze na zwykłym koncie bankowym. Ponieważ obie nogi księgują się w jednej księdze podwójnej, ruch zaczynający się on-chain i kończący przelewem bankowym to jedna uzgodniona historia, a nie dwa systemy uzgadniane ręcznie.

01Adres krypto to konto jak każde inne
02On/off-ramp: fiat i aktywa cyfrowe wymieniane na krawędzi
03Rozliczenie on-chain aż do wypłaty na IBAN
04Jedna uzgodniona historia obu nóg transakcji

Powierzchnia dla developerów

API, webhooki i sandbox do budowania.

Wszystko, co robią aplikacje, robią przez udokumentowane API — utworzenie konta, otwarcie płatności, wydanie karty, uruchomienie ramp. Przykładowe wywołania wyglądają tak: POST /v1/wallets lub POST /v1/payments; styl to REST z kluczem idempotentności przy każdym zapisie. Zmiany stanu są dostarczane jako webhooki, więc Twoje systemy reagują na zdarzenia zamiast je odpytywać. Prace trwają na tenancie sandbox — izolowanej kopii platformy z testowymi szynami, na której przejdziesz cały przepływ od utworzenia do uzgodnienia bez ruszania prawdziwych pieniędzy. To, co każdy produkt udostępnia i na jakim poziomie, określa jego pasmo dostępu; strony poszczególnych produktów wyjaśniają, co obejmuje dane pasmo.

01Udokumentowane REST API, idempotentne zapisy
02Webhooki dla każdej zmiany stanu — zdarzenia zamiast odpytywania
03Tenant sandbox z testowymi szynami, odizolowany od produkcji
04Zakres i limity określają pasma dostępu per produkt

Uczciwa granica

Protocore buduje oprogramowanie. Licencja trzyma linię regulowaną.

Produkt płatniczy to dwie połączone rzeczy: regulowane uprawnienie do przechowywania i przesyłania pieniędzy oraz oprogramowanie, które nimi steruje, je rejestruje i uzgadnia. Protocore buduje oprogramowanie. Działalność regulowana — przechowywanie środków klientów, prowadzenie rachunków, przesyłanie pieniędzy w systemie kartowym — leży po stronie własnej licencji operatora lub licencjonowanego partnera: banku, instytucji pieniądza elektronicznego (EMI) albo instytucji płatniczej. Platforma jest zbudowana tak, by pasować do dowolnych regulowanych szyn, które wnosisz, i by dane kart zostawały na szynie, nigdy nie trafiając na Twoje serwery; nie zastępuje tego uprawnienia i żadne oprogramowanie go nie zastąpi. Gdzie przebiega linia regulowana, decydujesz razem z partnerem, a architektura jest zaprojektowana tak, by czysto leżeć po każdej jej stronie.