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

Грошовий шлях має бути прозорим ще до першої оплачуваної дії. У prepaid-моделі hold лише відкладає погоджену суму; це не фінальне списання. Ledger створює debit після прийнятої відправки або призначення ресурсу. Послідовність залишається зрозумілою за успіху, відмови та тайм-ауту.

White-label JIT-процес IOSOR охоплює ціну, prepaid hold, виконання, призначення та точне списання. USD 20 — мінімальна підлога гаманця для пілота, не плата за вхід. Review біля USD 1 000 на місяць лише підказує, коли переглянути умови зростання.

Для чого потрібен резерв

Hold закріплює кошти за одним intent, поки результат не відомий. Запис містить суму, валюту, intent ID, час створення, expiry та стан: зарезервовано, завершено або вивільнено.

Як рахувати доступні кошти

Гаманець показує загалом, у резерві та доступно. Якщо з USD 50 зарезервовано USD 12, інша операція може використати USD 38. Паралельні запити не мають витрачати одну суму двічі, тому hold і debit пов’язує спільний correlation ID.

У messaging резерв покриває обмежений batch, а для JIT-номера — підключення і перший період до призначення. Активні резерви ніколи не входять до available balance.

Доказ для першого списання

Debit спирається на видимий результат, не на натискання кнопки: прийняту відправку, призначений номер чи іншу заздалегідь визначену billable event. Коли підсумок нижчий за hold, фактична сума списується, а різниця вивільняється. Перевищення без нового погодження неприпустиме.

Ledger зберігає intent ID, сервіс, суму, валюту, час і кінцевий стан. Отже, ідемпотентність, retry і гроші є частиною фінансового дизайну.

Розв’язання невдалого сценарію

Якщо дія не завершилась, резерв вивільняють або оформлюють явне повернення. Після тайм-ауту JIT-запиту hold знімають; виконана дія без можливості призначення потребує помітного операційного статусу. Докладніше: збій замовлення DID повернення і заміна.

• Відхилення до старту: debit відсутній
• Той самий ключ: повертається наявний intent
• Помилка під час hold: резерв вивільняється
• Частковий batch: оплачується виконане, решта повертається
• Невідомий результат: retry призупиняється до перевірки

Контрольні питання команди

1. Чи розділено reserved, available і settled?
2. Чи має кожен hold expiry та один business-intent ID?
3. Чи визначено completion для кожного каналу?
4. Чи видно release і refund без звернення до підтримки?
5. Чи повторний запит повертає початковий грошовий результат?
6. Чи блокує low balance нові резерви? Зіставте з зупинка при низькому балансі.

Почніть з IOSOR

Перевірте відображення балансу у консолі IOSOR, щоб переконатися у чіткому розділенні загальних, зарезервованих та доступних коштів. Налаштуйте відстеження вебхуків для подій резервування та списання із спільним correlation ID. Протестуйте сценарії автоматичного розблокування залишку коштів у разі часткового виконання інтенту або таймауту.

Підсумок IOSOR

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

Завжди встановлюйте термін дії для кожного холду та прив'язуйте його до конкретного ідентифікатора бізнес-наміру з можливістю автоматичного повернення нереалізованого залишку. Не списуйте суму, яка перевищує початкове резервування, і не залишайте заморожені кошти без видимого статусу у консолі.