Platby v aplikaci: Stripe, GoPay a předplatné bez zmatků v účtech

01Nejdříve popište produkt, platbu a distribuční kanál

U jednorázové objednávky řešíte cenu, měnu, dodání a případné vrácení peněz. U předplatného přibývá období, obnovení, změna tarifu, ukončení a chování při nezaplacení. Seznam těchto pravidel je důležitější než výběr barvy checkoutu.

• Co přesně zákazník kupuje a komu se služba zpřístupní?
• Kdy vzniká nárok na používání a kdy končí?
• Je částka pevná, podle počtu uživatelů, nebo podle spotřeby?
• Jak zákazník změní či zruší předplatné a opraví fakturační údaje?
• Který systém vede objednávky, doklady a skutečné oprávnění k přístupu?

U mobilní aplikace rozlišujte digitální funkce a obsah od fyzického zboží nebo služeb mimo aplikaci. Pravidla App Store i platební zásady Google Play stanovují požadavky a výjimky podle situace a regionu. Některé alternativy vyžadují splnění podmínek příslušného programu. Stripe ani GoPay tedy nelze automaticky vložit do každého mobilního nákupu. Před volbou architektury ověřte konkrétní způsob distribuce.

02Stripe a GoPay porovnávejte podle celého provozu

Nerozhodujte pouze podle jedné transakční sazby. Sečtěte očekávaný platební provoz, potřebné doplňkové funkce, implementaci, průběžnou správu, účetní práci i řešení reklamací. Nabídku posuzujte pro vlastní měny, trhy a typy plateb. Ceníky a dostupnost funkcí se mění.

Stripe má dokumentované události a životní cyklus předplatného prostřednictvím Billing. GoPay nabízí opakované platby včetně pravidelného strhávání i plateb podle čerpání služby. To samo neurčuje, kde budete spravovat tarify, oprávnění nebo české účetní doklady. Dostupnost opakování pro konkrétní účet a integrační variantu si potvrďte před vývojem.

GoPay dnes publikuje Payments API v4. Nepřenášejte automaticky staré endpointy nebo parametry opakování do nové implementace. U existujícího řešení určete používanou verzi, rozsah případné migrace a potřebné regresní testy. Stejně tak u Stripe zapište verzi API a používané knihovny.

03Zaplaceno musí potvrdit server

Objednávku založte s vlastním identifikátorem, částkou a měnou vypočtenými z důvěryhodných údajů. Server propojí objednávku s platebním záznamem poskytovatele. Hodnota poslaná z formuláře nesmí sama rozhodovat o tom, kolik služba stojí nebo komu patří.

Stripe u Checkout výslovně upozorňuje, že při dodání nelze spoléhat jen na návratovou stránku. Zákazník může zaplatit a ztratit spojení dříve, než se stránka načte. Backend proto zpracuje platební událost a ověří stav. Návratovou stránku použijte k zobrazení skutečného výsledku nebo informace, že potvrzení ještě probíhá.

Hosted integrace GoPay API v4 také odděluje návrat zákazníka od notifikace. Server po notifikaci znovu načte platbu přes API a zjistí její stav. Konkrétní ověření a formát zpráv se řídí dokumentací dané integrace, ne univerzálním webhookovým kódem pro všechny brány.

Před aktivací porovnejte správnou objednávku, účet, očekávanou částku, měnu a výsledný stav. Platba, předplatné a oprávnění jsou samostatné záznamy. Změny musí být dohledatelné i tehdy, když následný účetní export selže. Praktické souvislosti popisuje propojení systémů přes API.

04Opakování nesmí vytvořit druhou službu ani druhé stržení

Dokumentace Stripe webhooků upozorňuje na opakovaná doručení a na to, že pořadí událostí není garantované. Ověřuje se také podpis přijaté zprávy. Tým proto musí určit, jak pozná již zpracovanou událost a jak získá potřebný aktuální stav, když související oznámení přijde později.

Vedle doručení zpráv hlídejte samotné obchodní operace. Dvojí kliknutí, obnovení stránky nebo souběžná práce dvou serverů nesmí bez kontroly vytvořit dvě objednávky předplatného. Výsledek uchovávejte u stabilního identifikátoru a návrh otestujte také při současném zpracování.

Idempotentní požadavky Stripe umožňují bezpečně opakovat podporovaný požadavek se stejným klíčem, místo vytvoření druhého objektu. Klíč patří k dané operaci; nemá být náhodně nový při každém pokusu o její zopakování. Tento mechanismus nenahrazuje ochranu vlastních změn v databázi, e-mailů nebo účetního exportu.

Pokud server neví, zda první požadavek uspěl, nejdříve postupuje podle identifikátorů a pravidel poskytovatele. Slepé založení další platby je špatná obnova. Zároveň rozlišujte opakování technického požadavku od nového pokusu zákazníka zaplatit po skutečném zamítnutí.

05Předplatné má vlastní stav a obchodní pravidla

Pro předplatné si vytvořte přehled přechodů: čeká na první platbu, aktivní, vyžaduje zásah zákazníka, čeká na nápravu nezaplacení, ukončené. Jejich názvy a význam slaďte s poskytovatelem. Interní stav nesmí skrývat důležitou odlišnost jen proto, že všechno pojmenujete „aktivní“.

