Deweloper 7 min czytania

Obsługa timeoutów i ponownych prób w Verification of Payee

Każda integracja Verification of Payee prędzej czy później trafia na bank odbiorcy, który odpowiada wolno albo jest nieosiągalny. Różnica między integracją odporną a zawodną polega na tym, jak obsługuje ona timeout.

Autor Tomaas Vento Starrantino · Recenzja Donato Leone

Obsługa timeoutów i ponownych prób w Verification of Payee

Najważniejsze wnioski

  • Ustaw sensowny synchroniczny timeout i traktuj jego przekroczenie jako wynik niedostępny, a nie jako poważny błąd.
  • Powtarzaj żądania z odpowiednim odstępem (backoff), ale tylko gdy są idempotentne i mają stabilny identyfikator.
  • Zdefiniuj jasną politykę zastępczą dla płatnika na wypadek, gdy wynik nie zostanie uzyskany w wyznaczonym czasie.

Verification of Payee zależy od odpowiedzi zwrotnej z banku odbiorcy. Gdy ten bank działa wolno, jest przeciążony albo tymczasowo nieosiągalny, Twoja integracja musi zdecydować, co robić - a ta decyzja wpływa zarówno na doświadczenie płatnika, jak i na Twoją pozycję zgodności. Najgorsze scenariusze to zamrożony proces płatności albo weryfikacja, która w tle zostaje policzona lub obciążona dwa razy.

Wynik „niedostępny” to funkcja, nie usterka

Schemat definiuje wynik niedostępny właśnie po to, byś nie musiał wymyślać własnej semantyki błędów. Gdy strona odpowiadająca nie zdąży odpowiedzieć na czas, traktuj to jako pełnoprawny wynik, a nie wyjątek.

  • Ustaw synchroniczny timeout dopasowany do budżetu czasowego procesu płatności (często to kilka sekund).
  • Przy przekroczeniu czasu pokaż płatnikowi neutralny stan „niedostępny”, a nie przerażający komunikat błędu.
  • Zdecyduj w ramach polityki, czy płatnik może kontynuować, musi czekać, czy transakcja powinna zostać skierowana do ręcznej weryfikacji.

Bezpieczne ponawianie żądań

Ponowne próby pomagają przy przejściowych awariach, ale szkodzą, jeśli nie są idempotentne. Ponowna próba nigdy nie powinna tworzyć drugiej logicznej weryfikacji ani drugiego obciążenia.

  1. 1 Przypisz stabilny identyfikator żądania do każdej próby weryfikacji.
  2. 2 Powtarzaj przejściowe błędy sieciowe z wykładniczym backoffem i niewielkim limitem prób.
  3. 3 Nigdy nie powtarzaj definitywnego wyniku (zgodność, częściowa zgodność, brak zgodności) - ponawiaj tylko rzeczywiste awarie transportowe.
  4. 4 Uzgadniaj każdą spóźnioną odpowiedź z identyfikatorem żądania, aby została zarejestrowana tylko raz.

Zaplanuj czas oczekiwania, potem decyduj

Wybierz budżet synchroniczny, który obronisz przed zespołami UX i compliance. Po jego przekroczeniu wycofaj się w kontrolowany sposób - pokaż stan „w toku” albo „niedostępny” - zamiast pozwolić żądaniu wisieć, aż płatnik zrezygnuje.

RoxPay zwraca ustandaryzowane wyniki, w tym niedostępny, wspiera idempotentne ponowne próby na podstawie identyfikatora żądania i w przypadku spóźnionych odpowiedzi korzysta z webhooka - dzięki czemu Twoja polityka timeoutów pozostaje prosta.

FAQ

Najczęściej zadawane pytania

Dopasuj go do doświadczenia w procesie płatności - często to kilka sekund przy użyciu synchronicznym. Poza tym limitem przejdź do stanu „w toku” lub „niedostępny”, a nie blokuj płatnika bez końca.

Tylko w przypadku awarii transportowych i tylko z żądaniami idempotentnymi, indeksowanymi stabilnym identyfikatorem. Nigdy nie powtarzaj definitywnego wyniku zgodności - to wynik, nie błąd.

Traktuj go jako zdefiniowany wynik i zastosuj swoją politykę: pozwól płatnikowi kontynuować z ostrożnością, czekaj na odpowiedź asynchroniczną albo skieruj płatność do ręcznej weryfikacji, zależnie od poziomu ryzyka.

Zapewnij niezawodność VoP w produkcji

Porozmawiaj z RoxPay o timeoutach, idempotentnych ponownych próbach i mechanizmach zastępczych webhook w schemacie SEPA VoP.