Limity kredytowe w sklepie B2B - walidacja, blokady, payment on account

W skrócie

• 1. Limit kredytowy + saldo bieżące = ile klient może jeszcze wydać
• 2. Walidacja w sklepie: soft check w koszyku (cache 5 min), hard check przy checkoutcie (sync)
• 3. Komunikat dla klienta: klar, z opcjami alternatywnymi (BNPL, karta)
• 4. Edge cases: częściowa realizacja, korekty, anulacje wpływają na saldo
• 5. Integracja z ERP: kluczowa - ERP zarządza limitem, sklep tylko sprawdza

Jak limit kredytowy działa

Wzór:

Dostępny limit = Limit kredytowy − Saldo bieżące − Wartość koszyka

Gdzie:

• Limit kredytowy: kwota uzgodniona w kontrakcie (np. 100 tys. zł)
• Saldo bieżące: suma niezapłaconych faktur (np. 60 tys. zł)
• Wartość koszyka: to, co klient chce kupić teraz (np. 25 tys. zł)

W naszym przykładzie: 100 - 60 - 25 = 15 tys. zł pozostaje. OK, zamówienie wchodzi.

Inny scenariusz: 100 - 60 - 50 = -10 tys. zł. Limit przekroczony, blokada.

Skąd dane przychodzą

Limit kredytowy: ustawiony w ERP po podpisaniu kontraktu z klientem. Konfigurowalny per klient, czasem per grupa.

Saldo bieżące: ERP liczy na bieżąco. Każda faktura wystawiona zwiększa, każda zapłata zmniejsza.

Wartość koszyka: wiadomy sklepowi.

Sklep nie liczy limitu samodzielnie - pyta ERP o saldo + limit, wykonuje matematykę, decyduje.

Walidacja w sklepie - soft vs. hard

Soft check (w koszyku):

• Cache 3-5 min (saldo zmienia się ale wolniej niż stany)
• Info dla klienta: pasek z „pozostały limit: 40 000 zł, koszyk: 25 000 zł"
• Jeśli przekroczenie - komunikat, ale klient może zmienić koszyk

Hard check (przy checkoutcie):

• Bez cache, synchronizny call do ERP
• Saldo mogło się zmienić od soft check (nowa faktura, nowa płatność)
• Decyzja binarna: zamówienie wchodzi lub jest blokowane

Przykład komunikatu soft check:

[Pasek w koszyku]
Twój limit kredytowy: 100 000 zł
Saldo bieżące: 60 000 zł
Pozostały limit: 40 000 zł
Wartość koszyka: 25 000 zł
[OK - możesz zamówić na fakturę z 30-dniowym terminem]

Przy przekroczeniu:

[Pasek w koszyku]
Twój limit kredytowy: 100 000 zł
Saldo bieżące: 60 000 zł
Pozostały limit: 40 000 zł
Wartość koszyka: 50 000 zł (przekraczasz limit o 10 000 zł)

Opcje:
1. Zamów mniej (zmniejsz koszyk)
2. Zapłać kartą / BLIK-iem różnicę 10 000 zł, reszta na fakturę
3. Skontaktuj się z opiekunem o podniesienie limitu
4. Skorzystaj z BNPL (Mondu) - bierze ryzyko na siebie, ty kupujesz dalej

Edge cases

1. Częściowa realizacja zamówienia.

Klient zamówił 5 pozycji za 25 tys. zł. Sklep wysyła 3 (15 tys. zł), 2 zostają w oczekiwaniu. Limit zarezerwowany:

• 25 tys. zł na początku (rezerwacja)
• Po częściowej wysyłce: 15 tys. zł zafakturowane, 10 tys. zł nadal zarezerwowane na pending

2. Anulacja zamówienia.

Klient anuluje zamówienie 25 tys. zł. Rezerwacja limitu zostaje zwolniona.

3. Korekta (zwrot, błąd).

Klient zwraca część zamówienia. ERP wystawia korektę (-X zł). Saldo bieżące się zmniejsza, limit się zwalnia.

4. Wygasły kontrakt.

Klient miał kontrakt do 31 grudnia. 1 stycznia limit zerowy (lub kontrakt automatycznie odnowiony - zależnie od polityki).

5. Klient nieaktywny.

Klient nie kupował 3 miesiące, ERP go zablokował (różne polityki). Zamówienia blokowane.

Integracja z ERP

Każdy ERP ma własne pole / endpoint na limit:

Comarch ERP XL:

• Pole Kontrahent.LimitKredytowy + Kontrahent.SaldoBieżące
• Endpoint: Kontrahent/Lista lub Kontrahent/Saldo

SAP S/4HANA:

• BusinessPartner z polami credit limit + open items
• Endpoint OData lub BAPI

Subiekt GT:

• Pole „Kredyt kupiecki" w karcie kontrahenta
• Sfera API

enova365:

• Saldo per kontrahent w module Handel
• REST endpoint /Handel/Kontrahenci/{id}/Saldo

W każdym przypadku: sklep / middleware pobiera (limit, saldo), oblicza dostępny, decyduje.

Integracje z ERP.

Performance - cache i sync

Cache w Redis:

