Raty i BNPL w sklepie - integracja PayPo, Twisto i bramek ratalnych

Statusy i notyfikacje przy ratach i płatnościach odroczonych

Najwięcej błędów w integracjach BNPL dotyczy statusów. Dokumentacja PayU dla rat opisuje trzy wyniki procesu po stronie partnera kredytowego: SUCCESS, gdy finansowanie zostało przyznane, FAIL, gdy wniosek został odrzucony lub nie da się go rozpatrzyć, oraz PENDING, gdy partner nie może od razu zweryfikować danych lub podjąć decyzji. W tym ostatnim przypadku klient widzi stronę z informacją, że wniosek jest rozpatrywany, i przycisk powrotu do sklepu.

Dla sklepu oznacza to, że powrót klienta na stronę podziękowania nie jest dowodem zapłaty. O wyniku decyduje notyfikacja z operatora, którą system sklepu musi odebrać i potwierdzić. Mapowanie statusów warto zaprojektować z góry:

• wniosek w toku - zamówienie czeka na płatność, nie trafia do pakowania, a rezerwacja towaru ma rozsądny termin,

• finansowanie przyznane - zamówienie dostaje status opłaconego i dopiero wtedy idzie do magazynu i do integratora,

• wniosek odrzucony - klient dostaje możliwość zapłaty inną metodą, a zamówienie nie jest anulowane automatycznie od razu,

• transakcja oczekuje na odbiór - jeśli punkt płatności ma wyłączony autoodbiór, ktoś musi ją zatwierdzić, inaczej pieniądze nie wpłyną.

Ostatni punkt jest łatwy do przeoczenia. Według dokumentacji PayU autoodbiór jest domyślnie włączony, ale można go wyłączyć dla punktu płatności. Wtedy każdą transakcję trzeba potwierdzić ręcznie w panelu albo przez API. Jeśli sklep ma wyłączony autoodbiór z powodu innych metod, a integracja o tym nie wie, zamówienia ratalne mogą utknąć w stanie oczekiwania. Zasady bezpiecznego odbierania notyfikacji, w tym weryfikację podpisu i obsługę powtórzeń, opisujemy we wpisie o tym, jak działają webhooki w e-commerce.

Kiedy pokazać metodę - zakresy kwot i warunki dostępności

Każda metoda odroczona i ratalna ma minimalną i maksymalną kwotę transakcji, a część ma też ograniczenia co do waluty, kraju lub rodzaju klienta. Dokumentacja PayU podaje takie zakresy osobno dla każdego dostawcy i rynku. Sklep, który pokazuje metodę przy każdym koszyku, naraża klienta na odmowę już po przekierowaniu, co wygląda jak awaria sklepu, a nie decyzja dostawcy.

Dlatego w koszyku warto ukrywać metody, których kwota zamówienia nie mieści się w zakresie, i przeliczać to po każdej zmianie koszyka, kodu rabatowego lub kosztu dostawy. Zakresy najlepiej trzymać w konfiguracji, a nie w kodzie, bo dostawcy je zmieniają. Gotowe wtyczki często robią to same, ale przy własnym koszyku, sklepie headless albo niestandardowych rabatach trzeba to sprawdzić osobno.

Osobną kwestią są sklepy sprzedające firmom. Część metod odroczonych jest przeznaczona dla konsumentów, a część, jak opisany w dokumentacji PayU PragmaPay, tylko dla zakupów firmowych. W sklepie z klientami B2C i B2B metoda powinna pojawiać się w zależności od typu klienta lub danych do faktury, a nie zawsze. W przeciwnym razie klient wybierze metodę, która nie jest dla niego, i dostanie odmowę dopiero u dostawcy.

Druga decyzja to wybór drogi integracji. Poniżej porównanie, które pomaga ją podjąć:

