IOSOR

IOSOR База знань

Контракт webhook перед першим надсиланням

Шлях покупця: узгодити signed URL, типи подій і idempotency key до першого prepaid send — спочатку контракт, потім платний трафік.

Prepaid send без контракту webhook — це spend без спільної правди. Покупець має зафіксувати signed URL, перелік подій і idempotency key до того, як перше платне повідомлення спише гаманець — не після питання finance, чому status і ledger розходяться. Ця сторінка — buyer path, не чекліст ключів на запуску і не deep-dive підпису.

Пов’язані: вебхуки й ключі на запуску, вебхуки, що переживають запуск, prepaid-резерв до першого списання, Day-1 runway: що має бути зеленим.

IOSOR — white-label prepaid.

Узгодьте контракт до першого платного send

Платний send означає: гаманець може списати. Контракт означає: product, finance і ops уже ділять, куди йдуть callback, які події — money/status truth, який ключ робить retry безпечним. Launch habits і runway можуть виглядати зеленими, поки контракт — тред у Slack: це не ready. Див.

Signed URL і ownership consumer

Поле контракту Навіщо покупцю
HTTPS callback URL Один destination, який називають product і ops
Owner signing secret Хто ротує; ніколи paste у спільний чат
Правило ACK vs process Persist спочатку; side effects після ACK
Split середовищ Pilot URL ≠ production URL
Fail closed на unknown host Підроблений delivered не рухає ledger

Типи подій, які ділять product і finance

Перелічіть події, що можуть рухати гроші чи статус, до першого send: accepted, delivered, failed, expired, inbound STOP і будь-який verify-результат, який ви візьмете за truth. Неперелічені події fails closed — вони не вигадують рядки ledger. Словник: Спільна мова статусів для product і finance.

Idempotency key до spend

Узгодьте форму ключа до spend: platform event або message ID, зберігається до side effects, читається поруч із рядком debit. Ключ із timestamp плюс body — шлях до double-charge на retry. Soft volume language blocked, доки duplicate-event smoke не покаже один рядок ledger.

Чекліст покупця щодо контракту webhook

  1. Signed production URL названо й має owner до першого платного send?
  2. Перелік подій product і finance записаний — не усно?
  3. Форму idempotency key узгоджено й пишуть до side effects?
  4. Pilot і production consumers розділені з різними секретами?
  5. Unknown/unsigned callback fails closed із чесним status?
  6. Розмова soft USD 1 000/міс blocked, поки контракт у draft?

Почніть з IOSOR

Зафіксуйте продакшн-вебхук у консолі IOSOR та збережіть секретний ключ підпису в безпечному сховищі до першої платної відправки. Налаштуйте обробник так, щоб він спочатку зберігав ідемпотентний ключ та віддавав ACK (200 OK), і лише потім запускав побічні ефекти. Перевірте тестові DLR у журналі подій, щоб фінансовий та продуктовий контури бачили однакові статуси.

Підсумок IOSOR

Ця стаття доводить, що узгодження вебхуків у робочих чатах замість жорсткого контракту створює ризик подвійних списань та розходжень у балансі. Чіткий перелік подій, спільний для продуктової та фінансової команд, блокує появу фантомних записів у реєстрі.

Чи був матеріал корисним?

Пов’язані гіди