Webhook afiliacyjny

Webhook afiliacyjny to powiadomienie HTTP wysyłane do innego systemu, gdy wystąpi zdarzenie związane z afiliacją, takie jak konwersja, aktualizacja prowizji lub zmiana statusu wypłaty. W powiązanych integracjach można używać callbacku lub postbacku. Obsługiwane wyzwalacze i ładunki zależą od platformy.

Terminologia: webhook, callback i postback

Nazwy te częściowo się pokrywają w zależności od platformy. Webhook oznacza zdarzeniowe powiadomienie HTTP. Callback to szersze pojęcie określające odpowiedź lub powiadomienie wysyłane do innego systemu. W integracjach afiliacyjnych postback często odnosi się do konwersji przekazywanej przez serwer. Sam kierunek komunikacji nie wyznacza uniwersalnego rozróżnienia.

Przykłady zdarzeń i działania odbiorcy

To przykłady poglądowe, a nie obietnica, że każda platforma udostępnia te wyzwalacze. Przed zaprojektowaniem odbiorcy sprawdź rzeczywisty katalog zdarzeń i wersję ładunku.

Webhooki a odpytywanie

Odpytywanie polega na okresowym wysyłaniu do API zapytań o zmiany. Webhooki wysyłają obsługiwane zdarzenia w chwili ich wystąpienia. Webhooki mogą ograniczyć liczbę powtarzanych zapytań do API, a odpytywanie lub uzgadnianie danych może pomóc odzyskać brakujący stan. Solidna integracja może korzystać z obu metod, zamiast zakładać, że powiadomienia są kompletne i dostarczane we właściwej kolejności.

Przykład zduplikowanego powiadomienia

Po przekroczeniu limitu czasu zdarzenie zatwierdzenia zostaje dostarczone dwukrotnie. Odbiorca rozpoznaje ten sam identyfikator zdarzenia i zapisuje tylko jedną zmianę stanu. Późniejszy zwrot jest odrębnym zdarzeniem, które nadal należy przetworzyć, mimo że dotyczy tej samej transakcji.

Dlatego deduplikowanie każdego webhooka wyłącznie na podstawie identyfikatora transakcji może być błędne. Tożsamość zdarzenia i tożsamość transakcji służą różnym celom.

Kontrole operacyjne

Nie umieszczaj danych uwierzytelniających w publicznych przykładach, rejestruj wyniki dostarczenia bez niepotrzebnych danych klientów i konfiguruj alerty dotyczące powtarzających się błędów. Odbiorca powinien potwierdzać żądania zgodnie z udokumentowanym protokołem nadawcy i bezpiecznie przetwarzać działania finansowe. Uzgadniaj ważne dane stanu z systemem będącym źródłem prawdy, zamiast polegać wyłącznie na czasie dotarcia powiadomienia.

Projektowanie odbiorcy z uwzględnieniem rzeczywistych warunków dostarczania

Sprawdź, które zdarzenie uruchamia powiadomienie i czy dotyczy ono zarejestrowanej, zatwierdzonej czy wypłaconej prowizji. Zapisuj identyfikator zdarzenia oraz identyfikator odpowiedniej encji, weryfikuj żądanie przy użyciu obsługiwanej przez nadawcę metody uwierzytelniania i umieszczaj w kolejce zadania, których nie da się szybko zakończyć.

Przygotuj się na zdarzenia zduplikowane, opóźnione, nieudane i dostarczone w niewłaściwej kolejności. Ponowienie powinno aktualizować ten sam rekord, a nie powodować dwukrotną wypłatę premii. Jeśli zatwierdzenie dotrze przed lokalnym rekordem sprzedaży, pobierz brakujące dane lub uzgodnij stan, zamiast traktować kolejność dostarczenia jako regułę biznesową.

Oficjalna dokumentacja webhooków Stripe opisuje wzorce dostarczania i projektowania punktów końcowych; podpisy i ładunki są specyficzne dla Stripe. Rzeczywiste pola, obsługiwane wyzwalacze i uwierzytelnianie sprawdzaj w dokumentacji platformy afiliacyjnej. Przed powiązaniem webhooka z działaniem finansowym przetestuj nieudane odpowiedzi i uzgadnianie danych.

Informacje o odpowiednich ustawieniach Post Affiliate Pro znajdziesz w dokumentacji webhooków i callbacków . Sprawdź konfigurację i wymagania integracji pod kątem zasad obowiązujących w Twoim programie.

Przebieg w skrócie