IOSOR Знания

Когато предплатеният hold се провали: auto-refund и истински статус

Третирайте неуспешен предплатен hold като събитие на портфейла: автоматично освобождаване или refund, експортируеми честни статуси и никога Activated/Delivered без реален резултат.

Предплатен hold, който не може да завърши, трябва да остави пари и статус, които finance защитава. Провал не е «опитайте по-късно»: резервът се връща в available, явен refund обръща settled сума, или именуван статус блокира retry до доказателство. Успех при блокирани средства разрушава ledger доверието.

IOSOR е white-label prepaid. Същото правило важи за messaging, verification, email, voice и JIT номера на един портфейл. Минимумът USD 20 е под на пилота, не доказателство, че fail-пътят работи. Review около USD 1,000/месец само прави fail редовете по-видими.

Провалът е събитие на портфейла, не toast

Спинери и «pending» банери не са парична истина. След fail портфейлът е освободил hold, върнал debit или замразил intent с причина за експорт. Успех при отворен резерв = ledger лъже. Happy path: резервиране на предплатен баланс преди първото дебитиране; тази страница е fail-пътят.

Резултат Движение на портфейла Четим статус
Отказ на валидация преди работа Без hold / незабавен release Rejected — без debit
Провал на fulfillment под hold Пълен release Failed — средства върнати
Timeout без completion Release по expiry Timed out — средства върнати
Settled за обръщане Явен refund ред Refunded — с intent
Неясен mid-flight Freeze retry; без 2-ри debit Needs attention

Auto-refund и release трябва да са автоматични

Ръчното «ops ще оправи по-късно» не е продукт. Release и refund стартират от същите правила, създали резерва. Дубликати със същия idempotency key преизползват паричния резултат — идемпотентност, повторения и пари. Частични batch settle завършени units и връщат остатъка в един експорт.

Release възстановява резерва; refund обръща settled debit. Timestamps, причини и intent ID са задължителни. За номера: неуспешна DID поръчка връщане и замяна; тази статия е паричната истина за всеки канал.

Речник на статуси, който finance експортира

Изискайте кратък списък, който оцелява в CSV:

  • funds held
  • completed / settled
  • released
  • refunded
  • needs attention
  • cancelled

Не измисляйте «Activated», «Delivered» или «Live» за intent без ресурс или billable unit. «Needs attention» е работна опашка, не синоним на успех. Статус без сума, валута и correlation ID е театър.

Никога не фалшифицирайте Activated или Delivered

Фалшиви значки за успех горят доверие по-бързо от празно търсене. Messaging fail ≠ delivered; неотворена verify ≠ verified; JIT без assign ≠ Activated. Low balance и over-cap отказват преди hold — спиране при ниско салдо — за да не влязат пари в задънен резерв.

Чеклист на купувача за честност при fail

  1. Всеки failed hold завършва с release, refund или needs-attention със собственик?
  2. Release и refund автоматични от продуктови събития, не от чат?
  3. Може ли finance да свърже fail редовете с оригиналния intent ID без поддръжка?
  4. Същият ключ мести пари най-много веднъж?
  5. Клиентските грешки brand-safe без upstream имена?
  6. Stop-lines блокират нови holds при нисък available? Вижте стоп линии на портфейла преди продукционен трафик.

Започнете с IOSOR

Предизвикайте prepaid hold, който не може да завърши: таван, отказ или липса. Докажете връщане към available или явен ред refund. Експортирайте fail статуса, който финансите защитават. Повторете същия ключ без второ движение. Това е истина за fail на hold, не освобождаване след мъртъв assign.

Related: контрол на предплатения разход

Обобщение IOSOR

Неуспешният hold е събитие в портфейла, не театър на успех.

Правете: автоосвобождаване или refund и наименуван статус. Не правете: измислен Activated или Delivered.

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

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