Elementy internetowe i wydarzenia
Umowy dotyczące dostaw i zdarzeń przychodzących, ponawianie prób i idempotencja — nie tylko higiena klucza API.
Kolejność zdarzeń a księgowanie na ledgerze
Zdarzenia DLR i MO dostarczone w złej kolejności nie mogą psuć reguł debetu prepaid — sekwencja nadejścia to nie prawo pieniądza.
Ops konsumenta webhooka przy wolumenie
Kolejki, backoff i własność DLQ, gdy liczba zdarzeń webhooka opuszcza fazę pilotażową — jeden rytm konsumenta, który produkt i finanse mogą otworzyć bez wątków bohaterskich.
Duplikat webhooka nie może spowodować drugiego obciążenia
Ścieżka błędu: ponowienia i odtworzenia pozostają idempotentne dla środków prepaid i skrzynki — jeden identyfikator zdarzenia, jeden wiersz obciążenia, jedna linia skrzynki.
Bramka podpisu i okna replay
Bramka produkcyjna: zweryfikuj podpis i ogranicz okno replay, zanim jakikolwiek webhook stanie się prawdą o pieniądzach lub statusie — niepodpisane lub stare zdarzenia pozostają fail-closed.
Kontrakt webhooka przed pierwszą wysyłką
Ścieżka kupującego: uzgodnij podpisany adres URL, typy zdarzeń i klucz idempotentności przed pierwszą wysyłką prepaid — najpierw kontrakt, potem płatny ruch.