Jak działają płatności i subskrypcje w aplikacji dla firmy — od środka?

Warstwy płatności — co robi operator, a co aplikacja?

Płatności w aplikacji dla firmy to nie jeden przycisk, tylko osiem osobnych elementów. Operator płatności prowadzi sześć z nich: stronę płatności, cykl subskrypcji, ponowienia nieudanych obciążeń, faktury, portal klienta i wypłaty. Po stronie aplikacji zostają dwa: odbiór powiadomień o zdarzeniach i decyzja o dostępie.

Podział jest sztywny z jednego powodu. Pieniądze i dostęp rozstrzygają się w różnych miejscach i w różnym czasie. Operator wie, czy bank obciążył kartę; aplikacja wie, komu ma pokazać panel. Między nimi jest jedna droga — powiadomienie o zdarzeniu — i to ona decyduje, kiedy dostęp się otwiera.

Decyzja: cykl prowadzi operator, aplikacja tylko czyta stan

W aplikacjach, które budujemy, obowiązuje zasada bez wyjątków: powiadomienie od operatora płatności jest jedynym źródłem prawdy o wpłacie. Front nigdy nie zalicza płatności sam, a przekierowanie po zapłacie służy wyłącznie temu, żeby pokazać użytkownikowi ekran.

Gdzie ta zasada siedzi w architekturze, rozkłada na warstwy artykuł o tym, z jakich warstw składa się aplikacja dla firmy.

Powód jest prozaiczny. Użytkownik zamyka kartę przeglądarki, traci zasięg albo wraca z płatności, zanim bank potwierdzi obciążenie. Przekierowanie mówi tylko tyle, że ktoś kliknął powrót; powiadomienie mówi, że pieniądze są.

Druga decyzja dotyczy tego, kto jest sprzedawcą. Przy aplikacjach budowanych dla firm sprzedawcą jest ta firma, nie wykonawca — dlatego stawiamy Stripe Connect, w którym każdy taki podmiot ma własne konto operatora, własne wypłaty i własną nazwę na wyciągu płatnika.

Cena tej decyzji jest jawna: 9 zł miesięcznie za aktywne konto oraz 0,25% + 1,35 zł od każdej wysłanej wypłaty (cennik Connect dla Polski, odczyt 31 sierpnia 2026).

Alternatywa — jedno konto operatora po stronie wykonawcy i ręczne przelewanie pieniędzy dalej — jest tańsza w cenniku i droższa we wszystkim innym. Pieniądze przechodzą wtedy przez cudze konto, a zwroty i spory obsługuje ktoś, kto nie jest stroną transakcji. Który operator ma sens w pierwszej wersji, porównuje zestawienie płatności w MVP.

Ten układ nie jest teorią z diagramu: tak zbudowanych jest kilkanaście aplikacji i serwisów, które utrzymujemy na tym samym stosie (stan: sierpień 2026).

Zasada „dostęp otwiera powiadomienie, nie przekierowanie” nie wymaga dodatkowej warstwy — to jedna decyzja o tym, skąd aplikacja czyta stan — a jej brak wychodzi zwykle przy pierwszej płatności, która utknęła w banku.

Cykl życia subskrypcji — co aplikacja robi w każdym stanie

Subskrypcja nie ma dwóch stanów, „płaci” i „nie płaci”, tylko osiem. Stripe nazywa je wprost i zmienia sam, a aplikacja ma na każdy z nich jedną odpowiedź: pokazać panel, pokazać przypomnienie albo odciąć dostęp. Nazwy i przejścia są w dokumentacji (odczyt 31 sierpnia 2026).

Najczęściej pomijany jest stan pierwszy. Po utworzeniu subskrypcji z natychmiastową płatnością klient ma 23 godziny na opłacenie pierwszej faktury i przez ten czas subskrypcja stoi w stanie incomplete. Po tym oknie przechodzi w incomplete_expired, faktura zostaje unieważniona, a do kolejnej próby potrzebna jest nowa subskrypcja.

Drugi stan wart uwagi to past_due: ostatnia faktura nie została opłacona, ale subskrypcja żyje i operator ponawia obciążenie. To ustawienie w panelu operatora, nie kod aplikacji, rozstrzyga, co dzieje się po ostatniej próbie — anulowanie, przejście w unpaid albo pozostawienie w past_due.

Ponowienia prowadzi operator. Smart Retries powtarza obciążenie w oknie tygodnia, dwóch, trzech, miesiąca albo dwóch miesięcy, a zalecane ustawienie domyślne to 8 prób w ciągu 2 tygodni (dokumentacja, odczyt 31 sierpnia 2026). Własny harmonogram pozwala ustawić najwyżej trzy ponowienia.

