Przejdź do głównej zawartości

PayPo

PayPo to najpopularniejszy w Polsce dostawca płatności odroczonych. Klient otrzymuje towar od razu, a za zakup płaci PayPo w ciągu 30 dni albo rozkłada płatność na raty. Z perspektywy sklepu rozliczenie z Paymentic odbywa się standardowo — pieniądze otrzymujesz tak jak przy innych metodach, ryzyko niewypłacalności klienta przejmuje PayPo.

W Paymentic PayPo jest jednym z dostawców pod metodą BNPL:

  • paymentMethod: BNPL
  • paymentChannel: paypo

Jak to działa?​

Dane klienta — kto je zbiera?​

PayPo, jako produkt kredytowy, wymaga kompletu danych klienta: imienia i nazwiska, adresu rozliczeniowego, telefonu, e-maila itd. Paymentic ma to rozwiązane w taki sposób, że:

  • Jeśli prześlesz dane klienta w request — PayPo dostaje wszystko od razu, klient nie musi niczego dopisywać po drodze.
  • Jeśli nie prześlesz pełnych danych — bramka Paymentic wyświetli klientowi formularz, w którym poprosi o brakujące pola, a dopiero potem przekaże komplet do PayPo.

Te dwa scenariusze odpowiadają dwóm sposobom integracji opisanym poniżej.

Scenariusz A. Standard — Paymentic dopyta o dane​

Najprostsza integracja: tworzysz transakcję z paymentMethod: "BNPL" i paymentChannel: "paypo", nie martwisz się o komplet danych klienta. Jeśli czegoś brakuje, Paymentic dopyta klienta na swojej stronie przed przekierowaniem do PayPo.

POST https://api.paymentic.com/v1_2/payment/points/{pointId}/transactions
{
  "amount": "349.00",
  "currency": "PLN",
  "title": "Zamówienie #12345",
  "paymentMethod": "BNPL",
  "paymentChannel": "paypo",
  "customer": {
    "email": "[email protected]"
  }
}

W tym wariancie nie wymagamy billingAddress ani innych danych — klient uzupełni je w bramce Paymentic.

Scenariusz B. Direct redirect — pełne dane od razu​

Jeśli zależy Ci na tym, żeby klient po wyjściu z Twojego sklepu trafił bezpośrednio na ekran PayPo, bez pośredniego formularza w bramce, musisz przesłać komplet danych w request. Paymentic wtedy nie ma o co pytać i wykonuje przekierowanie od razu.

POST https://api.paymentic.com/v1_2/payment/points/{pointId}/transactions
{
  "amount": "349.00",
  "currency": "PLN",
  "title": "Zamówienie #12345",
  "paymentMethod": "BNPL",
  "paymentChannel": "paypo",
  "customer": {
    "email": "[email protected]"
  },
  "billingAddress": {
    "firstName": "Jan",
    "lastName": "Kowalski",
    "street": "ul. Kowalska",
    "buildingNumber": "26",
    "flat": "5",
    "postalCode": "43-316",
    "city": "Bielsko-Biała",
    "country": "PL"
  },
  "shippingAddress": {
    "firstName": "Jan",
    "lastName": "Kowalski",
    "street": "ul. Kowalska",
    "buildingNumber": "26",
    "flat": "5",
    "postalCode": "43-316",
    "city": "Bielsko-Biała",
    "country": "PL"
  },
  "order": {
    "customerType": "B2C"
  }
}

Po stronie klienta wygląda to tak: klika "Zapłać", widzi krótki ekran przejściowy i od razu ląduje na stronie PayPo z gotowym wnioskiem do zatwierdzenia.

Brakujące dane = błąd albo dopytanie

Jeśli celujesz w direct redirect, ale w request zabraknie któregoś z wymaganych pól (np. phone albo billingAddress.postalCode), Paymentic zwróci błąd lub w niektórych przypadkach dopytuje klienta — czyli efekt będzie taki sam jak w scenariuszu A. Jeśli direct redirect to dla Ciebie wymóg UX-owy, waliduj komplet danych po swojej stronie zanim wyślesz request.

Krok 2. Przekieruj klienta na redirectUrl​

W obu scenariuszach odpowiedź wygląda standardowo:

{
  "data": {
    "id": "ABCD-123-XYZ-9876",
    "redirectUrl": "https://pay.sandbox.paymentic.com/ABCD-123-XYZ-9876?token=...",
    "whitelabel": null
  }
}

Przekierowujesz klienta na data.redirectUrl. W scenariuszu A trafi najpierw na ekran Paymentic z formularzem uzupełnienia danych, w scenariuszu B — od razu na PayPo.

Krok 3. Odbierz webhook z finalnym statusem​

Po decyzji PayPo (akceptacja albo odrzucenie wniosku), Paymentic wyśle Ci webhook PAYMENT.TRANSACTION_STATUS_CHANGED ze statusem PAID albo FAILED. Na nim opieraj realizację zamówienia.

Szczegóły: PAYMENT.TRANSACTION_STATUS_CHANGED.

Ważne uwagi​

  • PayPo to produkt kredytowy. Decyzja o przyznaniu odroczenia należy do PayPo, nie do Paymentic. Klient z negatywną oceną zdolności kredytowej może dostać FAILED, mimo że request był poprawny.
  • Im więcej danych w request, tym lepszy UX. Każde brakujące pole = jeden ekran więcej dla klienta przed PayPo. To zwykle przekłada się na niższy współczynnik konwersji.
  • cart ma znaczenie. PayPo używa pozycji koszyka do oceny wniosku. Realnie wpisane produkty działają lepiej niż jeden "Zakup w sklepie" o łącznej kwocie.
  • customerType: "B2B" może blokować PayPo. PayPo to produkt detaliczny — w order.customerType ustawiaj B2C dla klientów indywidualnych.
  • Limity kwot. PayPo ma minimalne i maksymalne kwoty zakupu. Jeśli kwota wykracza poza widełki, endpoint channels zwróci available: false dla paypo przy danej kwocie — wtedy nie pokazuj PayPo klientowi na ekranie wyboru.

Dobre praktyki​

  • Przed wysłaniem requestu sprawdź available z GET /channels. Limity PayPo są dynamiczne (zależą od kwoty i waluty) — kanał może być chwilowo niedostępny.
  • Loguj id transakcji obok ID Twojego zamówienia. Reklamacje i rozliczenia z PayPo są łatwiejsze, gdy wiesz, która transakcja Paymentic odpowiada konkretnemu zamówieniu.
  • Nie realizuj zamówienia przed webhookiem PAID. Decyzja PayPo bywa odroczona — redirectUrl zwraca klienta do Twojego returnUrl zaraz po podpisaniu wniosku, ale finalny status przychodzi webhookiem.
  • Używaj B2C w order.customerType dla klientów indywidualnych. Bez tego niektórzy dostawcy (PayPo nie wyłączając) mogą odrzucić wniosek.

Co dalej?​