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

Одно техническое правило, которое стоит знать заказчику

Заказ начинается не тогда, когда экран сказал «успешно», а когда платёжный провайдер прислал уведомление на ваш сервер.

Телефон в момент оплаты может быть свёрнут, убит системой или без сети. Если запуск работы зависит от того, что доложит приложение, часть покупателей заплатит и не увидит ничего. И расскажут об этом именно они.

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

Пять решений, которые дорого менять потом

У кого лежат деньги до сдачи работы. Прямая оплата исполнителю, удержание у площадки или схема через провайдера. Это влияет на код меньше, чем на юридическую конструкцию: подтверждайте с провайдером и юристом, а не с разработчиком.

Что значит «сдано» — настолько точно, чтобы стать значением в базе.

Что покупатель видит до оплаты и что меняется в момент оплаты. Если продаётся файл, ответ обычно такой: до оплаты — версия с водяным знаком, после — оригинал. Мы так и делали: в нашем маркетплейсе доступ к файлу это не право пользователя, а функция состояния заказа.

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

Сколько хранятся доказательства по спору и кто их видит.

Сплитование платежей: кто держит деньги, если сторон две

Как только в продукте появляются двое — заказчик и исполнитель, покупатель и продавец, — вопрос перестаёт быть про оплату и становится про хранение.

Деньги нельзя просто перевести напрямую: тогда вы не можете ни защитить покупателя, ни удержать комиссию, ни разобрать спор. И держать их на своём расчётном счёте тоже нельзя — это уже деятельность платёжного агента, у неё свои требования и свой регулятор.

Рабочая схема одна: деньги удерживает платёжный провайдер, а ваша система говорит ему, когда удержать, когда отпустить и как разделить. Разделение одного платежа между несколькими получателями и называется сплитованием. ЮKassa, Тинькофф и Stripe Connect умеют это по-разному, и выбор провайдера — это не техническая деталь, а решение про то, какие сценарии вам вообще доступны.

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

Возвраты: то, о чём думают в последнюю очередь

Возврат кажется редкой веткой, пока не запустишься. Потом выясняется, что это самая частая нестандартная операция и что она бывает четырёх видов:

Полный до начала работ. Простой случай, и единственный, который обычно предусматривают.

Частичный. Половина суммы обратно, половина исполнителю, комиссия — вопрос отдельный: вы её уже посчитали выручкой или нет? Ответ надо решить один раз и записать, иначе бухгалтерия и продукт будут расходиться каждый месяц.

После выплаты исполнителю. Деньги уже ушли. Вернуть их можно только с будущих выплат или из своего кармана — и правило на этот счёт должно быть в оферте, а не в переписке.

По инициативе банка. Держатель карты оспорил операцию, и деньги списывают у вас автоматически, иногда через месяц. Это худший вид возврата, потому что решение принимаете не вы.

Спросите подрядчика, как в системе устроен второй и третий пункт. Если ответа нет — их не проектировали, и вы столкнётесь с ними на второй неделе после запуска.

Что обычно недооценивают

Выплаты. Принять деньги от сотни людей проще, чем выплатить сотне: там налоговые статусы, самозанятые, реестры, лимиты. Заложите на это отдельное время и отдельный разговор с бухгалтером.

Возвраты. Частичный возврат — это не «минус деньги», а отдельная ветка состояний со своими правилами.

Двойные нажатия. На плохой связи люди нажимают дважды. Проверьте, что ваша система от этого защищена не «кнопкой без повторного нажатия», а на уровне данных.

Если вы на стадии, когда всё это ещё можно решить на бумаге, — самое дешёвое время. Опишите свой сценарий, и мы вернём список решений, которые придётся принять, вместе с ценой первого релиза: она названа на странице разработки мобильного приложения.

Если ещё не читали: нативная разработка или кроссплатформа: когда какой ответ верный.