Pierwsza płatność: jak dodać prawdziwe pieniądze do aplikacji zbudowanej z AI i nie spartolić tego

Jest taki konkretny moment, w którym aplikacja zbudowana z AI przestaje być zabawką i staje się biznesem: pierwszy raz, gdy płyną przez nią prawdziwe pieniądze. Do tej pory błędy są tanie. Zepsuty przycisk jest irytujący. Błędna suma na ekranie, za który nikt nie płaci, to literówka. Ale w dniu, w którym obciążona zostaje karta prawdziwego klienta, błąd kosztuje rzeczywiste pieniądze — Twoje albo jego — a „AI tak to zbudowało” to nie jest zdanie, które chcesz powiedzieć komuś, kto kwestionuje obciążenie.

Dobra wiadomość: przyjmowanie płatności w aplikacji zbudowanej z AI jest bardziej przystępne, niż brzmi, jeśli wiesz, które części przekazać kreatorowi z AI, a których nigdy nie dotykać samodzielnie. Ten przewodnik jest o tej granicy.

Jedna zasada, która chroni Cię: nigdy nie przechowuj numerów kart

Zacznij tutaj, bo to zasada, na której wisi wszystko inne. Twoja aplikacja nigdy nie powinna widzieć, przechowywać ani obsługiwać surowego numeru karty kredytowej. Ani w bazie danych, ani w formularzu, który zbudowałeś, ani „tylko na chwilę”. Bezpośrednia obsługa danych kart zrzuca na Ciebie stos zobowiązań prawnych i bezpieczeństwa, którego żaden początkujący twórca nie powinien dźwigać.

Zamiast tego korzystasz z dostawcy płatności — Stripe to ten najczęstszy, a większość kreatorów aplikacji z AI dobrze go zna. Dostawca daje Ci gotowy, bezpieczny formularz płatności. Klient wpisuje swoją kartę w formularz dostawcy, dostawca ją obciąża, a Twoja aplikacja dostaje jedynie komunikat „tak, to zostało opłacone”. Twoja aplikacja wie, że płatność się odbyła. Nigdy nie poznaje numeru karty.

Kiedy każesz swojemu kreatorowi z AI dodać płatności, powiedz to wprost: „Użyj Stripe Checkout (albo hostowanego formularza płatności Stripe), żeby moja aplikacja nigdy nie obsługiwała surowych danych kart.” Jeśli kreator zacznie generować własny formularz z polem na numer karty, zatrzymaj go. To jedna rzecz, której zdecydowanie nie chcesz, żeby zbudował.

Co naprawdę obejmuje „dodanie płatności”

Warto znać ruchome części, zanim zaczniesz, żeby wyczuć, kiedy czegoś brakuje. Działający proces płatności ma cztery elementy:

Cena. To, co pobierasz, i czy jest jednorazowa, czy cykliczna. Mieszka u Twojego dostawcy płatności, a nie na sztywno w kodzie aplikacji.
Krok płatności. Przycisk, który klika klient i który przenosi go do bezpiecznego formularza dostawcy.
Potwierdzenie z powrotem do Twojej aplikacji. Po płatności dostawca mówi Twojej aplikacji „ta osoba zapłaciła za tę rzecz”. To część, którą początkujący najczęściej pomijają — a jej pominięcie kończy się tym, że ktoś zapłacił, ale nie dostał dostępu.
Zapis, kto za co zapłacił. Żeby Twoja aplikacja mogła odblokować właściwą rzecz i żebyś mógł później odpowiedzieć na pytanie „czy ta osoba zapłaciła?”.

Jeśli Twój kreator z AI da Ci przycisk Zapłać, który obciąża kartę, ale potem Twoja aplikacja nie robi niczego inaczej, to zbudował element 2, a zapomniał o elementach 3 i 4. To najczęściej spotykany na wpół zbudowany proces płatności i wygląda na działający aż do chwili, gdy klient zapłaci i nic nie dostanie.

Jak opisać to swojemu kreatorowi z AI

Oto prompt obejmujący powyższe elementy:

Dodaj płatny dostęp do tej aplikacji za pomocą Stripe Checkout. Jest jeden plan: 19 dolarów miesięcznie.

Gdy zalogowany użytkownik kliknie „Ulepsz”, przenieś go do hostowanej strony płatności Stripe. Nie buduj własnego formularza karty — moja aplikacja nigdy nie powinna obsługiwać numerów kart.

Po udanej płatności oznacz tego użytkownika jako „opłacony” w bazie danych i odblokuj mu stronę Raporty. Po nieudanej lub anulowanej płatności odeślij go na stronę z cennikiem z komunikatem.

Użyj webhooka Stripe, żeby potwierdzić płatność po stronie serwera, zanim cokolwiek odblokujesz — nie odblokowuj na podstawie samego trafienia użytkownika z powrotem na stronę sukcesu.

Ten ostatni akapit oddziela prawdziwy proces płatności od kruchego. Pozwolenie, by dostęp odblokowywała strona sukcesu, oznacza, że każdy, kto pozna adres tej strony, odblokuje go sobie za darmo. Webhook — bezpośredni, zweryfikowany komunikat od Stripe do backendu Twojej aplikacji — to wiarygodny sygnał. Twój kreator z AI wie, jak to skonfigurować; musisz tylko poprosić o to z nazwy.

Testuj fałszywymi pieniędzmi, zanim wejdą prawdziwe

Stripe (i większość dostawców) daje Ci tryb testowy z fałszywymi numerami kart, które zachowują się jak prawdziwe — w tym karty, które przechodzą, karty, które są odrzucane, i karty, które wywołują błędy. Korzystaj z tego. Zanim Twojej aplikacji dotknie choć jedna prawdziwa karta, przejdź przez każdą ścieżkę:

