Прийом платежів у вашому застосунку: проста інструкція
Прийом платежів у застосунку, який ви створили за допомогою ШІ, означає підключення до провайдера на кшталт Stripe, який показує форму для картки та переказує гроші — ваш застосунок лише фіксує замовлення і реагує, коли платіж підтверджено.
Є момент, коли ваш застосунок перестає бути проєктом і стає бізнесом: перший раз, коли хтось платить вам через нього. Це також момент, коли баг перестає бути просто незручністю і стає «ви взяли мої гроші, а я нічого не отримав». Прийом платежів — це найризикованіша функція, яку додає більшість білдерів, і хороша новина в тому, що складні, страшні частини насправді будувати не вам. Вам просто треба правильно їх підключити і не пропускати нудні випадки.
Це проста інструкція з прийому платежів у застосунку, який ви створили за допомогою ШІ: що насправді відбувається під капотом, три речі, які найчастіше йдуть не так, і те, з чого варто почати.
Що насправді означає «приймати платежі»?
Прийом платежів означає підключення застосунку до платіжного провайдера — найчастіше для цього обирають Stripe, і це цілком нормальний вибір за замовчуванням — а не побудову власної платіжної системи. Ось як розподілена робота, бо саме це найкраще заспокоює:
Провайдер показує форму для картки. Провайдер приймає номер картки, перевіряє його і переказує гроші. Потім провайдер повідомляє вашому застосунку одну річ: «ця людина заплатила вам $40». Ваш застосунок ніколи не бачить номер картки, ніколи його не зберігає, ніколи до нього не торкається. Це не обмеження — це вся суть. Дані картки — це юридичне й безпекове мінне поле, і тримати їх повністю всередині провайдера означає, що це мінне поле — його робота, а не ваша. Якщо ваш білдер колись запропонує «зберігати картку у вашій базі даних» — відповідь завжди «ні».
Тож справжня робота вашого застосунку в платежі невелика: відправити клієнта на сторінку оплати провайдера, а потім правильно відреагувати, коли провайдер підтвердить, що гроші пройшли.
Почати з разових платежів чи з підписок?
Почніть із разових платежів. У них те саме базове підключення, що й у підписки, але без усіх нюансів повторюваних платежів, а більшості перших продуктів потрібне лише «заплати один раз і отримай товар». Підписки додавайте пізніше, свідомо, коли у вас справді буде щось, за що варто платити щомісяця.
Майже все покривають дві форми оплати:
- Разовий платіж — купити квиток, шаблон, одну коуч-сесію, посібник для завантаження. Гроші переходять один раз, і на цьому все.
- Підписка — щомісячне членство, регулярний план. Гроші переходять щомісяця автоматично, а це означає, що ви заодно підписалися на «що робити, коли термін дії картки закінчиться», «що робити, коли клієнт скасує підписку» і «чи справді пройшов платіж цього місяця».
Які найпоширеніші помилки з платежами в застосунку, створеному ШІ?
Майже кожна проблема з платежами в застосунку, створеному ШІ, зводиться до трьох помилок: застосунок «забуває», що платіж узагалі відбувся; немає квитанції, тож клієнти платять двічі; і тестування лише успішного сценарію оплати за реальні гроші. До кожної додається проста інструкція, яку можна вставити своєму білдеру.
1. Платіж проходить, але застосунок про нього забуває. Клієнт платить, гроші потрапляють на ваш рахунок у провайдера — а застосунок не має жодного запису про те, хто і за що заплатив. Одна організаторка воркшопу продала так 30 квитків і в результаті мала гроші в Stripe і таблицю без жодного імені. Вона не мала уявлення, кого впускати на подію.
Виправлення: щойно платіж підтверджується, зберігайте запис про замовлення — хто заплатив, що купив, скільки, коли, і чіткий статус «оплачено: так». Попросіть свого білдера: «Коли платіж проходить успішно, створюй запис замовлення з клієнтом, товаром, сумою і статусом оплати. Спирайся на підтвердження платежу від провайдера, а не на те, що клієнт повернувся на сторінку подяки». Остання частина важлива — люди закривають вкладку, втрачають зв’язок або натискають двічі. Надійний сигнал того, що гроші перейшли, — це повідомлення, яке провайдер надсилає вашому застосунку напряму (вебхук), а не те, що браузер клієнта повернувся на екран успіху.
2. Немає квитанції, тож платять двічі. Людина натискає «оплатити», бачить індикатор завантаження, не отримує ні листа, ні підтвердження, нічого — тож вирішує, що платіж не пройшов, і платить ще раз. Тепер вам доводиться повертати один із платежів, а довіра до вас падає. Попросіть свого білдера: «Щойно платіж підтверджено, надсилай лист-підтвердження і показуй чіткий екран, що каже: оплата пройшла і що буде далі». Тиша після платежу — найдорожча тиша у вашому застосунку.
3. Тестування за реальні гроші. Ось та помилка, яка тихо потрапляє в реліз ще з баґом. Білдери тестують оплату, купуючи власний продукт своєю ж карткою, бачать, що це спрацювало один раз, і вважають справу закритою — жодного разу не перевіривши, що відбувається, коли картку відхиляють або платіж повертають. В одному застосунку замовлення позначалося «оплачено» навіть тоді, коли картку відхилили, бо ніхто не протестував цей сценарій; клієнт отримав продукт безкоштовно, а засновник дізнався про це аж наприкінці місяця.
Для такого тестування реальні гроші не потрібні ніколи. У кожного провайдера є тестовий режим із фейковими номерами карток — включно з конкретними номерами, які спеціально відхиляються, щоб ви побачили, як поведеться ваш застосунок. Попросіть свого білдера: «Спочатку побудуй і протестуй увесь процес оплати в тестовому режимі. Обробляй випадок відхиленої картки і випадок повернення коштів, а не лише успішний сценарій». Тестовий режим — найнедооціненіша функція в усьому світі платежів.
Тиха частина: тепер бізнес — це ви
Дві речі, про які люди забувають. По-перше, щоб справді отримувати гроші, провайдеру потрібні ваші реальні дані — бізнес- або банківський рахунок, на який виплачувати кошти. Це форма, яку ви заповнюєте один раз, а не те, що застосунок вигадує сам. По-друге, податки з того, що ви заробляєте, — це ваш обов’язок, а не застосунку. Жодна з цих речей не складна, але обидві легко можуть вас здивувати, якщо ніхто не скаже про них прямо.
Що варто побудувати першим, додаючи платежі?
Спочатку побудуйте рівно одну річ: один товар, одна ціна, разовий платіж, у тестовому режимі. Утримайтеся від кошика, промокодів, тарифних рівнів і підписок, поки цей шлях не запрацює чисто — гроші «переходять», замовлення записується, з’являється підтвердження. Цей один робочий шлях вартий більше, ніж напхана функціями оплата, яка жодного разу не пережила відхилену картку.
Потім двічі проведіть тест стороннього погляду. Спочатку оформіть замовлення в тестовому режимі з номером картки, яку спеціально відхиляють — застосунок каже правду («це не пройшло») чи бреше і позначає замовлення оплаченим? Потім зробіть успішну тестову покупку — чи отримали ви запис замовлення і підтвердження, яким довіряли б, якби були клієнтом?
Прийом платежів здається найстрашнішою функцією, яку ви колись додасте, а насправді це просто робота з підключення з трьома можливими збоями і тестовим режимом, який дає змогу безкоштовно відрепетирувати їх усі. Оберіть одну річ, за яку варто платити, підключіть один процес оплати в тестовому режимі і проведіть фейковий продаж повністю — з відхиленою карткою і всім іншим — перш ніж до нього хоч раз торкнеться справжня картка. Оце і є вся перша робота.