Integracja płatności: co naprawdę się z tym wiąże
Integracja bramki płatności nie jest technicznie trudna — nowocześni operatorzy mają dobrą dokumentację i działające przykłady. Trudne jest wszystko poza szczęśliwą ścieżką: nieudane płatności, zwroty, obciążenia zwrotne, zduplikowane zamówienia i to, co dzieje się, gdy klient zamknie kartę w trakcie płacenia.
Ten przewodnik omawia samą integrację i, obszerniej, przypadki brzegowe, w których naprawdę tracone są pieniądze.
Wybierz metody, których używa twój rynek#
Preferencje płatnicze są silnie regionalne. Oferowanie złych metod traci sprzedaż na etapie płatności, czyli w najdroższym możliwym miejscu.
| Metoda | Gdzie się liczy | Na co uważać |
|---|---|---|
| BLIK | Niezbędny w Polsce | Natychmiastowe potwierdzenie, bardzo popularny |
| Szybki przelew | Powszechny w Polsce | Potwierdzenie zwykle szybkie |
| Karta | Międzynarodowo i biznesowo | Wyższy koszt, ryzyko obciążenia zwrotnego |
| PayPal | Międzynarodowo, rozpoznawalna marka | Wyższy koszt, własny proces sporów |
| Apple Pay i Google Pay | Mobilnie, zauważalnie podnosi konwersję | Wymaga HTTPS i weryfikacji domeny |
| Odroczona płatność | Rośnie na wielu rynkach | Ryzyko po stronie operatora, za procent |
| Przelew tradycyjny | B2B i wysokie kwoty | Wolne potwierdzenie; zamówienia czekają |
Zacznij od dwóch, trzech metod, których twój rynek faktycznie używa. Każda dodatkowa to kolejny wybór w koszyku i, subtelniej, kolejna ścieżka do testowania po każdej aktualizacji.
Jak działa integracja#
Kształt jest niemal identyczny u wszystkich nowoczesnych operatorów i warto go zrozumieć, bo z niego wynikają tryby awarii.
- Twój serwer tworzy intencję płatności z kwotą, walutą i odniesieniem do zamówienia.
- Klient trafia na stronę operatora albo wypełnia osadzony formularz.
- Klient autoryzuje w banku lub u wydawcy karty, często z silnym uwierzytelnieniem.
- Operator odsyła klienta na twój adres powrotny — którego nigdy nie wolno traktować jako dowodu zapłaty.
- Operator wysyła webhook do twojego serwera z ostatecznym statusem. To jest prawda.
- Twój serwer weryfikuje podpis webhooka, aktualizuje zamówienie i wysyła potwierdzenie.
- Dane karty nigdy nie dotykają twojego serwera — co trzyma cię poza najcięższą częścią PCI.
Kroki cztery i pięć skupiają większość błędów. Klient może zamknąć przeglądarkę przed powrotem; webhook przyjdzie i tak. Buduj na webhooku, nie na powrocie.
Przypadki brzegowe, w których giną pieniądze#
Nie pojawiają się w testach, a pojawiają się w pierwszym intensywnym tygodniu.
| Sytuacja | Co idzie źle | Obsługa |
|---|---|---|
| Webhook przychodzi dwa razy | Zamówienie przetworzone podwójnie | Idempotencja: przetwarzaj każde zdarzenie raz |
| Webhook przed powrotem | Wyścig nadpisujący status zamówienia | Jawne przejścia stanów, bez cofania |
| Klient zamyka kartę po zapłacie | Zapłacone, brak zamówienia | Twórz zamówienie na webhooku, nie na powrocie |
| Płatność nieudana po rezerwacji stanu | Stan zablokowany bez sprzedaży | Wygaszaj rezerwację po ustalonym czasie |
| Zwrot częściowy | Księgowość przestaje się zgadzać | Modeluj zwroty jako zdarzenie pierwszej klasy |
| Obciążenie zwrotne | Pieniądze przepadły, towar wysłany | Zachowuj dowody; reguły ryzyka przy wysokich kwotach |
| Operator niedostępny | Zero sprzedaży, nie mniej sprzedaży | Druga metoda jako zapas |
Zgodność i testowanie#
Krótka lista pokrywająca to, co drogo kosztuje przy braku.
- Używaj hostowanych pól albo przekierowania, żeby dane karty nigdy nie dotknęły twojego serwera — to ogromnie zmniejsza zakres PCI.
- Silne uwierzytelnienie klienta jest w Europie obowiązkowe; przetestuj ścieżkę kartą, która je wymusza.
- Weryfikuj podpis każdego webhooka. Niezweryfikowany webhook to publiczny punkt końcowy zdolny oznaczyć zamówienia jako opłacone.
- Pokazuj konsumentom ceny z VAT i uwidocznij koszty wysyłki przed ostatnim krokiem.
- Przechowuj dane zamówień i płatności przez wymagany okres podatkowy, a dane osobowe nie dłużej niż to konieczne.
- Przetestuj zwroty i zwroty częściowe przed uruchomieniem, a nie gdy poprosi pierwszy klient.
- Wykonaj realną transakcję na produkcji prawdziwą kartą i zwróć ją sobie. Tryb testowy nie pokrywa wszystkiego.
Najczęstsze pytania
Którego operatora płatności wybrać?
Wybieraj po metodach obsługiwanych na twoim rynku, po prowizjach przy twoim obrocie i po jakości integracji z twoją platformą. Dla polskiego sklepu obsługa BLIK-a to pierwszy filtr. Różnice cenowe między dużymi operatorami są przy skromnym obrocie na tyle małe, że nie są decydujące.
Czy potrzebuję zgodności PCI?
Tak, ale zakres zależy całkowicie od sposobu integracji. Jeśli używasz hostowanych pól płatności albo przekierowania, tak że dane karty nigdy nie dotykają twojego serwera, obowiązek sprowadza się do najprostszej samooceny. Jeśli przetwarzasz dane karty samodzielnie, wchodzisz w zupełnie inny reżim — praktycznie żaden sklep nie powinien tego robić.
Po co webhooki, skoro jest adres powrotny?
Bo powrót zależy od przeglądarki klienta. Jeśli zamknie kartę, straci połączenie albo utknie na stronie banku, powrót nigdy nie nastąpi — a pieniądze i tak zostały pobrane. Webhook przychodzi z serwera operatora i dociera niezależnie. Buduj zamówienie na webhooku, a powrotu używaj tylko do pokazania czegoś klientowi.
Jak uniknąć zduplikowanych zamówień?
Uczyń obsługę webhooków idempotentną: zapisuj identyfikator każdego przetworzonego zdarzenia i ignoruj powtórki. Operatorzy wysyłają webhooki wielokrotnie, gdy brak potwierdzenia, więc duplikaty to normalne zachowanie, a nie awaria. Bez tej kontroli wyślesz dwa maile potwierdzające i dwukrotnie zdejmiesz stan.
integracja płatnościblik w sklepiebramka płatniczawebhook płatnościzgodność pcipłatności online