Stripe doporučuje u obnovy přístupu po události invoice.paid načíst související předplatné a ověřit jeho stav active. Samotné zaplacení jedné faktury nemusí vždy změnit stav předplatného, záleží na konfiguraci řešení nezaplacených dokladů. Nepoužívejte proto jednu zprávu jako univerzální zkratku pro všechny tarify a situace.

U vlastní logiky nad opakovanými platbami GoPay musíte určit, jak platba prodlužuje období a co udělá změna částky nebo termínu. Tyto operace patří do obchodního návrhu i do uživatelského rozhraní. Vývojáři nemají odhadovat, zda se při změně tarifu služba účtuje hned, poměrně, nebo až v příštím období.

• Ukončení odlište na okamžité a ke konci zaplaceného období, pokud je produkt nabízí.
• Po neúspěšné obnově určete upozornění, případnou lhůtu k nápravě a stav přístupu.
• Změnu tarifu ukažte zákazníkovi včetně účinnosti a dopadu na cenu.
• U zkušební doby vysvětlete, zda a kdy začne placené období.

Automatické opakování platby nepovažujte za souhlas s libovolnou další cenou. Zákazník musí rozumět schválenému režimu a mít dohledatelný způsob správy. Provozní podpora potřebuje stejná pravidla jako aplikace.

06Fakturu, úhradu a výplatu peněz nepomíchejte

Faktura může vzniknout dříve než její úhrada. U předplatného Stripe rozlišuje vytvoření, finalizaci a zaplacení invoice. Účetní návaznost proto nemá být slepý příkaz „po platbě vystavit fakturu“. Určete, který systém doklad vytváří a který pouze aktualizuje stav nebo páruje úhradu.

Pro českou firmu domluvte s účetní konkrétní podobu dokladů, číselné řady, potřebné údaje a postup oprav. PDF od platebního poskytovatele neposuzujte automaticky jako hotové řešení všech účetních a daňových povinností. Integrace se má řídit dohodnutým účetním procesem, ne vzhledem ukázkového souboru.

Oddělte také platbu zákazníka od převodu peněz poskytovatelem na váš bankovní účet. Při párování potřebujete dohledat vazbu mezi objednávkou, transakcí, dokladem a výplatou. Poplatky, refundace a další pohyby musí být vysvětlitelné, aby rozdíl mezi částkou objednávek a bankovním převodem nezůstal záhadou.

Určete, který systém spravuje příslušné číselné řady a kdo zodpovídá za opravy. Pokud účetní systém přijme export až na druhý pokus, nesmí se založit nový doklad se stejným obchodním významem. Chybný export dejte do dohledatelné fronty s odpovědným člověkem.

07Neúspěšné platby a refundace jsou běžný provoz

U platby vyžadující zásah zákazníka nabídněte srozumitelný další krok. Neoznačujte ji za zaplacenou jen proto, že byl vytvořen platební záznam. U odmítnuté obnovy vysvětlete, zda může zákazník aktualizovat platební prostředek a jaké období má dosud uhrazené.

Refundaci navrhněte jako samostatný proces: kdo ji smí schválit, zda je plná či částečná, jak se projeví v dokladech a zda mění přístup ke službě. Vrácení peněz samo nemusí znamenat zrušení všech budoucích plateb. Stejně tak ukončení předplatného automaticky neřeší minulou úhradu.

Podpora má vidět identifikátory objednávky, platby a předplatného, relevantní stav a historii změn. Čísla karet ani tajné přístupové klíče do těchto záznamů nepatří. Opravy provádějte řízeně s auditní stopou, místo ručních zásahů do několika systémů bez společného záznamu.

Chraňte serverové klíče, omezte oprávnění a oddělte testovací prostředí od produkce. U platebního formuláře zvolte podporovanou integraci poskytovatele. Bezpečnostní přejímku spojte s dalšími kontrolami podle přehledu před spuštěním aplikace.

08Co otestovat a sledovat po spuštění

Testovací prostředí použijte pro celý tok, nikoli pouze pro zobrazení brány. Přejímací scénáře mají mít očekávaný stav objednávky, přístupu a účetní návaznosti. Některé reálné vlastnosti zúčtování nebo nastavení účtu pak ověřte kontrolovaně při přechodu do provozu.

1. Úspěšná platba s návratem zákazníka i bez návštěvy návratové stránky.
2. Odmítnutí, nedokončené ověření a zpožděné potvrzení platby.
3. Opakovaná, souběžná nebo neplatná notifikace bez dvojího plnění.
4. Výpadek aplikace po přijetí události a následná bezpečná obnova.
5. První platba předplatného, obnovení, změna tarifu a ukončení.
6. Refundace a správná aktualizace či párování příslušných dokladů.
7. Účetní export, který selže a uspěje při dalším pokusu.

Po spuštění sledujte neověřené platby, selhání notifikací, čekající exporty a rozdíly při párování. Každá fronta potřebuje vlastníka a postup řešení. Připravená integrace vám umožní dohledat, proč zákazník zaplatil a co aplikace následně provedla.

09Časté otázky k platbám a předplatnému