Platby v aplikácii: Stripe, GoPay a predplatné, ktoré funguje aj pri neúspešnej úhrade
Zákazník zaplatí, zavrie okno a prístup sa neaktivuje. Inému sa po obnovení stránky predplatné predĺži dvakrát. Úspešná skúšobná platba ešte nepotvrdzuje správnu integráciu. Aplikácia potrebuje zvládnuť oneskorenie, opakovanie aj neúspech.
Stripe alebo GoPay môžu spracovať platbu, ale firma stále rozhoduje, čo sa má stať v jej aplikácii. Objednávka, úhrada, oprávnenie a účtovný záznam sú prepojené, no majú vlastné stavy. Integrácia má tieto rozdiely zachovať a vedieť ich vysvetliť podpore aj zákazníkovi.
Pre slovenskú firmu môžu byť relevantné jednorazové platby v eurách, mesačné predplatné aj služby pre zahraničné trhy. Výber brány začína obchodným modelom a prevádzkou. Poplatky a dostupné metódy overujte pre konkrétny účet, trh a dohodnuté podmienky, nie podľa starého porovnávacieho článku.
01Vyberajte podľa platobného modelu, nie iba loga brány
Najprv určte, čo predávate, kto platí a kedy vzniká nárok na službu. Jednorazové odomknutie funkcie je iné než predplatné s pravidelným účtovaním. Význam má aj zmena tarify, skúšobné obdobie, pozastavenie a prístup po zrušení.
| Potreba aplikácie | Čo preveriť u poskytovateľa | Čo vlastní firma |
|---|---|---|
| Jednorazová úhrada | Metódy, checkout a konečné stavy | Objednávku a pravidlo aktivácie služby |
| Pravidelné predplatné | Podporu a aktiváciu opakovaných platieb | Tarify, obdobia a prístup pri neúspechu |
| Zmena tarify | Možnosti účtovania zmeny | Kedy sa mení nárok a ako sa zmena vysvetlí |
| Doklady a účtovníctvo | Dostupné záznamy a exporty | Väzby dokladov a účtovný proces |
| Viac trhov alebo mien | Dostupnosť a zmluvné podmienky | Ceny, lokálnu ponuku a prevádzku |
| Podpora a reklamácie | Dohľadanie platby a dostupné operácie | Oprávnenia podpory a audit zmien |
Pri GoPay overte konkrétnu integračnú verziu. Slovenská dokumentácia novej brány upozorňuje, že API v4 sa líši od predchádzajúcej verzie a prechod vyžaduje úpravu implementácie. Starší doplnok alebo návod nemusí opisovať aktuálny tok.
Pri cenovom porovnaní zahrňte transakčné a ďalšie zmluvné náklady, správu integrácie aj spracovanie problémov. Najnižšia položka v cenníku nemusí predstavovať najnižší náklad celej služby. Firma potrebuje vedieť, kto dokáže platbu dohľadať a opraviť nadväzujúci stav.
02Návrat prehliadača nie je dôkazom úhrady
Po platbe sa zákazník môže vrátiť na potvrdenie, zavrieť okno alebo stratiť spojenie. Táto návšteva nemá byť jediným spúšťačom aktivácie. Stripe pri plnení objednávok výslovne vyžaduje serverové spracovanie cez webhooks, pretože návrat na cieľovú stránku nie je zaručený.
Prehliadač môže po návrate zobraziť stav získaný zo servera. Samotný parameter v adrese alebo obrazovka „úspech“ nesmú rozhodovať o zaplatení. Server musí overiť príslušnú platbu, jej väzbu na objednávku, sumu a menu podľa integračného návrhu.
Niektoré metódy majú oneskorený výsledok. Dokončenie checkoutu preto nemusí vždy znamenať konečnú úspešnú úhradu. Používateľ potrebuje zrozumiteľný stav čakania a aplikácia musí pokračovať aj po tom, čo už zákazník nie je na stránke.
Modelová situácia: zákazník zaplatí predplatné, no prehliadač sa nevráti do aplikácie. Overená serverová cesta má platbu spracovať a následne umožniť správny prístup. Pri ďalšom otvorení zákazník uvidí aktuálny stav. Nemá byť nútený platiť druhýkrát iba preto, že neotvoril potvrdenie.
03Oznámenia overujte podľa konkrétneho poskytovateľa
Stripe dokumentuje overenie podpisu webhooku a upozorňuje na opakované doručenie aj nezaručené poradie udalostí. Aplikácia preto potrebuje kontrolu pôvodu a spracovanie, ktoré nevykoná tú istú obchodnú zmenu opakovane.
Nápoveda GoPay odlišuje doručenie oznámenia od samotného stavu platby a opisuje jeho zistenie dotazom. Presný postup použite podľa zvolenej verzie a dokumentácie. Podpis Stripe nemožno preniesť ako univerzálny mechanizmus GoPay.
Ukladajte identifikátory potrebné na väzbu objednávky, platby a spracovania. Potvrdenie prijatia správy má zodpovedať jej bezpečnému prijatiu do zvoleného procesu. Následná chyba aktualizácie aplikácie potrebuje dohľadateľný stav a možnosť opravy.
Praktické pravidlo pre duplicity: opätovné doručenie tej istej udalosti nemá druhýkrát predĺžiť obdobie, odoslať tovar alebo pripísať kredit. Súbežné požiadavky tiež nesmú obísť kontrolu. Ochranu navrhnite na úrovni konkrétnej obchodnej zmeny, nie iba vizuálnym vypnutím tlačidla.
Pri staršej udalosti overte, či nevracia stav späť. Udalosť čakajúcej platby, ktorá príde neskôr než potvrdenie úhrady, nemá bez kontroly odobrať už platný prístup. Potrebujete pravidlá prechodu stavov a podľa potreby získanie aktuálnych údajov od poskytovateľa.
04Predplatné potrebuje pravidlá celého obdobia
Dohodnite začiatok obdobia, obnovu, zmenu tarify a zrušenie. Zrušenie ďalšieho obnovenia a okamžité ukončenie služby sú odlišné možnosti. Používateľ musí vedieť, ktorá platí a dokedy má prístup.
Stripe pri predplatnom rozlišuje stav predplatného, faktúry a konkrétnej platby. Niektoré spôsoby fakturácie môžu mať aktívne predplatné aj s neuhradenou faktúrou. Samotný stav active preto neprezentujte ako univerzálny dôkaz úhrady každej pohľadávky.
GoPay opisuje opakované platby ako automatické alebo vyvolané obchodníkom. Uvedené možnosti a aktiváciu treba potvrdiť pre konkrétny účet a integračnú verziu. Súhlas zákazníka s nastavením úhrad musí zodpovedať skutočnému obchodnému procesu.
Zmena tarify potrebuje jasné rozhodnutie: okamžitá alebo od ďalšieho obdobia, s akým účtovaním a akými oprávneniami. Pri skúške zahrňte prechod na vyššiu aj nižšiu tarifu. Používateľ nemá dostať funkcie vyššej tarify iba preto, že klikol na jej názov.
Pri obnove určte, ktorá udalosť obnoví nárok a kedy ho treba prehodnotiť. Prístup k aplikácii nemusí presne kopírovať každú technickú zmenu u poskytovateľa. Musí však vychádzať z dohodnutých a konzistentných pravidiel služby.
Pri obdobiach stanovte aj časové pravidlá a zobrazenie zákazníkovi. Mesačné predplatné nezaokrúhľujte svojvoľne na rovnaký počet dní. Skontrolujte koniec mesiaca, prechod roka a okamih účinnosti zrušenia. Server, poskytovateľ a používateľský prehľad musia pracovať s dohodnutými údajmi. Pri rozdiele má podpora vedieť vysvetliť, ktoré obdobie bolo uhradené a odkedy sa mení nárok.
05Neúspešná úhrada nesmie zostať bez rozhodnutia
Karta môže byť neplatná, platba zamietnutá alebo môže vyžadovať ďalšiu akciu zákazníka. Pri predplatnom sa tento problém môže objaviť aj po mesiacoch úspešnej prevádzky. Prvá ukážková platba preto neoverí obnovovanie služby.
Určte komunikáciu, opakovanie a prípadnú lehotu na vyriešenie problému. Používateľ má vedieť, ako zmeniť platobný prostriedok a čo sa stane s prístupom. Pravidlá nesmú vzniknúť až pri prvom rozčúlenom zákazníkovi.
Rozlíšte úspešnú úhradu, vrátenie a spor. Platba, ktorú zákazník spochybnil alebo ktorá bola vrátená, potrebuje vlastný postup. Podpora má vedieť dohľadať objednávku, úhradu a prístup bez ručného zásahu priamo do databázy.
Pri oneskorenom výsledku neoznačujte platbu za definitívne neúspešnú iba preto, že zákazník odišiel. Opätovný pokus spojte s aktuálnym stavom objednávky. Zabránite tomu, aby si používateľ omylom vytvoril viac paralelných platieb za tú istú potrebu.
06Doklad a párovanie riešte ako samostatný proces
Stripe pri faktúrach predplatného opisuje vznik faktúry aj pred úhradou. Preto schéma nemá tvrdiť, že každý doklad sa vytvorí až po zaplatení. Integrácia môže po potvrdení platby aktualizovať alebo spárovať už existujúci záznam.
Určte, ktorý systém vlastní číslovanie, zákaznícke údaje a účtovný doklad. Záznam platobnej brány a firemný účtovný proces nemusia byť totožné. Účtovanie, daňové údaje a potrebné náležitosti dohodnite podľa skutočného predaja a používaného systému.
Pri párovaní sledujte identitu objednávky, platby a dokladu, sumu, menu, poplatky, vrátenia a vyúčtovanie. Úspešná zákaznícka platba nemusí znamenať rovnakú sumu ako čistá platba prijatá na bankový účet. Kontrola potrebuje vysvetliť rozdiel.
Ak účtovný systém pri aktualizácii zlyhá, stav úhrady sa nemá stratiť. Uložte nevykonanú nadväzujúcu úlohu a pripravte jej bezpečné opakovanie. Jedna zaplatená objednávka nemá vytvoriť dva doklady iba preto, že integrácia skúšala operáciu znovu.
07Pri mobilnej aplikácii preverujte pravidlá distribúcie
Webový checkout nemožno bez posúdenia preniesť do mobilnej aplikácie. Apple App Review Guidelines a Google Play Payments policy rozlišujú typ predávaného obsahu, služby a podmienky alternatívnych platieb.
Digitálna funkcia v aplikácii a nákup fyzického tovaru nie sú rovnaký scenár. Pravidlá a programy sa môžu líšiť podľa regiónu a spôsobu distribúcie. Vyberte platobný tok až po overení konkrétneho produktu, nie podľa všeobecného tvrdenia, že jedna brána funguje všade.
Súkromné kľúče a prístupové tokeny poskytovateľa ponechajte v zodpovedajúcej serverovej ochrane. Neprenášajte ich do verejného klienta ani diagnostických záznamov. Pri platobných údajoch využite správne navrhnutý tok poskytovateľa a jasne určte, čo vaša aplikácia skutočne spracúva.
08Pilot musí prejsť aj zlyhaním a opakovaním
- Dohodnite objednávku, stavy, nárok na službu a účtovný proces.
- Vyberte poskytovateľa, verziu a overenie serverových správ.
- Otestujte úspech, čakanie, duplicitu a neúspešnú obnovu.
- Overte párovanie, komunikáciu, podporu a prevádzkovú kontrolu.
- Platba bez návratu prehliadača a návrat pred doručením oznámenia.
- Opakované alebo súbežné spracovanie toho istého výsledku.
- Neplatná karta, dodatočná akcia zákazníka a oneskorená metóda.
- Zmena tarify, zrušenie, vrátenie a obnovenie po neúspechu.
- Nedostupné účtovníctvo a následné bezpečné doplnenie záznamu.
Po spustení sledujte rozdiely medzi stavmi poskytovateľa a aplikácie. Upozornenie potrebuje vlastníka a dohľadateľné identifikátory. Testovacie a produkčné prostredie oddeľte a pri prechode skontrolujte konfiguráciu aj prístupy. Prevádzku nepreberajte iba podľa jednej úspešnej platby.
09Najčastejšie otázky o platbách v aplikácii
Stačí po platbe zobraziť stránku úspechu?
Nie. Návrat zákazníka nie je zaručený a sám nepotvrdzuje stav úhrady. Spracovanie potrebuje overenú serverovú cestu. Stránka má zobrazovať stav získaný zo správneho zdroja.
Je Stripe alebo GoPay automaticky lepšia voľba?
Rozhodujte podľa platobného modelu, metód, trhov, integrácie a prevádzky. Overte konkrétny účet, verziu a podmienky. Samotné logo ani jedna cenníková položka nevysvetlia celý náklad.
Prečo sa oznámenie spracúva opakovane?
Doručovanie môže zahŕňať opakovanie alebo súbeh. Integrácia musí zvládnuť rovnaký výsledok bez druhej obchodnej zmeny. Napríklad jedno zaplatenie nesmie dvakrát predĺžiť službu.
Vzniká faktúra vždy až po zaplatení?
Nie. Napríklad pri predplatnom v Stripe môže existovať pred úhradou. Po potvrdení platby sa môže aktualizovať alebo spárovať. Konkrétny účtovný proces navrhnite podľa predaja a používaných systémov.
Má neúspešná obnova ihneď zrušiť prístup?
To je rozhodnutie služby, nie univerzálne technické pravidlo. Dohodnite komunikáciu, ďalší pokus a prípadnú lehotu. Aplikácia musí reagovať konzistentne a používateľ má vedieť, ako problém vyriešiť.
Môžem rovnaký checkout vložiť do mobilnej aplikácie?
Najprv overte typ produktu, pravidlá distribučného obchodu a región. Digitálny obsah a fyzický tovar majú odlišné podmienky. Webový platobný tok nie je automatické riešenie pre každý mobilný nákup.