Деньги в вашем приложении: простое руководство по приёму платежей
Приём платежей в приложении, созданном с помощью ИИ, означает подключение к провайдеру вроде Stripe, который берёт на себя форму оплаты картой и переводит деньги — ваше приложение просто фиксирует заказ и реагирует, когда платёж подтверждён.
Есть особый момент, когда ваше приложение перестаёт быть проектом и становится бизнесом: момент, когда кто-то впервые платит вам через него. Это же момент, когда баг перестаёт быть просто неловкостью и превращается в «вы забрали мои деньги, а я ничего не получил». Приём платежей — это самая рискованная функция, которую большинство создателей приложений когда-либо добавляют, и хорошая новость в том, что самые сложные и пугающие части вам строить не придётся. Нужно только правильно всё подключить и не пропускать скучные, но важные случаи.
Это простое руководство по приёму платежей в приложении, созданном с помощью ИИ: что на самом деле происходит «под капотом», какие три вещи чаще всего идут не так, и с какой единственной настройки стоит начать.
Что на самом деле значит «принимать платежи»?
Принимать платежи — значит подключить приложение к платёжному провайдеру (чаще всего для этого берут Stripe, и это отличный выбор по умолчанию), а не строить платёжную систему самому. Вот как распределяются обязанности — это самое обнадёживающее, что стоит понять:
Провайдер показывает форму для ввода карты. Провайдер принимает номер карты, проверяет его и переводит деньги. А затем сообщает вашему приложению ровно одну вещь: «этот человек заплатил вам $40». Ваше приложение никогда не видит номер карты, никогда его не хранит и никак с ним не взаимодействует. Это не ограничение — в этом весь смысл. Данные карт — это минное поле с точки зрения закона и безопасности, и если оставить их полностью на стороне провайдера, минное поле становится его заботой, а не вашей. Если ваш билдер вдруг предложит «сохранить карту в вашей базе данных» — ответ всегда «нет».
Так что настоящая задача вашего приложения в процессе оплаты невелика: отправить клиента на страницу оформления заказа провайдера, а затем правильно отреагировать, когда провайдер сообщит, что деньги прошли.
С чего начать — с разовых платежей или с подписок?
Начните с разовых платежей. По сути, это та же базовая настройка, что и для подписки, только без всех сложностей повторяющихся списаний, а большинству первых продуктов и нужно-то всего «заплатить один раз и получить то, за чем пришёл». Подписки добавляйте позже и осознанно — когда у вас действительно появится что-то, за что стоит платить каждый месяц.
Почти все случаи покрываются двумя формами оплаты:
- Разовое списание — покупка билета, шаблона, одной консультации, гайда для скачивания. Деньги проходят один раз — и всё готово.
- Подписка — ежемесячное членство, регулярный тариф. Деньги списываются автоматически каждый месяц, а значит, вы заодно подписываетесь на вопросы «что делать, когда у клиента истечёт срок действия карты», «что происходит при отмене» и «действительно ли прошёл платёж в этом месяце».
Какие ошибки в приёме платежей чаще всего встречаются в приложениях, созданных с помощью ИИ?
Почти любая проблема с платежами в приложении, созданном с помощью ИИ, сводится к трём ошибкам: приложение «забывает», что платёж вообще был; отсутствие чека приводит к тому, что клиенты платят дважды; и тестирование только успешного сценария оплаты — да ещё реальными деньгами. Для каждой ошибки — простая инструкция, которую можно вставить прямо в билдер.
1. Платёж проходит, а приложение о нём забывает. Клиент платит, деньги попадают на счёт у провайдера — а в приложении не остаётся никакой записи о том, кто и за что заплатил. Организатор мастер-класса продал так 30 билетов и в итоге получил деньги в Stripe и таблицу без единого имени. Она понятия не имела, кого пускать на входе.
Решение: в момент подтверждения платежа сохраняйте запись о заказе — кто заплатил, что купил, сколько, когда, и чёткий статус «оплачено: да». Попросите билдер: «Когда платёж проходит успешно, создавай запись о заказе с клиентом, товаром, суммой и статусом оплаты. Опирайся на подтверждение платежа от провайдера, а не на то, что клиент вернулся на страницу благодарности». Последняя часть важна: люди закрывают вкладку, теряют связь или дважды нажимают на кнопку. Надёжный сигнал о том, что деньги прошли, — это сообщение, которое провайдер отправляет напрямую вашему приложению (вебхук), а не то, что браузер клиента добрался обратно до экрана успеха.
2. Нет чека — платят дважды. Человек нажимает «оплатить», видит крутящийся индикатор загрузки, не получает ни письма, ни подтверждения — вообще ничего, — и решает, что платёж не прошёл, и платит снова. Теперь вам нужно оформлять возврат, а доверие к вам падает. Попросите билдер: «В момент завершения платежа отправляй письмо-подтверждение и показывай понятный экран с сообщением, что оплата прошла, и что будет дальше». Тишина после платежа — самая дорогая тишина во всём приложении.
3. Тестирование реальными деньгами. Это ошибка, из-за которой в продакшен незаметно уезжает сломанная оплата. Создатели тестируют оформление заказа, покупая собственный продукт собственной картой, видят, что один раз всё сработало, и считают дело сделанным — ни разу не проверив, что происходит, когда карту отклоняют или платёж возвращают. Одно приложение помечало заказ как «оплачен», даже если карта была отклонена, — просто потому что этот сценарий никто не тестировал; клиент получил продукт бесплатно, а основатель узнал об этом только в конце месяца.
Для этого никогда не нужны настоящие деньги. У каждого провайдера есть тестовый режим с фейковыми номерами карт — включая специальные номера, которые специально созданы для отклонения, чтобы вы могли увидеть, как поведёт себя приложение. Попросите билдер: «Сначала полностью построй и протестируй оформление заказа в тестовом режиме. Обработай случай отклонённой карты и случай возврата, а не только успешный сценарий». Тестовый режим — самая недооценённая и редко используемая функция во всём мире платежей.
То, о чём молчат: теперь вы — бизнес
Есть две вещи, о которых часто забывают. Во-первых, чтобы деньги действительно доходили до вас, провайдеру нужны ваши настоящие реквизиты — бизнес-счёт или банковский счёт, на который переводить выплаты. Это форма, которую вы заполняете один раз, а не то, что приложение придумывает само. Во-вторых, налоги с заработанного — это ваша забота, а не приложения. Ни то, ни другое не сложно, но оба пункта легко застают врасплох, если о них никто не предупредил заранее.
Что стоит построить в первую очередь, добавляя приём платежей?
Сначала постройте ровно одну вещь: один продукт, одну цену, разовый платёж, в тестовом режиме. Устойте перед соблазном сразу добавить корзину, промокоды, тарифы, подписки — пока этот единственный путь не будет работать чисто: деньги «проходят», заказ фиксируется, появляется подтверждение. Этот один рабочий сценарий стоит больше, чем набитое функциями оформление заказа, которое ни разу не пережило отклонённую карту.
Затем дважды проведите «тест незнакомца». Сначала оформите заказ в тестовом режиме с номером карты, которая должна быть отклонена, — приложение говорит правду («платёж не прошёл») или лжёт и всё равно помечает заказ как оплаченный? Потом совершите успешную тестовую покупку — появилась ли запись о заказе и подтверждение, которому вы бы поверили, будь вы клиентом?
Приём платежей ощущается как самая пугающая функция, которую вы когда-либо добавите, но на деле это просто настройка соединений с тремя типичными сбоями — и тестовый режим, который позволяет отрепетировать их все бесплатно. Выберите то единственное, за что стоит платить, подключите одно оформление заказа в тестовом режиме и проведите фиктивную продажу от начала до конца — включая отклонённую карту, — прежде чем к процессу прикоснётся хоть одна настоящая карта. В этом и заключается вся первая задача.