Webhook за плащания: проверка на подписа и обработка на повторения

Запазете точния материал за проверката

Следвайте документацията на конкретния доставчик за проверка на подписа. При схеми, които използват оригиналното тяло, промяна на интервали или повторно сериализиране може да наруши проверката. Конфигурирайте входната обработка така, че необходимите байтове да са налични на правилното място.

Това не означава да записвате цялото тяло и подписите в обикновените логове. Съдържанието може да включва чувствителна информация. За диагностика използвайте безопасни идентификатори, клас на грешката и минимални технически полета, достатъчни за намиране на съответната операция.

Платежни известия

Проверявайте настройката на правилния акаунт

Секретът за webhook трябва да съответства на конкретния endpoint и среда. Тестова и реална конфигурация не се смесват. При множество търговски връзки трябва да е ясно коя настройка се използва за проверката, без да се избира произволно първата налична връзка.

При липсваща или нечетима настройка не представяйте събитието като успешно обработено. Определете кои грешки могат да се поправят оперативно и трябва да се повторят. Окончателно невалидният подпис е различен случай от временно недостъпна конфигурация.

Инструменти за разработчици

Свързвайте събитието с точния запис

След успешна проверка намерете платежния опит чрез надеждна референция. Уверете се, че доставчикът, търговецът, сумата и валутата съответстват на очаквания запис. Самото наличие на валиден подпис не означава, че всяка получена операция може да промени произволна поръчка.

Не използвайте клиентски свободен текст като единствено основание за маршрутизиране. Например бележка с номер на поръчка може да е полезна, но връзката трябва да се потвърди със сървърните данни. При несъответствие пазете ясна техническа причина за разследване.

Прилагайте повторението безопасно

Доставчикът може да повтори същото събитие, ако не е получил навременен отговор. Вашата обработка трябва да разпознава вече приложения резултат. Пазете подходящ идентификатор или устойчиво състояние, което предотвратява второ изпълнение на бизнес действието.

Ако уведомлението е за успешно плащане, повторението не трябва да добавя втори път баланс, да изпраща втори билет или да стартира нова доставка. Защитата трябва да работи и когато две инстанции обработват събитието едновременно, не само в паметта на един процес.

Отговаряйте според реалния резултат

Успешният HTTP отговор трябва да има ясен смисъл: събитието е обработено или е надеждно прието за устойчива доставка според архитектурата. Ако вътрешната услуга е недостъпна и няма надеждно съхранение, безусловното потвърждение може да загуби информацията.

Определете временните грешки, окончателните откази и процедурата за повторно обработване. Ограничете повторенията с подходящи паузи и наблюдение. След изчерпване на допустимия прозорец събитието трябва да остане видимо за оператор, а не да изчезне без причина.

Проверете целия път до поръчката

Тестът не завършва с това endpoint да върне код. Проследете валидно събитие до промяна на поръчката, после повторете същото събитие и потвърдете, че няма втори ефект. Проверете невалиден подпис, забавена доставка и временно прекъсване на вътрешната услуга.

В OrsunPay използвайте актуалната документация за входящите известия и за подписването на съобщенията към вашия бизнес. Това са различни посоки и могат да имат различни правила. Запишете кой наблюдава неуспешните доставки и как се прави безопасен повторен опит без разкриване на секрети.

Източници

• Stripe Webhooks
• OrsunPay: продукти