Dla produktu finansowego płatność to nie funkcja na liście, tylko moment prawdy. To tutaj klient albo dokończy transakcję, albo porzuci koszyk, a Ty albo pogodzisz salda, albo spędzisz tydzień na szukaniu rozjazdu. Integracja płatności decyduje więc naraz o konwersji, zaufaniu i domknięciu dnia przez księgowość.
Z naszego doświadczenia w projektach bankowych i fintechowych najtrudniejsze nie jest podpięcie pierwszej bramki, tylko utrzymanie wielu metod płatności, wielu dostawców i wielu standardów w jednej, przewidywalnej całości, która nie wywraca się przy pierwszym timeout’cie. Ten artykuł jest więc o tym, jak zbudować warstwę płatności, która wytrzyma lata, i kto powinien ją budować.
Dlaczego integracja płatności jest tak trudna?
Bo płatność nie jest jednym systemem, tylko łańcuchem niezależnych uczestników, z których każdy może zawieść osobno. Między kliknięciem „Zapłać” a zaksięgowaniem środków przewija się bramka, agent rozliczeniowy, organizacja kartowa lub system przelewowy, bank wydawcy i Twój backend - a każde z tych ogniw ma inne SLA i inny sposób zgłaszania błędów.
Do tego dochodzi mnogość standardów obsługiwanych równolegle: karty i 3-D Secure, przelewy natychmiastowe, BLIK, portfele mobilne, a coraz częściej open banking. Każdy standard niesie własne reguły autoryzacji, zwrotów i reklamacji, a regulacje (PSD2, SCA) dokładają kolejną warstwę wymagań. Integracja płatności jest więc projektem na styku technologii, finansów i zgodności - i to ten styk najczęściej przerasta pojedynczy zespół produktowy.
Czym są bramki płatnicze i PSP i czym się różnią?
Warto rozdzielić cztery pojęcia, które w rozmowach biznesowych często się zlewają:
- bramka płatnicza (payment gateway) to warstwa techniczna, która przyjmuje dane płatności, szyfruje je i przekazuje dalej - to „wtyczka” między Twoją aplikacją a światem rozliczeń,
- PSP (payment service provider) to dostawca usług płatniczych, który daje Ci nie tylko bramkę, ale też agregację wielu metod płatności, rozliczenie i raportowanie w jednym miejscu,
- agent rozliczeniowy (acquirer) odpowiada za faktyczny ruch pieniędzy między bankami,
- orkiestrator płatności to warstwa ponad PSP, która pozwala przełączać dostawców i routować transakcje bez przepisywania integracji.
Decyzja „jeden PSP czy wielu” rzutuje na całą architekturę: wielu dostawców wymaga warstwy abstrakcji, dzięki której dołożenie kolejnej metody płatności nie oznacza przebudowy całości - i to ją najczęściej projektujemy z klientami.
Jak działają przelewy natychmiastowe i jakie standardy obowiązują?
Przelewy natychmiastowe zmieniły oczekiwania klientów: pieniądze mają być na koncie w sekundy, przez całą dobę, także w weekend. Po stronie technicznej oznacza to pracę 24/7 bez okien serwisowych, które kiedyś przyjmowała tradycyjna bankowość. System płatności natychmiastowych nie wybacza przestoju - transakcja albo przechodzi od razu, albo klient od razu wie, że coś nie zadziałało.
W Europie porządkuje ten obszar schemat SEPA Instant Credit Transfer, a w Polsce Express Elixir i BLIK. Każdy z tych systemów narzuca własne limity, formaty komunikatów (coraz częściej oparte na ISO 20022) i reguły potwierdzeń. Nasi inżynierowie podchodzą do tego projektując płatność jako proces asynchroniczny ze statusami, a nie jako pojedyncze żądanie - bo tylko tak obsłużysz i błyskawiczny sukces, i opóźnione potwierdzenie czy odrzucenie.
Jak zadbać o tokenizację i bezpieczeństwo (PCI DSS)?
Dane kartowe to materiał, którego najlepiej u siebie nie trzymać. Fundamentem bezpiecznej integracji jest więc przeniesienie wrażliwych danych poza własne systemy i ograniczenie zakresu zgodności PCI DSS do minimum:
- tokenizacja zamienia numer karty na token, który sam w sobie jest bezużyteczny dla atakującego,
- hosted fields i przekierowania sprawiają, że dane karty nigdy nie dotykają Twojego serwera,
- szyfrowanie w tranzycie i w spoczynku chroni to, co jednak musisz przechowywać,
- segmentacja środowiska i kontrola dostępu zmniejszają zakres audytu PCI DSS,
- 3-D Secure i silne uwierzytelnianie (SCA) przenoszą część ryzyka na wydawcę i spełniają wymóg regulacyjny.
Zgodność PCI DSS to nie jednorazowy certyfikat, lecz sposób projektowania systemu. Architekturę układamy tak, żeby zakres wrażliwych danych był jak najwęższy - im mniej danych kartowych przepływa przez Twoje systemy, tym tańszy audyt i mniejsza powierzchnia ataku.
Jak zapewnić niezawodność, obsługę błędów i reconciliation?
Tę część widać dopiero wtedy, gdy coś pójdzie nie tak, i dlatego tak łatwo ją przeoczyć. Płatność jest rozproszona, więc trzeba założyć, że odpowiedź się zgubi, spóźni albo przyjdzie dwa razy. Projektujemy więc operacje jako idempotentne, z jednoznacznym kluczem transakcji, żeby ponowienie żądania nigdy nie obciążyło klienta dwukrotnie, a każdy status dawało się odtworzyć z logu.
Druga połowa tej pracy to reconciliation, czyli codzienne uzgadnianie tego, co widzi Twój system, z tym, co raportuje PSP i bank. Bez tego salda się rozjeżdżają, a reklamacje rosną. Budujemy więc automatyczne dopasowanie transakcji, raporty rozbieżności i jasną ścieżkę zwrotów oraz chargebacków, a do tego monitoring i alerty na poziomie pojedynczej metody płatności - bo awaria jednej bramki nie powinna wyglądać jak awaria całego produktu.
Jakie kompetencje dostarczamy do projektu płatności?
Nie mamy tu jednej recepty na kształt zespołu - dobieramy skład pod konkretny etap i architekturę. Najczęściej obsadzamy role, które realnie decydują o jakości warstwy płatności:
- backend developerzy (Java, .NET, Node) budujący integracje z bramkami, PSP i systemami przelewowymi,
- architekt rozwiązań projektujący warstwę abstrakcji nad dostawcami i model transakcji,
- specjaliści DevOps / SRE odpowiadający za niezawodność, monitoring i pracę 24/7,
- inżynierowie QA testujący scenariusze błędów, timeouty, zwroty i reconciliation,
- kompetencje bezpieczeństwa i zgodności wspierające PCI DSS i wymogi regulacyjne.
Ważne zastrzeżenie: piszemy tu o kompetencji, nie o gotowym wdrożeniu płatniczym z półki. Dostarczamy ludzi, którzy to zbudują - inżynierów z doświadczeniem w projektach bankowych i fintechowych, wpinanych w Twój zespół i Twoje procesy.
Jak szybko zespół może wejść w projekt płatności?
Liczy się tempo, bo okno rynkowe dla nowej metody płatności bywa krótkie. Jako partner nearshore z Polski pracujemy w zbliżonej strefie czasowej, więc nasi specjaliści wchodzą w Wasz rytm przeglądów kodu i spotkań bez długiego rozruchu. Proces doboru ludzi zwykle zamykamy w okolicach trzech tygodni, a kompetencje weryfikujemy przed startem - przy płatnościach doświadczenia w projektach regulowanych nie zakładamy w ciemno.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, który dokłada kompetencje tam, gdzie ich brakuje, i bierze odpowiedzialność za kawałek systemu:
- obsadzamy role backendu, architektury, DevOps i QA pod konkretną architekturę płatności,
- projektujemy warstwę abstrakcji nad bramkami i PSP, żeby zmiana dostawcy nie była przepisaniem całości,
- automatyzujemy reconciliation, zwroty i obsługę błędów, a zespół wpinamy w Wasze procesy i narzędzia.
Najczęściej jest to dedykowane oprogramowanie budowane przez nasz zespół, a tam, gdzie trzeba szybko uzupełnić kompetencje, model wzmocnienia zespołu.
Od czego zacząć integrację płatności?
Zacznij od jednej, najważniejszej ścieżki płatności (np. płatność kartą z 3-D Secure albo przelew natychmiastowy) i od pytania, jak będzie wyglądać dla niej reconciliation. To wyznacza wybór PSP, model transakcji i potrzebne role. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Budujesz lub przebudowujesz integrację płatności? Porozmawiajmy - dobierzemy zespół i architekturę pod Twój produkt finansowy.