Первый платёж: как добавить настоящие деньги в приложение на ИИ и не ошибиться

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

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

Единственное правило, которое держит вас в безопасности: никогда не храните номера карт

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

Вместо этого вы используете платёжного провайдера — Stripe тут самый распространённый, и большинство ИИ-конструкторов приложений хорошо его знают. Провайдер даёт вам готовую защищённую форму оплаты. Клиент вводит свою карту в форму провайдера, провайдер списывает с неё деньги, а ваше приложение получает только сообщение «да, оплачено». Ваше приложение знает, что платёж состоялся. Оно никогда не знает номер карты.

Когда вы говорите своему ИИ-конструктору добавить платежи, скажите это прямо: «Используй Stripe Checkout (или размещённую форму оплаты Stripe), чтобы моё приложение никогда не работало с сырыми данными карт.» Если конструктор начинает генерировать собственную форму с полем для номера карты — остановите его. Это та самая единственная вещь, которую вы не хотите, чтобы он строил.

Что на самом деле включает «добавление платежей»

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

Цена. Сколько вы берёте и разовый это платёж или повторяющийся. Она живёт у вашего платёжного провайдера, а не зашита в приложение.
Шаг оформления. Кнопка, на которую нажимает клиент и которая отправляет его на защищённую форму провайдера.
Подтверждение обратно в ваше приложение. После оплаты провайдер сообщает вашему приложению «этот человек заплатил за это». Это та часть, которую новички чаще всего пропускают, — и именно так получаются люди, которые заплатили, но не получили доступ.
Запись о том, кто за что заплатил. Чтобы ваше приложение могло открыть нужное и чтобы вы могли позже ответить на вопрос «заплатил ли этот человек?».

Если ваш ИИ-конструктор даёт вам кнопку «Оплатить», которая списывает деньги с карты, но ваше приложение после этого не делает ничего иного — он построил часть 2 и забыл части 3 и 4. Это самый частый наполовину построенный платёжный сценарий, и он выглядит рабочим ровно до того момента, пока клиент не заплатит и не получит ничего.

Как описать это своему ИИ-конструктору

Вот промпт, который покрывает части выше:

Добавь платный доступ в это приложение через Stripe Checkout. Тариф один: $19 в месяц.

Когда залогиненный пользователь нажимает «Улучшить», отправляй его на размещённую страницу оформления Stripe. Не строй собственную форму карты — моё приложение никогда не должно работать с номерами карт.

После успешной оплаты пометь этого пользователя как «оплатившего» в базе данных и открой ему страницу «Отчёты». После неудачной или отменённой оплаты верни его на страницу тарифов с сообщением.

Используй вебхук Stripe, чтобы подтвердить оплату на стороне сервера, прежде чем что-либо открывать, — не открывай доступ только по тому, что пользователь вернулся на страницу успеха.

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

Тестируйте на ненастоящих деньгах до настоящих

Stripe (и большинство провайдеров) дают вам тестовый режим с ненастоящими номерами карт, которые ведут себя как настоящие, — включая карты, которые проходят, карты, которые отклоняются, и карты, которые вызывают ошибки. Пользуйтесь им. Прежде чем по вашему приложению ударит хоть одна настоящая карта, пройдите по каждому пути:

Успешная оплата. Открылось ли то, что должно? Сменился ли статус пользователя на «оплатил»?
Отклонённая карта. Обработало ли приложение это аккуратно или оставило пользователя застрявшим на сломанном экране?
Отменённое оформление — пользователь нажимает «назад» вместо оплаты. Оказался ли он в разумном месте, по-прежнему без улучшения?
Оплата, затем выход и повторный вход. Он всё ещё «оплатил»? (Это ловит приложения, которые открывают доступ только на текущую сессию и забывают к завтрашнему дню.)

Попросите у своего ИИ-конструктора номера тестовых карт или найдите их в документации провайдера. Распространённую тестовую карту для «этот платёж проходит» конструктор может дать вам по запросу. Прогоните все четыре сценария. Путь с отклонённой картой и путь с отменённым оформлением — те, что ИИ-конструкторы чаще всего оставляют сломанными, потому что счастливый путь — это тот, под который они оптимизируют.

Ошибки, которые стоят настоящих денег

Несколько конкретных режимов отказа возникают снова и снова в первых платёжных сценариях:

Открытие доступа по странице успеха вместо вебхука. Уже разобрано выше, но стоит повторить, потому что это дорогая ошибка. Если ваше приложение открывает платные функции в тот же миг, как пользователь попадает на /success, вы доверяете браузеру пользователя быть честным насчёт того, заплатил он или нет. Он не всегда честен. Открывайте доступ по вебхуку.

Нет записи о том, за что они заплатили. Если ваше приложение просто переключает глобальный флаг «оплатил: да», вам станет трудно в тот момент, когда у вас появится больше одного тарифа, или кто-то отменит подписку, или понадобится оформить возврат. Храните конкретику: какой тариф, когда и идентификатор этого платежа у провайдера. Это понадобится вам позже для вопросов в поддержку.

Забывание о том, что подписки заканчиваются. Разовый платёж прост: оплачено значит оплачено. Повторяющаяся подписка может прекратиться — карта истечёт, платёж не пройдёт в следующем месяце. Если ваше приложение слушает только «они заплатили» и никогда «их подписка закончилась», у вас будут люди, сохраняющие доступ бесплатно после того, как перестали платить. Скажите конструктору обрабатывать и сообщение «подписка отменена или платёж не прошёл», а не только успех.

Списание неверной суммы из-за того, что цена живёт в двух местах. Если цена прописана на экране вашего приложения и задана у платёжного провайдера, они рано или поздно разойдутся, и клиент увидит $19, а спишется с него $29. Держите цену в одном месте — у провайдера — и пусть ваше приложение показывает то, что говорит провайдер. Один источник истины.

Короткий чек-лист перед запуском

Прежде чем переключиться из тестового режима на настоящие деньги:

В моём приложении нет поля, куда кто-то вводит сырой номер карты.
Платёж подтверждается вебхуком от провайдера, а не тем, что пользователь дошёл до страницы успеха.
Я протестировал успешную оплату, отклонённую карту и отменённое оформление — все три ведут себя разумно.
После оплаты доступ остаётся открытым после выхода и на следующий день.
Моё приложение записывает, за что заплатил каждый, а не только то, что он заплатил.
Если подписка прекращается, доступ снимается автоматически.
Я переключил ключи провайдера из тестового режима в боевой (легко забыть — ваш первый настоящий клиент, попавший на тестовые ключи, получит непонятную ошибку).

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

Настрой, который помогает

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

Поэтому относитесь к платёжному сценарию как к той единственной части приложения на ИИ, которую вы тестируете как скептик. Попробуйте попасть внутрь без оплаты. Попробуйте его сломать. Заплатите, а затем попробуйте потерять доступ. Те 30 минут, что вы потратите, пытаясь обмануть собственное приложение, — самая дешёвая страховка, которую вы когда-либо для него купите.

Собираетесь добавить платежи в то, что построили? Откройте следующую сессию с ИИ-конструктором, описав весь сценарий — цену, оформление, подтверждение вебхуком и то, что открывается, — за один раз, а не просто попросив кнопку «Оплатить». Кнопка «Оплатить» — это лёгкие 10%. Остальные 90% — это то, что держит деньги честными.