Części odmów nie da się ponowić w ogóle. Przy twardych kodach odmowy, takich jak karta zgubiona albo skradziona, próby są planowane, ale wykonają się dopiero po dodaniu nowej metody płatności.

Aplikacja nie liczy tych prób i nie odtwarza harmonogramu u siebie. Odbiera zdarzenie o nieudanej płatności, zapisuje stan i rozstrzyga o dostępie. Jak zbudować odbiór powiadomień, żeby nie gubił zdarzeń, opisują kroki budowy, a jak nie przyjąć cudzego zdarzenia — zasady bezpieczeństwa od pierwszego dnia.

Portal klienta — czego nie trzeba budować

Zmiana karty, zmiana planu, pobranie faktury i rezygnacja to cztery ekrany, których nie trzeba pisać. Stripe hostuje portal klienta pod własnym adresem, klient loguje się do niego adresem e-mail, a link do logowania dostaje pocztą. Portal jest wliczony w cennik Billing i nie ma osobnej opłaty (cennik i dokumentacja, odczyt 31 sierpnia 2026).

Dwa ograniczenia trzeba znać, zanim ktoś obieca zamawiającemu „pełny panel rozliczeń”. Adresu e-mail klient w portalu nie zmieni — to celowa blokada. A gdy pod jednym adresem jest kilku klientów, operator wybiera najnowszego z aktywną subskrypcją, co przy firmach z jedną skrzynką na dział bywa zaskoczeniem.

Co zmienia skala: 10, 1 000 i 10 000 płacących?

Przy dziesięciu płacących nie zmienia nic. Opłata za prowadzenie subskrypcji jest ułamkiem obrotu, a portal klienta i ponowienia są włączone od pierwszego dnia. Praca po stronie aplikacji jest ta sama przy dziesięciu i przy dziesięciu tysiącach kont: odebrać zdarzenie, zapisać stan, otworzyć albo zamknąć dostęp.

Przy tysiącu płacących zmienia się to, czego przy dziesięciu nie widać: odsetek nieudanych obciążeń. Odmowa banku przestaje być pojedynczą sprawą dla obsługi, a staje się procesem, który przez dwa tygodnie chodzi w tle. Wtedy zaczyna mieć znaczenie, czy dostęp odcina się po pierwszej odmowie, czy po ostatniej próbie ponowienia.

Przy dziesięciu tysiącach zaczyna się rachunek. Stripe Billing kosztuje 0,7% kwoty odnawialnej, a plan opłacany miesięcznie zaczyna się od 2 500 zł miesięcznie przy rocznej umowie, obejmuje obrót do 400 000 zł i liczy 0,67% od nadwyżki (cennik dla Polski, odczyt 31 sierpnia 2026). Próg opłacalności wychodzi z własnego obrotu, nie z cennika.

Osobno rośnie Connect, bo jego opłata jest za konto, nie za obrót. Przy stu aktywnych kontach sprzedawców to — w naszym przeliczeniu z cennika — 900 zł miesięcznie z samych kont, do tego 0,25% + 1,35 zł od każdej wysłanej wypłaty i 0,25% od kwoty wypłat (cennik, odczyt 31 sierpnia 2026).

Tę liczbę trzeba policzyć przed wyborem architektury z wieloma sprzedawcami, a nie po pierwszym rachunku.

Po czym poznać, że płatności są zrobione dobrze?

Sześć pytań, które właściciel firmy może zadać bez znajomości kodu. Odpowiedź „sprawdzimy” na którekolwiek z nich znaczy, że płatności nie są gotowe do przyjmowania pieniędzy.

• Czy dostęp otwiera się z powiadomienia operatora, czy z powrotu użytkownika na stronę po zapłacie?
• Co robi aplikacja w stanie zaległości: odcina dostęp po pierwszej odmowie banku czy po ostatniej próbie ponowienia?
• Czy klient sam zmieni kartę i pobierze fakturę, czy każda taka prośba idzie do obsługi?
• Czy po rezygnacji dostęp trwa do końca opłaconego okresu i czy aplikacja wie o tym ze stanu u operatora?
• Czy w trybie testowym operatora przećwiczono odrzuconą i wygasłą kartę, a nie tylko udaną płatność?
• Kto jest sprzedawcą na fakturze i na wyciągu płatnika — firma, która sprzedaje, czy ta, która zbudowała aplikację?

Ostatnie pytanie jest najdroższe do naprawienia po starcie. Zmiana sprzedawcy oznacza nowe konto operatora, nowe umowy z płatnikami i ponowne zebranie zgód na obciążenia cykliczne. Dane kart zostają u operatora, więc nie da się ich przenieść jak pliku.