Перша оплата: як додати справжні гроші до застосунку на ШІ, не наробивши помилок

Є конкретний момент, коли застосунок на ШІ перестає бути іграшкою й стає бізнесом: уперше, коли крізь нього рухаються справжні гроші. До цього моменту помилки дешеві. Зламана кнопка дратує. Неправильна сума на екрані, за який ніхто не платить, — це друкарська помилка. Але того дня, коли картку справжнього клієнта списано, помилка коштує реальних грошей — ваших чи їхніх, — і «ШІ так зробив» — не те речення, яке ви хочете сказати комусь, хто оскаржує списання.

Хороша новина: брати платежі в застосунку на ШІ доступніше, ніж звучить, якщо ви знаєте, які частини передати своєму конструктору на ШІ, а яких частин ніколи не торкатися самому. Це гайд про цю лінію.

Одне правило, що тримає вас у безпеці: ніколи не зберігайте номери карток

Почніть звідси, бо це правило, на якому тримається все інше. Ваш застосунок ніколи не має бачити, зберігати чи обробляти сирий номер кредитної картки. Не в базі даних, не у формі, яку ви зробили, не «просто тимчасово». Робота з даними карток напряму звалює на вас купу юридичних і безпекових обов’язків, які не має нести жоден будівник-початківець.

Натомість ви використовуєте платіжного провайдера — Stripe поширений, і більшість конструкторів застосунків на ШІ добре його знають. Провайдер дає вам готову, захищену платіжну форму. Клієнт вводить свою картку в форму провайдера, провайдер її списує, а ваш застосунок лише отримує повідомлення «так, це сплачено». Ваш застосунок знає, що платіж стався. Він ніколи не знає номера картки.

Коли ви кажете конструктору на ШІ додати платежі, скажіть це явно: «Використовуй Stripe Checkout (чи розміщену платіжну форму Stripe), щоб мій застосунок ніколи не обробляв сирі дані карток.» Якщо конструктор почне генерувати кастомну форму з полем номера картки, зупиніть його. Це та єдина річ, яку ви не хочете, щоб він будував.

Що насправді передбачає «додавання платежів»

Корисно знати рухомі частини, перш ніж почати, щоб ви могли зрозуміти, коли чогось бракує. Робочий платіжний потік має чотири частини:

Ціну. Що ви берете й чи це разово, чи повторювано. Це живе у вашого платіжного провайдера, а не вшите в застосунок.
Крок оформлення. Кнопка, яку клієнт клікає, що відправляє його на захищену форму провайдера.
Підтвердження назад у ваш застосунок. Після платежу провайдер каже вашому застосунку «ця людина сплатила за цю річ». Це частина, яку початківці найчастіше пропускають — а пропустити її означає опинитися з людьми, які сплатили, але не отримали доступу.
Запис про те, хто за що сплатив. Щоб ваш застосунок міг розблокувати правильну річ і щоб ви могли відповісти «чи ця людина сплатила?» потім.

Якщо ваш конструктор на ШІ дає вам кнопку «Сплатити», що списує картку, але ваш застосунок потім нічого не робить інакше, він збудував частину 2 й забув частини 3 і 4. Це найпоширеніший напівзбудований платіжний потік, і він виглядає робочим аж до того, як клієнт сплатить і отримає нічого.

Як описати це своєму конструктору на ШІ

Ось промпт, що покриває частини вище:

Додай платний доступ до цього застосунку через Stripe Checkout. Є один план: $19/місяць.

Коли увійшлий користувач клікає «Оновити», відправ його на розміщену сторінку оформлення Stripe. Не будуй кастомну форму картки — мій застосунок ніколи не має обробляти номери карток.

Після успішного платежу познач цього користувача як «сплатив» у базі даних і розблокуй йому сторінку «Звіти». Після невдалого чи скасованого платежу поверни його на сторінку цін із повідомленням.

Використовуй вебхук Stripe, щоб підтвердити платіж на боці сервера, перш ніж щось розблоковувати, — не розблоковуй лише на основі того, що користувач повернувся на сторінку успіху.

