Automatyczne fakturowanie w n8n po opłaceniu zamówienia

Webhook ze sklepu odpala się po zaksięgowaniu płatności, n8n sprawdza, czy zamówienie jest naprawdę opłacone i jeszcze niezafakturowane, woła API fakturowania i zapisuje numer faktury z powrotem na zamówieniu. Pięć nodów i poranne przepisywanie znika na dobre.

Ostatni przegląd:

Co robi ten workflow

Sam workflow jest banalny. Pieniądze ratują dwa zabezpieczenia wokół niego: nigdy nie wystawiaj na czymkolwiek innym niż potwierdzona płatność i nigdy nie wystawiaj dwa razy na to samo zamówienie. Zbuduj je najpierw, reszta to hydraulika.

Łańcuch nodów n8n wystawiający fakturę po opłaceniu zamówienia.
KrokNode n8nCo robi
TriggerWebhookOdbiera ze sklepu zdarzenie o opłaceniu zamówienia, po HTTPS, z włączoną weryfikacją podpisu
WeryfikacjaIFPrzepuszcza dalej tylko przy statusie potwierdzonej płatności, nie przy oczekującej ani autoryzowanej
DeduplikacjaHTTP RequestOdczytuje rekord zamówienia i przerywa, jeśli numer faktury jest już na nim zapisany
Budowa payloaduEdit Fields (Set)Mapuje pozycje, stawkę VAT, dane nabywcy i datę płatności na kształt wymagany przez API
WystawienieHTTP RequestWysyła fakturę do API i odczytuje numer oraz link do dokumentu
Zapis zwrotnyHTTP RequestZapisuje numer faktury na zamówieniu, żeby deduplikacja zobaczyła go następnym razem
Obsługa awariiError TriggerŁapie nieudany przebieg i powiadamia człowieka, zamiast po cichu porzucić zamówienie

Źródła: Dokumentacja n8n: node Webhook · Dokumentacja n8n: node HTTP Request · Dokumentacja API Fakturowni · ostatni przegląd: 16.08.2026

Konfiguracja krok po kroku

1. Zarejestruj webhook

Dodaj node Webhook, skopiuj jego produkcyjny URL i zarejestruj go w sklepie jako adres powiadomień o opłaceniu zamówienia. Włącz weryfikację podpisu i odrzucaj wszystko, co jej nie przejdzie. Ten endpoint jest publiczny, więc traktuj go jako wrogi, dopóki się nie udowodni inaczej.

2. Postaw bramkę na potwierdzoną płatność

Node IF sprawdzający status płatności to najważniejszy node w całym workflow. Autoryzowana to nie opłacona, a oczekująca to już na pewno nie. Wystawienie dokumentu na którejkolwiek z nich tworzy korektę, którą zrobisz ręcznie.

3. Zrób przebieg idempotentnym

Odczytaj zamówienie i przerwij, jeśli ma już numer faktury. Nadawcy webhooków ponawiają, a bez tego zabezpieczenia ponowienie wystawi drugą fakturę na to samo zamówienie. Tę awarię odkrywa się na koniec miesiąca.

4. Zmapuj payload uważnie

W nodzie Set stawki VAT, opisy pozycji i identyfikatory nabywcy trafiają na to, czego oczekuje API fakturowania. Przy polskim fakturowaniu tu wchodzi też NIP nabywcy, a pomyłka oznacza korektę, nie edycję.

5. Wystaw i zapisz zwrotnie

Wyślij żądanie do API nodem HTTP Request, odczytaj zwrócony numer faktury i zapisz go na zamówieniu. Ten zapis zwrotny sprawia, że krok 3 zadziała przy kolejnym przebiegu, więc nie jest opcjonalny.

6. Łap awarie

Workflow na Error Triggerze wysyłający wiadomość na kanał, który ktoś czyta, zamienia cichą awarię w pięciominutową naprawę. Bez niego pierwszym sygnałem jest księgowa pytająca, gdzie się podział styczeń.

Uwagi z wdrożenia

To automatyzacja, którą budujemy najczęściej, i ta, która najbardziej zaskakuje klientów, bo praca, którą zastępuje, jest niewidoczna, dopóki jej nie policzysz. Ktoś co rano otwiera panel sklepu, czyta opłacone zamówienia i przepisuje je do systemu fakturowego. Dwadzieścia zamówień to czterdzieści minut. Dzieje się to każdego dnia roboczego, jest najmniej ciekawą rzeczą, jaką ktokolwiek w zespole robi, a poziom błędów jest dokładnie taki, jakiego można się spodziewać po czterdziestu minutach przepisywania liczb.

O tym, czy ten workflow jest aktywem, czy obciążeniem, decydują dwie rzeczy i żadną z nich nie jest integracja z API. Pierwsza to bramka płatności: dokument wystawiony na płatność autoryzowaną, ale niepobraną, to korekta, a korekty kosztują więcej, niż automatyzacja zaoszczędziła. Druga to idempotentność. Nadawcy webhooków ponawiają przy timeoutach, a workflow wystawiający fakturę za dostarczenie, a nie za zamówienie, będzie po cichu dublował dokumenty, dopóki ktoś nie uzgodni miesiąca. Każde z tych zabezpieczeń to jeden node. Żadne nie jest efektowne, a ich pominięcie to różnica między pożytkiem a bałaganem. O wyborze platformy pisaliśmy w Make vs n8n vs Zapier, a szersze wdrożenia opisuje strona automatyzacji biznesowych.

← Wszystkie: Automatyzacje

FAQ

Częste pytania

01.Z jakimi systemami fakturowymi to zadziała?

Z każdym, który udostępnia REST API do wystawiania faktur, co obejmuje polskie systemy, o które klienci pytają najczęściej, w tym Fakturownię. Łańcuch nodów jest identyczny; zmienia się tylko mapowanie payloadu w nodzie Set.

02.Co powstrzyma wystawienie dwóch faktur do jednego zamówienia?

Krok deduplikacji. Przed wystawieniem workflow odczytuje zamówienie i przerywa, jeśli numer faktury już na nim jest. Nadawcy webhooków ponawiają przy timeoutach, więc bez tego sprawdzenia ponowienie tworzy zdublowany dokument.

03.Czy to zadziała z Baselinkerem albo WooCommerce?

Tak, jako źródło zdarzenia o opłaceniu. Oba udostępniają dane zamówienia i potrafią zawołać webhook, więc trigger i zapis zwrotny dopasowuje się do tego, co stoi z przodu; fakturowa połowa workflow zostaje bez zmian.

04.Co się dzieje, gdy API fakturowania nie odpowiada?

Przebieg kończy się błędem, a workflow na Error Triggerze powiadamia człowieka. Świadomie nie ponawiamy w ciemno wobec API fakturowania, bo częściowo wykonane wystawienie jest gorsze niż opóźnione. Ponawia człowiek, gdy API wróci.

05.Czy mogę to uruchomić na n8n Cloud zamiast self-hosted?

Tak, workflow jest identyczny. Wybór dotyczy kształtu kosztu i tego, gdzie leżą dane: self-hosted to stały koszt infrastruktury na własnym serwerze, chmura to rozliczenie za wykonania i mniej utrzymania.

Powiązane strony

Który proces kosztuje Cię najwięcej?

Trzydzieści minut, bezpłatnie. Wychodzisz z konkretnym planem naprawy i kwotą, jaką ten proces kosztuje. Plan zostaje u Ciebie, nawet jeśli wdrożysz go bez nas.

Zamów bezpłatny audyt