Верифікація та ідемпотентність підпису вебхука

Перевіряйте 6MM Agent webhooks за допомогою сирого запиту та обробляйте повтори, тайм-аути та повторювані події без дублювання бізнес-дій.

View as Markdown

Вебхуки повідомляють партнерський бекенд про асинхронні зміни бізнес-стану. Оскільки доставка може бути повторною, кожен отримувач повинен перевірити підпис перед аналізом довірених даних і обробити подію ідемпотентно.

Заголовки Webhook

ЗаголовокОпис
X-Агент-Часова МіткаТайммарк Unix за секунди.
X-Agent-NonceЗахист від повтору не так.
X-Агент-підписHMAC-SHA256 підпис.
timestamp + nonce + rawBody

Використовуйте точне сире тіло запиту, отримане протягом HTTP , при відновленні підписаного значення. Спочатку парсинг і повторна серіалізація JSON можуть змінити пробіл або ордер полів і отримати інший підпис.

Потік верифікації

  1. Прочитайте часову мітку, нонс і підписні заголовки.
  2. Захопити незмінене сирий запит.
  3. Будуйте timestamp + nonce + rawBody.
  4. Розрахуйте HMAC-SHA256 з партнером API секрет.
  5. Порівняйте розраховані та отримані підписи за допомогою порівняння з постійним часом.
  6. Застосовуйте затверджені перевірки свіжості та неповторного використання.
  7. Розбирати та обробляти подію лише після успішної перевірки.

Коли доступний офіційний Agent SDK -верифікатор, використовуйте його замість того, щоб підтримувати незалежний код підпису.

Ідемпотентність порядку

ВипадокКерованість
Початковий запит на переведенняСтворіть унікальний у світі agentOrderNo.
HTTP тайм-аутЗапитайте оригінальний agentOrderNo перед створенням нового.
PROCESSING відповідьЗачекайте на статус замовлення вебхука або запиту.
Повторюваний вебхукДедуплікація за ключем ідемпотентності та кінцевим статусом.

Зберігайте достатньо інформації, щоб розпізнати повторну доставку і безпечно відновити її:

ПолеМета
Ключ події або бізнесуУнікально ідентифікує сповіщення або операцію.
Номер замовлення партнераПов’язує подію з початковим запитом.
Хеш корисного навантаженняДопомагає виявити суперечливі повторювані корисні навантаження.
Поточний стан обробкиРозрізняє отриману, обробку, успішну та невдалу роботу.
Остаточний статус бізнесуЗапобігає двічі застосування термінальної дії.
Оброблена часова міткаПідтримує політику розслідування та утримання.

Зафіксуйте запис зміни бізнесу та ідемпотентності в одній транзакції, де це можливо. Повторювана подія повинна повертати вже відомий результат замість повторного застосування балансу, порядку чи зміни користувача.

Правило тайм-ауту та повторної спроби

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

Чек-лист виробництва

  • Перевірити підпис перед JSON парсінгом або бізнес-обробкою.
  • Зберігати сирий корпус незалежно від розборованого корисного навантаження.
  • Відхилити застарілі або повторні запити відповідно до затвердженої політики інтеграції.
  • Зробити обробку подій безпечною для повторної та поза порядком доставки.
  • Ідентифікатори подій журналу, номери замовлень партнера, результати обробки та час запиту.
  • Редагувати секрети та значення підписів із журналів і підтримуючих вкладень.