IOSOR

IOSOR Знания

Политика за повторен опит при неуспешен DLR в prepaid: кога да опитате отново и кога да спрете да харчите

Failed, rejected и expired не са една и съща дума. Всеки prepaid повторен опит е дебит. Споделете речника на статусите преди тавана, иначе портфейлът гори в задънена улица.

Тикетът казва «неуспешно» и някой удря повторен опит, докато prepaid портфейлът се изпразни. Неуспехът не е статус. undelivered, rejected и expired искат различни действия. В prepaid всеки автоматичен повторен опит е дебитен ред, не безплатна учтивост. Съгласете речника преди цикъла, иначе продуктът гони конверсия, а финансите плащат втория и третия опит към мъртъв номер.

IOSOR е white-label prepaid: същият речник DLR в табло, webhook и износ. Коридор live допуска повторен опит с таван; in setup не се отваря «следващия път». Вижте недоставено, отхвърлено, изтекло и DLR, забавяне и превключване. Близо до USD 1,000+ месечно дебитите за повторен опит по кофа статус влизат в по-плътен търговски прочит.

Речник на статусите преди логиката за повторен опит

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

Статус Автоматичен повторен опит? Кой подписва
Delivered Не Никой
Undelivered / failed С таван Ops
Rejected Не (сменете payload) Продукт
Expired Не (настройте TTL) Продукт

Failed срещу rejected срещу expired

Failed / undelivered означава, че платформата е предала работата, а терминалът не е потвърдил. Ако коридорът е здрав, повторен опит с таван може да спаси конверсия. Rejected е отказ на мрежа или политика: същият номер, същото тяло, почти винаги нов отказ и нов дебит. Expired е време: TTL по-къс от закъснението на коридора, или опашка преди изпращане. Да третирате expired като failed и да удряте опити само множи редове expired. OTP извън прозореца вече не конвертира — портфейлът пак плаща.

Тавани за повторен опит и удар върху портфейла

Сложете таван на автоматичните опити на съобщение и разделете повторното изпращане на потребителя от failover на системата. Всеки опит трябва да съвпада с correlation ID в книгата. «Докато се достави» без таван изпразва prepaid на мъртъв коридор. Финансите трябва да изнесат дестинация, статус, № опит и дебит. Близо до USD 1,000+ цикъл без собственик спира да е тикет и става търговска тема. Когато политиката каже спри, портфейлът спира, дори продуктът да иска още веднъж.

Собственост продукт срещу финанси

Продуктът притежава политиката: кои статуси позволяват повторен опит, TTL, охлаждане на повторно изпращане. Финансите притежават видимостта: дебитира ли всеки опит, съвпада ли износът с webhook. Ops притежава среза на коридора, за да не крие световна средна счупен маршрут. Без същата таблица prepaid не решава «опитай отново» срещу «спри да харчиш». Не оставяйте поддръжката да обещава устен refund, докато книгата таксува всеки опит.

Червени флагове

  • Само sent и failed, но автоматичен повторен опит
  • Три еднакви удара по payload rejected
  • Expired като мрежова авария
  • Failover на системата и повторно изпращане на потребителя на същия дебитен ред
  • «Докато се достави» без таван на опити
  • Обещан повторен опит при каталог in setup
  • Финансов износ без № опит

Започнете с IOSOR

Попълнете речника: failed срещу rejected срещу expired. Сложете таван на автоматичния retry, за да не отваря всеки неуспешен DLR нов prepaid дебит. Бутонът за повторно изпращане от потребителя е отделен от системния опит. Докажете тавана на два live коридора при нисък обем.

Обобщение IOSOR

Retry при failed DLR е таван на разхода, не безкраен цикъл.

Правете: класифицирайте крайния статус, ограничете опитите, експортирайте потребителското повторно изпращане отделно от системния опит. Не правете: да повтаряте rejected или expired като преходен failed.

Полезно ли беше ръководството?

Свързани ръководства