IOSOR

IOSOR Gabay

Ang duplicate na webhook ay hindi dapat lumikha ng ikalawang debit

Fail path: ang mga retry at replay ay nananatiling idempotent sa prepaid na pera at inbox — isang event ID, isang debit row, isang inbox line.

Ang at-least-once delivery ay magre-retry. Ang isang duplicate na webhook na nagpo-post ng ikalawang debit o ikalawang inbox line ay insidente sa pera at operasyon, hindi 'harmless ack'. Ang pahinang ito ay ang fail path: ang mga retry at replay ay nananatiling idempotent sa prepaid na pera at inbox — hindi ang essay ng API send-idempotency at hindi ang playbook ng inbound SMS retry.

Kaugnay: Gate ng lagda at replay window, Webhook kontrata bago ang unang send, debit row at delivery status sa iisang ledger.

Ang IOSOR ay white-label prepaid.

Ang idempotency ay fail path, hindi slogan

Happy path: isang signed event, isang accept, isang debit. Ang fail path ay sumusunog sa tiwala — timeout, 5xx, provider replay, operator re-push. I-store ang idempotency key mula sa Webhook kontrata bago ang unang send bago ang mga side effect: ledger, inbox, CRM.

Ano ang binibilang bilang duplicate

Signal Ituring bilang duplicate kapag Ligtas na kinalabasan
Event ID Tinanggap na ang ID sa loob ng window ACK; walang ikalawang debit
Message ID Nakaugnay na ang mensahe sa ledger Gamitin ulit ang row; walang bagong charge
Inbox key Na-file na ang MO/MT Walang ikalawang inbox line
Labas ng replay window Stale retry matapos ang gate reject Reject;

Ang pera ay hindi dapat lumipat nang dalawang beses

Ang ikalawang debit para sa parehong event ID ay isang bug kahit na ang produkto ay nagpapakita pa rin ng 'delivered'. Ang finance ay nag-filter sa pamamagitan ng event o message ID at nakakita ng isang prepaid row para sa UTC window na iyon. Ang partial side effects pagkatapos ng ACK — CRM muna, ledger pagkatapos — ay lumilikha ng dobleng katotohanan.

Ang inbox ay hindi rin dapat dumoble

Ang idempotency ay hindi lamang tungkol sa pera. Ang isang replayed inbound o delivery event na nagbubukas ng ikalawang inbox thread ay nagtuturo sa support na humabol sa mga multo at maaaring mag-trigger ng mga autoreply loop. I-store ang inbox key gamit ang parehong event ID na ginamit para sa debit. Ang produkto at finance ay nagbabahagi ng reject/duplicate status.

Checklist ng mamimili para sa mga duplicate-safe na webhook

  • Naka-lock ba ng system mo ang event ID sa ledger bago ang ACK?
  • Nakikilala ba ng iyong CRM ang replay at binabalewala ito?
  • Mayroon ka bang gate para tanggihan ang mga event sa labas ng replay window?
  • Pinapanatili ba ng iyong ledger ang event ID na unique ayon sa UTC window?

Magsimula sa IOSOR

Puwersahin ang isang signed na replay sa loob ng window sa corridor na nakadebit na. I-export ang event id sa tabi ng ledger id at patunayan ang isang debit row at isang inbox row. Kapag may second debit, ihinto ang consumer at i-refund ang sobrang row — huwag i-net sa susunod na trapiko. Ang gate na ito ay pera ng replay, hindi E.164 check at hindi shipping copy.

Buod ng IOSOR

Ang isang replay ay hindi nangangahulugang may bagong pagpapadala ng pondo. Ang bawat natatanging event id ay dapat magtala lamang ng iisang debit sa ledger.

Gawin: Panatilihing nakatutok ang beripikasyon ng pirma at ang replay window sa administrative console. Pagkatapos, patunayan na iisang debit lamang ang naisusulat sa ledger pagkatapos ng isang pumasok na POST sa tinukoy na window, at i-export ang audit log sa UTC para sa beripikasyon.

Huwag: Huwag mag-debit sa bawat natanggap na POST, at huwag kailanman ituring ang muling pagsubok ng network bilang pangalawang hiwalay na invoice.

Nakatulong ba ang gabay na ito?

Mga kaugnay na gabay