Prepaid hold до первого списания

Первое движение денег должно быть понятно до оплачиваемого события. В prepaid-сценарии hold резервирует согласованную сумму, но ещё не является списанием. Только после принятой отправки или назначения ресурса ledger фиксирует debit. Так продукт, операции и финансы видят одну последовательность при успехе, отказе и тайм-ауте.

IOSOR использует white-label JIT-путь: цена, prepaid hold, выполнение, назначение результата и точное списание. Минимальное пополнение USD 20 — пол кошелька для пилота, а не входной взнос. Review около USD 1 000 в месяц — мягкий ориентир роста, не условие проверки.

Что резервирует hold

Hold отделяет деньги под один intent, пока результат неизвестен. У него есть сумма, валюта, intent ID, время создания, expiry и понятное состояние: зарезервировано, завершено или освобождено.

Доступный остаток

Показывайте отдельно всего, в резерве и доступно. При USD 50 в кошельке и hold USD 12 новый запрос может использовать USD 38. Параллельные операции не расходуют одни деньги дважды. Hold и debit используют общий correlation ID.

Для messaging резерв может покрывать ограниченный batch, для JIT-заказа номера — подключение и первый период до назначения. В обоих случаях активный hold исключён из available balance.

Когда возникает первый debit

Основанием служит наблюдаемый результат, а не клик: принятая отправка, назначенный номер или заранее названное billable event. Если итог меньше резерва, списывается фактическая сумма, разница освобождается. Незаметно превышать hold нельзя.

Ledger хранит intent ID продуктового события, услугу, сумму, валюту, время и финальный статус. Поэтому идемпотентность, retry и деньги входят в устройство кошелька.

Что делать при сбое

Отказ до завершения заканчивается освобождением резерва или явным возвратом. При тайм-ауте JIT-запроса hold снимается; если действие завершилось, но назначение невозможно, нужен видимый операционный статус. См. сбой заказа DID refund и swap.

• Reject до начала работы: debit не создаётся
• Повтор с тем же ключом: возвращается прежний intent
• Ошибка при активном hold: резерв освобождается
• Частичный batch: завершённые units списываются, остаток возвращается
• Неясный исход: retry останавливается до проверки

Проверка перед запуском

1. Видны ли reserved, available и settled отдельно?
2. Есть ли у hold expiry и один business-intent ID?
3. Названо ли доказательство completion для каждого канала?
4. Видны ли release и refund без обращения в поддержку?
5. Переиспользует ли дубль исходный денежный результат?
6. Останавливает ли low balance новые резервы? Проверьте остановка при низком балансе.

Начните с IOSOR

Проверьте логи холдов и авторизаций в консоли IOSOR перед запуском первой списанной транзакции. Убедитесь, что каждый intent ID корректно передает статусы reserved, completed и released через вебхуки. Настройте таймауты автоматического снятия удержаний, чтобы не блокировать доступный баланс клиента при сбоях.

Итог IOSOR

Статья подтвердила, что корректное разделение общего, зарезервированного и доступного баланса предотвращает повторное расходование одних и тех же средств. Холд должен опираться на измеримое событие и завершаться списанием точной суммы с немедленным возвратом остатка.

Делайте списание только по факту оказания услуги и всегда связывайте холд со списанием единым correlation ID. Не списывайте средства 'вслепую' по нажатию кнопки и не превышайте изначально зарезервированную сумму без нового холда.