• Klucz: customer_credit:{customer_id}
• TTL: 1-5 minut (saldo zmienia się szybciej niż cenniki)
• Wartość: {limit, saldo, dostepny, last_update}

Cache invalidation:

• TTL
• Webhook z ERP przy zmianie salda (np. nowa faktura, nowa płatność)
• Po zamówieniu w sklepie - invalidacja lokalnie

Synchronization na checkoutcie:

• Force-refresh cache przed hard check
• Lub: bypass cache, query direct (krótki TTL i tak nie ratuje przed race condition)

Alternatywy przy przekroczeniu

Gdy klient przekracza limit, daj mu opcje:

1. Płatność kartą / BLIK-iem części. „Zapłać kartą 10 000 zł, reszta na fakturę". To często działa - klient płaci bezpośrednio różnicę.

2. BNPL (Mondu, Billie, Twisto Biznes). BNPL bierze ryzyko. Klient płaci BNPL-owi, sklep dostaje pieniądze od BNPL natychmiast. Twój limit kredytowy nie jest wymagany.

Płatności B2B.

3. Kontakt z opiekunem. „Skontaktuj się z opiekunem o jednorazowe podniesienie limitu". W ERP-ie po stronie sprzedawcy: tymczasowe zwiększenie limitu.

4. Faktura proforma + przelew tradycyjny. Klient płaci proformy (przed dostawą), nie używa limitu kredytowego.

Workflow zatwierdzania podniesienia limitu

Klient prosi o podniesienie. Workflow:

1. Klient w sklepie: "Skontaktuj się z opiekunem"
2. Sklep tworzy zgłoszenie: "Customer K001 chce podnieść limit z 100k na 150k"
3. Email do handlowca + admina
4. Handlowiec analizuje (historia płatności, marża, kontekst)
5. Decyzja:
   - Zatwierdzono → admin zmienia limit w ERP
   - Odrzucono → klient dostaje uzasadnienie
6. Sklep dostaje webhook → cache invalidation → klient widzi nowy limit

SLA: typowo decyzja w 24-48h godzin. Niektóre firmy mają „instant decyzja" do pewnej kwoty (np. +20% bez konsultacji).

Blokowanie konta

Niektóre scenariusze wymagają pełnej blokady:

1. Niezapłacone faktury > 30 dni po terminie. ERP automatycznie blokuje. Sklep nie pozwala zamówić.

2. Kontrakt wygasł. Bez aktywnego kontraktu - blokada.

3. Klient zalega z dokumentami. ERP-owy stan „dokumenty niekompletne" → blokada.

4. Manualna blokada (np. windykacja). Admin w ERP-ie ustawia flagę. Sklep widzi, blokuje.

Komunikat dla klienta:

[Pasek w koszyku]
Twoje konto jest tymczasowo zablokowane.
Powód: zaległe faktury powyżej terminu.
Skontaktuj się z działem rozliczeń: rozliczenia@sklep.pl

Możesz nadal kupować przy płatności z góry (karta, BLIK).

Najczęstsze problemy

1. Brak cache → checkout wolny. Każdy klick „Złóż zamówienie" = call do ERP. ERP wolne = checkout 5-10s.

2. Za długi cache → klient widzi nieprawdziwy limit. Cache 1h. Klient widzi limit 40k, ale ERP już wystawił fakturę 30k. Klient zamawia za 30k, dostaje blokadę przy hard check.

3. Brak walidacji przy hard check. Tylko soft check. Klient zamawia za przekroczenie limitu. ERP blokuje. Sklep już potwierdził zamówienie. Dramat.

4. Brak alternatyw. Klient przekracza limit → tylko „nie możesz kupić". Klient idzie do konkurencji. Sklep traci sprzedaż. Trzeba alternatyw (BNPL, częściowa płatność).

5. Race conditions. Klient ma 2 sesje (przeglądarka + telefon). Składa 2 zamówienia jednocześnie, każde za 60% limitu. Bez locków - oba przechodzą.

Rozwiązanie: distributed lock w Redis (SETNX z TTL) na customer_id podczas finalizacji.

FAQ

Czy mogę pozwolić klientowi na przekraczanie limitu o pewien procent? Tak, „soft limit" + „hard limit". Soft: 100k (normalny), hard: 120k (z ostrzeżeniem). Klient może kupić powyżej softa ale poniżej harda, dostaje komunikat „przekraczasz, ale jeszcze OK".

Co z klientami nowymi bez historii? Limit startowy ustalany przy podpisaniu kontraktu. Często niski (5-20 tys. zł), rośnie po pierwszych płatnościach w terminie.

Czy BNPL eliminuje potrzebę limitu kredytowego? Nie zupełnie. BNPL dla pewnych klientów, limit dla strategicznych (twoi top klienci). Większe marże w bezpośrednim kontrakcie z klientem.

Czy klient widzi swój limit? W panelu konta - tak. To buduje zaufanie i pozwala planować zakupy.

Co z windykacją? ERP-owe, nie sklepowe. Sklep tylko respektuje blokady ustawione w ERP.

Co dalej

• Pillar procesów B2B: Procesy zakupowe B2B
• Płatności B2B (BNPL, faktoring): Płatności B2B
• Integracja z ERP: Comarch XL
• Wydajność checkoutu: Wydajność checkoutu