Cześć — widziałem twoją wiadomość dziś rano, screen z wiadomością „jak mogę ci za to zapłacić" w skrzynce wsparcia twojej aplikacji. Szczerze gratuluję. To moment, w którym projekt poboczny przestaje być demem. To także moment, w którym setka drobnych decyzji, które dotąd odkładałeś, ląduje na twoim biurku tego samego wtorku. Prosiłeś, żebym po prostu powiedział ci, co robić. Zrobię to, ale najpierw chcę przeprowadzić cię przez „dlaczego", bo to „dlaczego" sprawi, że nie będziesz musiał mnie o to pytać ponownie za trzy miesiące, gdy zamiast Stripe będzie Lemon Squeezy albo zamiast płatności jednorazowej — subskrypcja.
Decyzja, którą naprawdę podejmujesz
Nazwałeś to pytaniem „którego dostawcę płatności wybrać", ale to w rzeczywistości dwie decyzje jedna na drugiej. Po pierwsze: chcesz być sprzedawcą zapisanym formalnie (merchant of record), czy chcesz, żeby był nim ktoś inny? Po drugie: jaki jest kształt twojego rozliczenia — zakup jednorazowy, subskrypcja czy rozliczenie za użycie? Pomyl się w pierwszej i za sześć miesięcy spędzisz weekend na rejestracji do VAT w kraju, którego nigdy nie odwiedziłeś. Pomyl się w drugiej i czeka cię irytująca migracja, nie problem prawny — więc jest to mniej straszne z tych dwóch.
Bycie sprzedawcą zapisanym formalnie (merchant of record) oznacza, że to ty prawnie sprzedajesz produkt. Zbierasz pieniądze, odpowiadasz za rozpoznanie podatku od sprzedaży i VAT w każdej jurysdykcji, w której mieszkają twoi klienci, i sam się z tego rozliczasz. Stripe chętnie naliczy za ciebie ten podatek (Stripe Tax), ale naliczenie to nie odprowadzenie — nadal musisz zarejestrować się i złożyć deklarację wszędzie tam, gdzie przekroczysz próg. Usługa typu merchant of record, jak Lemon Squeezy czy Paddle, zdejmuje ten cały problem z twojego biurka: to one są prawnie sprzedawcą, zbierają i odprowadzają podatek wszędzie, a tobie wypłacają kwotę netto. W zamian oddajesz część marży.
| Opcja | Kto jest sprzedawcą | Typowa prowizja | Obsługa podatków | Najlepsze do |
|---|---|---|---|---|
| Stripe (bezpośrednio) | Ty | ~2,9% + 0,30 USD/transakcję, +0,5% za Stripe Tax | Ty rejestrujesz się i rozliczasz, Stripe tylko nalicza | Spodziewasz się skalowania powyżej kilku tysięcy miesięcznie i chcesz niższych opłat w dłuższej perspektywie |
| Lemon Squeezy | Lemon Squeezy | ~5% + 0,50 USD/transakcję | W pełni obsłużone, oni są formalnym sprzedawcą | Samodzielny twórca, pierwszy produkt, nie chcesz w ogóle zajmować się podatkami |
| Paddle | Paddle | ~5% + opłaty zależne od regionu | W pełni obsłużone, bardziej nastawione na klientów enterprise | SaaS z subskrypcjami i pewnymi potrzebami fakturowania |
| PayPal | Ty | ~3,5–4,5%, reklamacje przyjazne kupującemu | Ty się tym zajmujesz | Klienci, którzy konkretnie ufają PayPal, nie domyślny wybór |
Na twoim obecnym etapie — jeden klient, prosty produkt, jeszcze nie wiadomo, czy to się przerodzi w biznes — polecam raczej Lemon Squeezy lub Paddle niż surowe Stripe. Dodatkowe dwa punkty procentowe opłaty to tania polisa ubezpieczeniowa przed przypadkowym zostaniem podatnikiem w stanie, w którym nigdy nie postawiłeś stopy. Możesz później przejść bezpośrednio na Stripe, gdy wolumen uzasadni zmianę i będziesz gotów na papierkową robotę. Nikt nie migruje dostawców płatności dla przyjemności, ale to problem do rozwiązania w jeden wtorek, nie w cały rok.
Sam popełniłem ten błąd przy wcześniejszym projekcie — poszedłem prosto w Stripe, bo „wszyscy używają Stripe", zbierałem kilkaset dolarów miesięcznie od garstki europejskich klientów, a osiemnaście miesięcy później dostałem bardzo uprzejmy, ale bardzo mylący e-mail o rejestracji VAT MOSS. Kosztowało mnie to popołudnie z księgowym i czterdzieści minut czystej paniki w Google'u pod hasłem „czy jestem winien pieniądze Holandii". Nie katastrofa. Ale w pełni do uniknięcia.
Zanim dotkniesz kluczy produkcyjnych
Cokolwiek wybierzesz, nie podłączaj tego najpierw w trybie produkcyjnym. Każdy z tych dostawców ma tryb testowy/sandbox z fałszywymi numerami kart, które wywołują konkretne wyniki — udaną płatność, odrzuconą kartę, wymóg 3D Secure, brak środków. Przejdź przez wszystkie te scenariusze, zanim dotkniesz prawdziwego klucza. Ścieżki błędów to te, na które faktycznie trafisz w pierwszym tygodniu, a debugowanie ich na żywo, z kartą prawdziwej osoby podpiętą do systemu, jest o wiele mniej przyjemne.
W czacie budującym aplikację wyraźnie zaznacz, że chcesz to podzielić na etapy: poproś, żeby integracja była najpierw podłączona do trybu testowego, z wyraźnie widocznym banerem lub flagą, żeby nikt — włącznie z tobą w przyszłości — przypadkowo nie obciążył prawdziwej karty podczas testów. Potem zrób osobny, świadomy krok, w którym podmienisz klucze na produkcyjne. Dwa polecenia, nie jedno, nawet jeśli szybciej byłoby po prostu powiedzieć „dodaj płatności" i pozwolić, żeby zgadło, o który tryb chodzi. Ta niewygoda jest celowa.
Musisz też zdecydować, co się dzieje, gdy webhook się uruchamia, a twój serwer jest wyłączony, wolny albo zdarzenie dociera dwukrotnie. To nie jest hipoteza — dzieje się to niezawodnie w pierwszym tygodniu. Zdarzenia, które musisz obsłużyć, co najmniej:
checkout.session.completed(lub odpowiednik) — przyznaj dostęp, to jest moment, w którym klient staje się klienteminvoice.payment_failed— w przypadku subskrypcji zdecyduj teraz, czy to natychmiastowa blokada, czy okres karencji, bo „natychmiastowa blokada" to naprawdę złe pierwsze wrażenie w przypadku karty, która miała chwilowy problemcustomer.subscription.deleted— ktoś anulował subskrypcję, cofnij dostęp na koniec okresu, nie od razu, chyba że regulamin stanowi inaczej- Zdarzenie zwrotu — zdecyduj raz, pisemnie wobec samego siebie, jaka jest naprawdę twoja polityka zwrotów, zanim pierwsza prośba o zwrot zmusi cię do decyzji na żywo
Idempotencja ma tutaj większe znaczenie niż niemal wszędzie indziej w twojej aplikacji. Jeśli webhook dotrze dwukrotnie — a dotrze, dostawcy ponawiają próby przy każdej odpowiedzi innej niż 200 — nie możesz przyznać dostępu dwukrotnie ani, co gorsza, podwójnie obciążyć stanu wewnętrznego. Zapisuj identyfikator zdarzenia i sprawdzaj, czy nie zostało już przetworzone, zanim na nie zareagujesz.
Pytanie o cenę, którego unikasz
Wspomniałeś w wiadomości, że nie jesteś pewien, czy pobierać 9 USD miesięcznie, czy jednorazowo 49 USD. Myślę, że żadna z tych opcji nie jest błędna, ale zauważ, czemu naprawdę unikasz: rozmowie z klientem o tym, jaka jest wartość cykliczna. Cena jednorazowa jest łatwiejsza do zaakceptowania i łatwiejsza dla ciebie do zbudowania (bez windykacji, bez obsługi nieudanych odnowień, bez procesu anulowania). Subskrypcja to zakład, że będziesz na tyle poprawiał produkt, żeby ludzie nie rezygnowali — to prawdziwe zobowiązanie, nie tylko checkbox na stronie z cennikiem. Jeśli nie jesteś pewien, czy za sześć miesięcy nadal będziesz aktywnie nad tym pracować, cena jednorazowa jest uczciwszą ofertą. Zawsze możesz później dodać poziom subskrypcyjny, gdy pojawi się coś ciągłego, na co warto się zapisać.
Jeszcze jedno, a potem wracaj do pracy: umieść na stronie prawdziwą politykę zwrotów i anulowania, zanim przyjmiesz pierwszego dolara, nawet jeśli to tylko trzy zdania. Nie dlatego, że ktoś cię pozwie za obciążenie 9 USD, ale dlatego, że napisanie tego zmusza cię do faktycznego podjęcia decyzji, a „wymyślę to, jak ktoś zapyta" to sposób na podjęcie decyzji o polityce w środku wściekłego e-maila, zamiast spokojnego popołudnia.
Idź podłącz najpierw sandbox. Napisz do mnie, jak przepuścisz przez niego fałszywą odrzuconą kartę — to wersja „działa", która naprawdę się liczy.