Останній абзац — той, що відділяє справжній платіжний потік від крихкого. Дати сторінці успіху розблоковувати доступ означає, що будь-хто, хто дізнається адресу сторінки успіху, може розблокувати його задарма. Вебхук — пряме, верифіковане повідомлення від Stripe до бекенду вашого застосунку — це надійний сигнал. Ваш конструктор на ШІ знає, як це налаштувати; вам просто треба попросити це за назвою.

Тестуйте фейковими грошима перед справжніми

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

Успішний платіж. Чи розблокувалося правильне? Чи змінився статус користувача на «сплатив»?
Відхилена картка. Чи обробив застосунок це гладко, чи лишив користувача застряглим на зламаному екрані?
Скасоване оформлення — користувач клікає «назад» замість того, щоб платити. Чи опинився він десь розумно, усе ще не оновленим?
Сплата, потім вихід і повторний вхід. Чи він усе ще «сплатив»? (Це ловить застосунки, що розблоковують доступ лише для поточної сесії й забувають до завтра.)

Попросіть свій конструктор на ШІ номери тестових карток, чи знайдіть їх у документації свого провайдера. Поширена тестова картка для «цей платіж проходить» — це та, яку ваш конструктор може дати вам на запит. Пройдіться всіма чотирма сценаріями. Шляхи відхиленої картки й скасованого оформлення — ті, що конструктори на ШІ найчастіше лишають зламаними, бо щасливий шлях — той, під який вони оптимізують.

Помилки, що коштують справжніх грошей

Кілька конкретних режимів збою з’являються знову й знову з першими платіжними потоками:

Розблокування на сторінці успіху замість вебхука. Розглянуто вище, але варто повторити, бо це дорогий випадок. Якщо ваш застосунок розблоковує платні функції тієї миті, коли користувач потрапляє на /success, ви довіряєте браузеру користувача бути чесним щодо того, чи він сплатив. Вони не завжди такі. Розблоковуйте на вебхуку.

Немає запису про те, за що вони сплатили. Якщо ваш застосунок просто перемикає глобальний прапорець «сплатив: так», вам буде складно тієї миті, коли у вас більше ніж один план, чи хтось скасує, чи вам треба буде зробити повернення. Зберігайте конкретну річ: який план, коли і ID провайдера для цього платежу. Це знадобиться для питань підтримки потім.

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

Списання неправильної суми, бо ціна живе у двох місцях. Якщо ціна вписана в екран вашого застосунку й задана у вашого платіжного провайдера, вони зрештою розійдуться, і клієнт побачить $19, але буде списано $29. Тримайте ціну в одному місці — у провайдера — і нехай ваш застосунок показує те, що каже провайдер. Одне джерело істини.

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

Перш ніж перемкнутися з тестового режиму на справжні гроші:

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

Якщо кожну галочку поставлено, ви готові до справжньої картки. Якщо ні, це ваша наступна розмова з конструктором на ШІ — перш ніж ви поділитеся посиланням, а не після першого спору.

Налаштування мислення, що допомагає

Гроші — це частина вашого застосунку, де «виглядає робочим» і «справді працює» найдальші одне від одного. Зламаний макет ви бачите одразу. Платіжний потік, що розблоковує доступ без перевірки оплати, виглядає бездоганно — доки хтось не помітить і не розповість друзям.

Тож ставтеся до платіжного потоку як до однієї частини вашого застосунку на ШІ, яку ви тестуєте як скептик. Спробуйте увійти, не сплативши. Спробуйте його зламати. Сплатіть, а потім спробуйте втратити свій доступ. 30 хвилин, які ви витратите на спроби обдурити власний застосунок, — найдешевша страховка, яку ви на нього купите.

Збираєтеся додати платежі до чогось, що ви зібрали? Почніть наступну сесію з конструктором на ШІ, описавши весь потік — ціну, оформлення, підтвердження вебхуком і що розблоковується — за один раз, замість того, щоб просто просити кнопку «Сплатити». Кнопка «Сплатити» — легкі 10%. Інші 90% — це те, що тримає гроші чесними.