Udana płatność. Czy odblokowała się właściwa rzecz? Czy status użytkownika zmienił się na „opłacony”?
Odrzucona karta. Czy aplikacja obsłużyła to z gracją, czy zostawiła użytkownika utkniętego na zepsutym ekranie?
Anulowana płatność — użytkownik klika „wstecz” zamiast zapłacić. Czy wylądował w sensownym miejscu, wciąż bez ulepszenia?
Zapłata, a potem wylogowanie i ponowne zalogowanie. Czy wciąż jest „opłacony”? (To wyłapuje aplikacje, które odblokowują dostęp tylko dla bieżącej sesji i zapominają o nim do jutra.)

Poproś kreatora z AI o testowe numery kart albo sprawdź je w dokumentacji swojego dostawcy. Typową kartą testową dla „ta płatność się powiedzie” jest taka, którą kreator może Ci podać na żądanie. Przejdź przez wszystkie cztery scenariusze. Ścieżki z odrzuconą kartą i anulowaną płatnością to te, które kreatory z AI najczęściej zostawiają zepsute, bo szczęśliwą ścieżkę optymalizują najbardziej.

Błędy, które kosztują prawdziwe pieniądze

Kilka konkretnych trybów awarii pojawia się raz za razem przy pierwszych procesach płatności:

Odblokowywanie na stronie sukcesu zamiast na webhooku. Omówione wyżej, ale warte powtórzenia, bo to ten kosztowny. Jeśli Twoja aplikacja odblokowuje płatne funkcje w chwili, gdy użytkownik trafia na /success, ufasz przeglądarce użytkownika, że jest szczera co do tego, czy zapłacił. Nie zawsze jest. Odblokowuj na webhooku.

Brak zapisu, za co zapłacili. Jeśli Twoja aplikacja po prostu przerzuca globalną flagę „opłacony: tak”, będziesz mieć kłopot w chwili, gdy pojawi się więcej niż jeden plan, ktoś anuluje subskrypcję albo będziesz musiał wystawić zwrot. Zapisuj konkretną rzecz: który plan, kiedy i identyfikator tej płatności u dostawcy. Będzie Ci to potrzebne później, przy pytaniach do wsparcia.

Zapominanie, że subskrypcje się kończą. Płatność jednorazowa jest prosta: opłacone to opłacone. Cykliczna subskrypcja może wygasnąć — karta straci ważność, płatność w przyszłym miesiącu się nie powiedzie. Jeśli Twoja aplikacja nasłuchuje tylko „zapłacili”, a nigdy „ich subskrypcja się skończyła”, będziesz mieć ludzi zachowujących dostęp za darmo po tym, jak przestaną płacić. Powiedz kreatorowi, żeby obsłużył też komunikat „subskrypcja anulowana lub płatność nieudana”, nie tylko sukces.

Pobranie błędnej kwoty, bo cena mieszka w dwóch miejscach. Jeśli cena jest wpisana w ekran Twojej aplikacji i ustawiona u dostawcy płatności, w końcu się rozjadą, a klient zobaczy 19 dolarów, a zostanie obciążony 29. Trzymaj cenę w jednym miejscu — u dostawcy — a aplikacja niech wyświetla to, co mówi dostawca. Jedno źródło prawdy.

Krótka lista kontrolna, zanim wejdziesz na żywo

Zanim przełączysz się z trybu testowego na prawdziwe pieniądze:

Moja aplikacja nigdy nie ma pola, w które ktoś wpisuje surowy numer karty.
Płatność jest potwierdzana webhookiem od dostawcy, a nie tym, że użytkownik dotarł na stronę sukcesu.
Przetestowałem udaną płatność, odrzuconą kartę i anulowaną płatność — wszystkie trzy zachowują się sensownie.
Po zapłacie dostęp pozostaje odblokowany po wylogowaniu i następnego dnia.
Moja aplikacja zapisuje, za co każda osoba zapłaciła, a nie tylko to, że zapłaciła.
Jeśli subskrypcja wygaśnie, dostęp jest automatycznie odbierany.
Przełączyłem klucze dostawcy z trybu testowego na tryb live (łatwo o tym zapomnieć — Twój pierwszy prawdziwy klient trafiający na klucze testowe dostanie mylący błąd).

Jeśli każde pole jest odhaczone, jesteś gotów na prawdziwą kartę. Jeśli nie, to Twoja następna rozmowa z kreatorem z AI — zanim udostępnisz link, a nie po pierwszym sporze.

Nastawienie, które pomaga

Pieniądze to ta część Twojej aplikacji, gdzie „wygląda, że działa” i „naprawdę działa” są najdalej od siebie. Zepsuty układ widzisz natychmiast. Proces płatności, który odblokowuje dostęp bez weryfikacji płatności, wygląda idealnie — dopóki ktoś tego nie zauważy i nie powie znajomym.

Więc traktuj proces płatności jak tę jedną część aplikacji zbudowanej z AI, którą testujesz jak sceptyk. Spróbuj wejść bez płacenia. Spróbuj to zepsuć. Zapłać, a potem spróbuj stracić dostęp. Te 30 minut, które poświęcisz na próby oszukania własnej aplikacji, to najtańsze ubezpieczenie, jakie kiedykolwiek na nią wykupisz.

Masz zamiar dodać płatności do czegoś, co zbudowałeś? Otwórz następną sesję z kreatorem z AI, opisując cały proces — cenę, płatność, potwierdzenie webhookiem i to, co się odblokowuje — za jednym razem, zamiast prosić tylko o przycisk Zapłać. Przycisk Zapłać to łatwe 10%. Pozostałe 90% to to, co utrzymuje pieniądze w uczciwości.