Whitepaper
Payment Standard to otwarty, lekki i tani standard płatności elektronicznych, który eliminuje pośredników, upraszcza proces płatności i umożliwia realne wdrożenie mikrotransakcji.
Wykorzystując istniejącą infrastrukturę bankową (np. system ELIXIR, aplikacje mobilne), omija kosztowne i złożone rozwiązania operatorów kartowych i pośredników.
1. Kluczowe cechy:
- Bezpośredni przepływ pieniędzy – od klienta do sprzedawcy, bez kosztownego pośrednictwa.
- Potwierdzenie transakcji – spełnia te funkcje, które głównie dają bramki płatnicze.
- Ekonomia mikrotransakcji – koszt transakcji nawet poniżej 0.01 PLN.
- Minimalna integracja – działa w oparciu o istniejące systemy bankowe i narzędzia użytkownika (np. aplikacja bankowa).
- Alternatywa dla subskrypcji – wspiera model pay-as-you-go.
| Cecha / System | Payment Standard | Tradycyjni operatorzy |
|---|---|---|
| Koszt transakcji | Stały, bardzo niski (< 0.01 PLN) | Prowizja % + opłata stała |
| Pośrednicy | Brak | Obecni w każdym przepływie |
| Integracja techniczna | Minimalna, oparta o API bankowe | Złożona, wymaga dokumentacji i wdrożeń |
| Chargeback / rezerwy | Brak potrzeby | Obowiązkowe zabezpieczenia finansowe |
| Wsparcie dla mikrotransakcji | Tak | Praktycznie nieopłacalne |
| Ścieżka płatności dla klienta | Szybka, bez przekierowań | Często wieloetapowa z bramkami płatniczymi |
| Natychmiastowe potwierdzenie transakcji | Tak | Tak |
| Środki trafiają bezpośrednio na konto | Tak | Nie, przelew zbiorczy + raporty |
| Elastyczność dla małych biznesów | Wysoka | Ograniczona |
| Klient widzi w historii transakcji | Pełne dane komu płacił i za co | Nieczytelne kody operatora |
| Wymagana umowa | Nie | Tak + wpływ na politykę prywatności i regulamin |
2. Komponenty
System bazuje na rejestrze, w którym są uczestnicy tj. banki.
Jeden Bank może obsługiwać kilka rejestrów - więc nie ma sytuacji vendor-lock.
Pozostała część standardu, to implementacje SDK dla platform.
2.1 Rejestr
Centralny katalog wszystkich współpracujących banków / providerów płatności. Odpowiada, za obslugę linków płatniczych oraz weryfikację transakcji.
2.2 Generowanie linków płatniczych
Za pomocą dedykowanych SDK, bezpośrednio sklep czy dostawca usług płatniczych generuje link płatniczy / kod QR z linkiem płatniczym.
W momencie kliknięcia w link / zeskanowania, aplikacja banku rozpoznaje ten link i uruchamia bezpośrednio aplikację bankową.
Banki poprzez użycie SDK, umieją rozszyfrować link i jego parametry, aby dokonać uzupełenia szablonu transakcji oraz zatwierdzić operację.
2.3 Dwustopniowy mechanizm potwierdzeń
Każda transakcja jest potwierdzana dwu-etapowo tj:
Complete emitowane w momencie finalizacji transakcji przez użytkownika (np. zatwierdzenia w aplikacji bankowej). - Przydatne dla ścieżki UX.
Confirm emitowane po rozliczeniu i uznaniu środków przez bank, co zabezpiecza dostawcę przed zwrotami i nieudanymi transakcjami.
Oba zdarzenia wysyłane są jako webhook do punktu końcowego zdefiniowanego przez dostawcę usług ( w linku płatniczym ), z sygnaturą do weryfikacji w (rejestrze).
3. Transakcje
Koszt transakcji jest stricte technologiczny, brak compliance, brak operacji powoduje, że cały system musi pokryć jedynie “rejestr” jaki jest publiczny.
| Model | Opłata za transakcję | Opłata procentowa |
|---|---|---|
| Inne metody | 0,25 PLN | 1–3% |
| Payment Standard | < 0,01 PLN | 0% |
3.1 Czas realizacji
Informacja o transakcji jest wysyłana natychmiastowo po dokonaniu, zablokowaniu środków.
Czas otrzymania środków pieniężnych jest zgodny z czasem wyjścia i przyjścia sessji między dwoma podmiotami (bankami).
3.2 Bezpieczeństwo
Transakcja odbywa się realnie między Bankiem a Sprzedającym. Rejestr służy do inicjalizacji aplikacji i weryfikacji sumy kontrolnej. Na podstawie tych danych, właściciel rejestru dysponuje tylko i wyłącznie danymi “metrycznymi” o ilości transakcji i operacji.
Zgodność ze standardami jest zapewniana i utrzymana na poziomie instucji tj. Bank, Sprzedawca.
W oferowany modelu Payment Standard, jak w każdej technologii istnieją ryzyka:
| Ryzyko | Opis | Mitygacja |
|---|---|---|
| wycofanie przelewu | Użytkownik po zatwierdzeniu operacji może wycofać przelew | 2 stopnie weryfikacji: complete (UX), confirm (brak opcji wycofania) |
| wyciek kluczy | Wyciek kluczy służących do liczenia sumy kontrolnej | Zabezpieczenia po stronie Banku jak i Rejestru |
| spreparowanie linku | W trakcie transakcji link, zostaje nadpisany innym numerem konta | Walidacja sumy kontrolnej |
| błędna implementacja | Jakiś krok ze standardu został pominięty np. walidacja sumy kontrolnej | Użycie SDK dla pewności implementacyjnej |
- | ryzyko wycieku klucza klienckiego poprzez “dekompilacje” | celowe działanie | rotacja kluczy, przeniesienie klucza na backend |
4. Wnioski i wezwanie do współpracy
Payment Standard dostarcza długo oczekiwany, kompletny standard mikrotransakcji, łączący efektywność kosztową z prostotą integracji.
Zapraszamy banki, dostawców usług i developerów do wspólnego kształtowania przyszłości płatności cyfrowych.