[#chart:wpr71b]

Zwroty i korekty przy płatnościach odroczonych i ratach

Przy BNPL pieniądze wracają do dostawcy finansowania, a nie bezpośrednio na konto klienta. Jeśli sklep odda pieniądze przelewem poza systemem operatora, dostawca nie dostanie informacji o zwrocie i klient nadal będzie miał do spłaty pełną kwotę. Dlatego każdy zwrot, pełny i częściowy, musi przejść przez API lub panel operatora albo dostawcy, w którym była transakcja.

W integracji oznacza to kilka wymagań. Zwrot z panelu sklepu powinien wywoływać zwrot w API operatora, a nie tylko zmieniać status zamówienia. Zwrot częściowy musi przekazywać właściwą kwotę, uwzględniającą rabat rozłożony na produkty i koszt dostawy. Integracja powinna też zapisywać identyfikator zwrotu z operatora, żeby księgowość mogła połączyć korektę z wypłatą. O tym, jak łączyć wypłaty od operatorów z zamówieniami i korektami, piszemy we wpisie o eksporcie zamówień do księgowości.

[#uwaga] Zasady zwrotów, terminy wypłat dla sklepu, zwrot prowizji przy anulowaniu i odpowiedzialność przy reklamacjach wynikają z umowy z operatorem lub dostawcą, a nie z wtyczki. Zanim zaprojektujesz automatyzację zwrotów, sprawdź te zapisy w umowie i regulaminie, a w sprawach prawnych skonsultuj się z prawnikiem.

Raty i BNPL a ERP, integrator i marketplace

Zamówienie opłacone ratami lub płatnością odroczoną trafia dalej do systemów, które często znają tylko kilka typów płatności. Jeśli integracja przekaże je jako płatność przy odbiorze albo jako nieopłacone, magazyn wstrzyma wysyłkę, a kurier dostanie przesyłkę z pobraniem. Z kolei przekazanie jako zwykłego przelewu utrudnia uzgadnianie wpłat, bo pieniądze przyjdą zbiorczo od operatora, a nie od klienta.

Dlatego w mapowaniu metod płatności warto mieć osobną pozycję dla każdej metody odroczonej i ratalnej, oznaczoną jako przedpłata, z nazwą dostawcy. Dzięki temu w raportach widać udział BNPL w sprzedaży, księgowość wie, od kogo spodziewać się wypłaty, a obsługa klienta wie, jak poprowadzić zwrot. Zamówienia z marketplace'ów to osobny temat: tam płatności odroczone obsługuje platforma, a sklep dostaje zamówienie już opłacone, więc integracja nie musi niczego zmieniać po swojej stronie.

Najczęstsze błędy przy integracji rat i BNPL w sklepie

Poniżej problemy, które najczęściej znajdujemy w sklepach z płatnościami odroczonymi. Większość z nich wychodzi dopiero przy pierwszym zwrocie albo w szczycie sprzedaży:

1. zamówienie oznaczane jako opłacone po powrocie klienta, a nie po notyfikacji,

2. brak obsługi stanu oczekującego, przez co wniosek w toku wygląda jak porzucona płatność,

3. metoda widoczna przy koszykach spoza zakresu kwot dostawcy,

4. zwrot zrobiony przelewem zamiast przez operatora,

5. metoda odroczona przekazana do ERP jako płatność przy odbiorze.

[#chart:wpr71c]

Informacja o ratach na karcie produktu

Klient powinien wiedzieć o możliwości zapłaty później lub w ratach, zanim trafi do koszyka. Operatorzy udostępniają do tego widgety, np. PayU opisuje widget kredytowy i zaleca umieszczanie go na listach produktów, kartach produktu, w koszyku i przed płatnością. Technicznie warto ładować go tylko tam, gdzie ma sens, i przekazywać mu aktualną cenę, także po wyborze wariantu. Treść komunikatów o ratach podlega przepisom o kredycie konsumenckim, dlatego ustal ją z dostawcą i skonsultuj z prawnikiem.

Jak testować integrację rat i BNPL przed uruchomieniem

Płatności odroczone trudno przetestować na produkcji, bo każda prawdziwa transakcja to wniosek o finansowanie. Dlatego testy warto prowadzić w środowisku testowym operatora, o ile udostępnia ono daną metodę, a scenariusze ułożyć tak, żeby objęły wszystkie wyniki decyzji, a nie tylko sukces. Szczególnie ważne są sytuacje, w których klient zamyka kartę przeglądarki u dostawcy albo wraca do sklepu, zanim decyzja zapadnie. Wtedy jedynym źródłem prawdy jest notyfikacja, a sklep musi poprawnie zaktualizować zamówienie bez udziału klienta.

[#checklista] Przed uruchomieniem rat i BNPL sprawdź: zamówienie z przyznanym finansowaniem; wniosek odrzucony i ponowną płatność inną metodą; wniosek w toku i późniejszą notyfikację; zamknięcie przeglądarki u dostawcy; koszyk poniżej i powyżej zakresu kwot; zmianę koszyka po wyborze metody; zwrot pełny i częściowy przez API operatora; przekazanie zamówienia do ERP i integratora jako przedpłaty; widok metody w raportach i w eksporcie do księgowości.

Jak Vinson pomaga przy integracji rat i BNPL

Programiści Vinson wdrażają płatności ratalne i odroczone w sklepach na WooCommerce, Shoperze, PrestaShop i Shopify oraz w sklepach headless. Konfigurujemy wtyczki operatorów, a przy własnych koszykach integrujemy API bezpośrednio: obsługujemy notyfikacje i statusy, ukrywamy metody spoza zakresu kwot, podpinamy zwroty pod API operatora i mapujemy metody płatności w ERP, integratorze i eksporcie do księgowości. Testujemy też całą ścieżkę: przyznanie finansowania, odmowę, wniosek w toku i zwrot częściowy, a po wdrożeniu sprawdzamy, czy wypłaty od operatora zgadzają się z zamówieniami w sklepie i w księgowości. Więcej znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Jak dodać PayPo lub Twisto do sklepu internetowego?

Najczęściej przez operatora płatności, który ma te metody w ofercie, np. PayU, albo przez integrację udostępnioną przez platformę sklepu. W PayU PayPo i Twisto to osobne metody w REST API, wskazywane parametrem payMethod. Najpierw sprawdź, czy metoda jest aktywna dla Twojego punktu płatności.

Czy sklep dostaje pieniądze od razu przy płatności odroczonej?

Sklep dostaje zapłatę od operatora lub dostawcy finansowania, a klient spłaca zakup już u dostawcy. Termin wypłaty i ewentualne potrącenia opisuje umowa z operatorem lub dostawcą, dlatego sprawdź je przed wdrożeniem i uwzględnij w uzgadnianiu wpłat.

Dlaczego zamówienie ratalne długo czeka na płatność?

Decyzja o finansowaniu nie zawsze zapada od razu. Dostawca może potrzebować dodatkowej weryfikacji, a wtedy transakcja ma status oczekujący. Sprawdź też, czy punkt płatności nie ma wyłączonego autoodbioru, bo wtedy transakcję trzeba zatwierdzić ręcznie.

Jak zrobić zwrot przy płatności PayPo, Twisto lub ratach?

Zawsze przez panel lub API operatora albo dostawcy, w którym była transakcja. Tylko wtedy dostawca zmniejszy zadłużenie klienta. Zwrot przelewem poza systemem operatora może sprawić, że klient zapłaci dwa razy.

Dlaczego metoda ratalna nie pojawia się w koszyku?

Najczęściej kwota zamówienia jest poza zakresem obsługiwanym przez dostawcę, metoda nie jest aktywna dla punktu płatności albo waluta lub kraj klienta nie pasują do konfiguracji. Zakresy kwot sprawdzisz w dokumentacji operatora i w umowie.

Raty i BNPL mogą ułatwić klientowi decyzję przy droższych zakupach, ale tylko wtedy, gdy integracja poprawnie obsługuje cały cykl transakcji: od pokazania metody, przez decyzję dostawcy, po zwrot i rozliczenie w księgowości. Jeśli chcesz wdrożyć płatności odroczone w sklepie albo uporządkować istniejącą integrację, sprawdź wsparcie programistyczne Vinson.