<b>TON-комиссии в Mini App: где разработчик теряет деньги на каждом платеже</b>

<b>TON-комиссии в Mini App: где разработчик теряет деньги на каждом платеже</b>

TON-платежи в MA выглядят просто, пока не начинаешь считать полный путь денег: перевод, конвертацию, вывод, возвраты и внутренние комиссии кошелька или провайдера. Ошибка на этом этапе почти всегда бьёт не по UX, а по марже.

Что стоит проверить до запуска:
— кто платит комиссию: пользователь, приложение или обе стороны;
— как округляются суммы при оплате и возврате;
— есть ли отдельная логика для микроплатежей, где fee съедает заметную долю чека;
— совпадает ли сумма в интерфейсе, webhook и бухгалтерском учёте;
— что происходит при частичной оплате и повторной попытке транзакции.

Для Mini App важен не только размер комиссии, но и её предсказуемость. Если fee плавает между сценариями, ломается аналитика: ARPU и конверсия по платёжной воронке начинают врать. Для теста достаточно прогнать три сценария — маленький чек, средний чек и возврат — и сравнить, сколько остаётся после всех удержаний.

Отдельно проверьте, как комиссия влияет на Stars vs TON-модель. Если вывод в TON нужен редко, а покупки внутри MA идут часто, иногда выгоднее держать TON только как расчётный слой, а пользовательский чек строить вокруг более простого флоу.

Считайте комиссию не как техническую деталь, а как часть unit economics: чем раньше она попадает в модель, тем меньше сюрпризов в P&L.