Oferta - ustawienia zaawansowane

Zakładka Zaawansowane w formularzu oferty (tworzenie i edycja) zawiera ustawienia checkoutu niezwiązane bezpośrednio z ceną ani promocjami. Poniżej każde pole opisane jest w tej samej kolejności co w formularzu. Ustawienia dotyczą wyłącznie tej oferty i obowiązują na stronie /pay, w osadzonym checkout oraz przy płatnościach powiązanych z grafikiem.

Dozwolone metody płatności

Określa, które metody płatności klient zobaczy na stronie płatności tej oferty. Dostępne opcje:

• BLIK i Karta - obie metody do wyboru przez płatnika.
• BLIK - tylko płatność BLIK (wymaga aktywnego konta Tpay w organizacji).
• Karta - tylko płatność kartą (integracja Stripe).

Co najmniej jedna metoda musi być włączona. Gdy organizacja nie ma aktywnego Tpay, opcje z BLIK są niedostępne - domyślnie zostaje karta.

Rezerwowe oferty przy błędzie na stronie płatności

Fallbacki uruchamiają się, gdy pierwsza próba płatności w danym flow checkout kończy się terminalnym błędem Tpay (status FAILED). System mapuje kod błędu z Tpay na warunek reguły; jeśli reguła pasuje, klient przechodzi do zapasowej ścieżki płatności zamiast pozostawać na pustym ekranie błędu.

Fallbacki nie dotyczą: błędów onboardingu merchanta, zwrotów, automatycznych odnowień subskrypcji ani operacji poza pierwszą płatnością w bieżącym checkout.

Włączenie i reguły

• Włącz przełącznik Rezerwowe oferty przy błędzie na stronie płatności.
• Dodaj reguły: Warunek + Przekieruj do. Przy pierwszym włączeniu domyślnie: Dowolna nieudana płatność → Oferta (wybierz ofertę zapasową).
• Reguły oceniane od góry - stosowana jest pierwsza pasująca.

Przekieruj do - typy

Pole Przekieruj do określa, co dzieje się po dopasowaniu reguły. Dostępne są trzy typy akcji - każdy opisany poniżej.

Oferta

Klient trafia na inną, wybraną przez Ciebie ofertę Zevio - otwiera się jej strona płatności (/pay) w tej samej karcie przeglądarki. Nie można wybrać bieżącej oferty; oferta zapasowa musi należeć do tej samej organizacji.

Na checkoutie oferty docelowej obowiązują jej własna cena, promocje i dozwolone metody płatności. Klient finalizuje płatność jak przy normalnym zakupie tej oferty - np. płaci kartą, gdy na pierwotnej ofercie BLIK się nie powiódł, albo wybiera tańszy plan awaryjny bez subskrypcji BLIK.

Referrale, kody polecające i promocje z pierwotnego linku nie są przenoszone (parametry takie jak ref są celowo pomijane). Inna oferta ma własny program poleceń i własne promocje - unikasz przypisania prowizji lub zniżki do niewłaściwego produktu.

Kontekst checkoutu ułatwiający płatnikowi dokończenie zakupu jest przenoszony przez parametr URL zfc: identyfikator wskazuje dane zapisane w sessionStorage (m.in. email, imię i nazwisko, dane do faktury, zgody, zapis na newsletter). Klient zwykle nie musi wpisywać ich ponownie. Pełne metadane integracyjne pierwotnej sesji nie są kopiowane - przenoszony jest wyłącznie kontekst UX płatnika.

Przy przekierowaniu na ofertę zapasową dodawany jest parametr śledzenia sfa=1 (fallback attempt), co pozwala m.in. liczyć Sukcesy po fallbacku w Analityce → Źródła.

Adres URL

Klient trafia pod podany przez Ciebie adres HTTPS (landing, strona pomocy, własny formularz) w tej samej karcie. Zevio nie hostuje tej strony - Ty decydujesz, co klient zobaczy po błędzie.

Do URL dołączane są parametry z bieżącej sesji płatności (kampania UTM, parametry źródła itp.), z wyjątkiem m.in. podpisu oferty (sig), identyfikatora oferty (qrId), linków referralowych (ref), identyfikatorów płatności i sesji checkout. Dołączany jest też skrócony kontekst checkoutu w parametrze zfc (jak przy typie Oferta).

BLIK manualny

BLIK manualny to tryb awaryjny dla subskrypcji BLIK (modele A, M lub O). Przy standardowej pierwszej płatności subskrypcji Zevio próbuje zarejestrować alias BLIK u banku klienta - dzięki temu kolejne opłaty mogą być pobierane automatycznie, bez wpisywania kodu 6-cyfrowego. Gdy bank nie obsługuje BLIK powtarzalnego i przełącznik Uruchom BLIK rekurencję manualną, gdy bank nie jest obsługiwany jest wyłączony (domyślnie), pierwsza płatność jest odrzucana - bez reguły fallbacku klient widzi twardy błąd i subskrypcja nie startuje.

Reguła BLIK manualny nie przenosi klienta na inną ofertę ani URL. Klient zostaje na tej samej ofercie i tej samej stronie płatności; w adresie pojawia się parametr blikManualFallback=1. Checkout przełącza się w tryb jednorazowego BLIK (eBLIK): klient wpisuje standardowy 6-cyfrowy kod z aplikacji bankowej, tak jak przy zwykłej płatności jednorazowej, zamiast flow rejestracji aliasu.

W trybie manualnym zwykle dostępny jest wyłącznie BLIK (karta jest ukryta), aby uprościć awaryjną ścieżkę. Po udanej płatności subskrypcja może zostać utworzona, ale kolejne odnowienia w bankach bez aliasu wymagają ponownego potwierdzenia kodem BLIK (Zevio wysyła przypomnienia e-mailem z linkiem do płatności). Typowy warunek reguły: Bank nie obsługuje BLIK powtarzalnego.

Na ekranie płatności klient widzi link Wróć do standardowej płatności - usuwa on tryb manualny z URL i przywraca normalny checkout (ponowna próba aliasu BLIK lub wybór karty, jeśli dostępna). Parametry referral/promo z oryginalnego linku pozostają, bo klient nadal jest na tej samej ofercie.

Działa na /pay, w panelu płatności merchant oraz w osadzonym checkout - wszędzie tam, gdzie obsługiwane są payment fallbacks.

Warunki błędów

• Dowolna nieudana płatność
• Bank nie obsługuje BLIK powtarzalnego (typowo z BLIK manualny)
• Nieprawidłowy lub wygasły kod BLIK
• Odrzucenie w aplikacji banku
• Odrzucenie przez bank lub wystawcę karty
• Niewystarczające środki
• Przekroczony limit transakcji
• Przekroczony czas potwierdzenia BLIK
• Odrzucenie BLIK przez bank (alias lub bezpieczeństwo)
• Bank lub kanał płatności niedostępny
• Błąd techniczny lub brak odpowiedzi

Ekran przejścia przed przekierowaniem

Osobny przełącznik pod regułami. Gdy włączony, klient widzi ekran pośredni z opisem błędu i odliczaniem (~10 s) przed kontynuacją (/payment/redirect lub /checkout/redirect). Przy włączeniu fallbacków domyślnie włączony - można wyłączyć.

Uruchom BLIK rekurencję manualną, gdy bank nie jest obsługiwany

Przełącznik dostępny tylko przy włączonej subskrypcji BLIK (zakładka Podstawowe). Domyślnie wyłączony (obowiązuje tryb strict). Określa, co dzieje się przy pierwszej płatności subskrypcji BLIK, gdy bank klienta nie wspiera BLIK powtarzalnego (brak identyfikatora payId): włączony - uruchamiamy dla takiego banku rekurencję manualną (płatność przechodzi, kolejne okresy po przypomnieniu); wyłączony - pierwsza płatność jest odrzucana.

Zevio wysyła do Tpay parametr refuseNoPayId zgodnie z tym ustawieniem. Po wpisaniu kodu BLIK Tpay zwraca w odpowiedzi createTransaction (zwykle w ~1 s) informację payIdEligible, czy bank obsługuje alias do płatności powtarzalnych. Na tej podstawie system wybiera typ subskrypcji i dalszy flow - bez czekania klienta na webhook rejestracji aliasu.

Gdy włączone - tryb permissive (rekurencja manualna)

• W ofercie zapisywane jest paymentFallbacks.refuseNoPayId: false.
• Do Tpay trafia refuseNoPayId: false - pierwsza płatność BLIK może przejść nawet bez wsparcia recurring u banku.
• Bank wspiera recurring (payIdEligible: true) - subskrypcja `BLIK_RECURRING`, automatyczne odnowienia (alias BLIK).
• Bank nie wspiera recurring (brak payIdEligible lub false) - subskrypcja `BLIK_MANUAL_RECURRING`: pierwsza płatność jednorazowym BLIK-iem, kolejne okresy klient opłaca sam po przypomnieniach e-mail (link z blikManualFallback=1).
• Na stronie sukcesu klient może zobaczyć komunikat, że bank nie wspiera płatności powtarzalnych i że o kolejnych płatnościach przypomni Zevio (parametr URL blikRecurringManual=1).

Tryb permissive pozwala zamknąć konwersję u klientów z bankami bez aliasu BLIK bez konieczności przechodzenia przez ekran błędu i regułę BLIK manualny - subskrypcja z przypomnieniami powstaje od razu po udanej pierwszej płatności.

Gdy wyłączone (domyślnie) - tryb strict

• Do Tpay trafia refuseNoPayId: true (wartość domyślna, gdy pole nie jest ustawione).
• Bank wspiera BLIK powtarzalny (payIdEligible: true) - pierwsza płatność przechodzi, subskrypcja `BLIK_RECURRING`, kolejne obciążenia automatyczne (alias BLIK).
• Bank nie wspiera BLIK powtarzalnego - pierwsza płatność jest odrzucana, subskrypcja nie powstaje.
• Klient widzi błąd na stronie płatności - chyba że zadziała reguła fallbacku (np. BLIK manualny), która przełącza go w tryb jednorazowego BLIK na tej samej ofercie.

Tryb strict jest odpowiedni, gdy chcesz wyłącznie automatyczne subskrypcje z aliasem BLIK i akceptujesz odrzucenie płatności u banków bez wsparcia (Revolut i podobne), o ile nie skonfigurujesz fallbacku.

Różnica: permissive vs reguła BLIK manualny

• Włączone „Uruchom BLIK rekurencję manualną…” (permissive) - bank bez payId: płatność od razu przechodzi, subskrypcja manual recurring, bez redirectu fallbacku.
• Reguła BLIK manualny - uruchamia się po terminalnym błędzie pierwszej płatności (typowo gdy strict odrzuci bank); klient dostaje blikManualFallback=1 na tej samej ofercie i wpisuje jednorazowy kod BLIK.
• Oba mechanizmy kończą subskrypcją `BLIK_MANUAL_RECURRING`, ale wejście klienta jest inne: automatyczne (permissive) vs po błędzie (fallback).
• Reguła BLIK manualny nadal ma sens przy wyłączonym przełączniku (tryb strict) - np. gdy chcesz strict domyślnie, ale awaryjnie ratować konwersję wybranym warunkiem błędu.

Późna rejestracja aliasu

Jeśli subskrypcja powstała jako `BLIK_MANUAL_RECURRING` (bank początkowo bez payId), a później dotrze webhook Tpay `ALIAS_REGISTER`, Zevio zapisuje alias i podnosi metodę subskrypcji do `BLIK_RECURRING`. Kolejne okresy mogą wtedy iść automatycznie - bez zmiany konfiguracji oferty.

Przypomnienia i anulowanie (manual recurring)

W formularzu: Powiadomienia o płatności dla rekurencji manualnej oraz Wygaśnięcie subskrypcji po terminie. Dodatnie offsety to dni przed terminem, 0 to dzień płatności, ujemne (np. -1) to dni po terminie. Powiadomienie po terminie musi być wcześniejsze niż wygaśnięcie. Pusta lista = domyślnie dzień przed i w dniu płatności. W REST API: recurring.manualRenewalPolicy.notifyDaysBefore oraz recurring.manualRenewalPolicy.cancelAfterDaysUnpaid (1-30 dni).

REST API

W `paymentFallbacks` obiektu oferty (POST/PUT /qr): opcjonalne pole `refuseNoPayId`. Gdy `false`, włącza tryb permissive (w UI: przełącznik Uruchom BLIK rekurencję manualną, gdy bank nie jest obsługiwany = włączony). Gdy pole nie występuje, obowiązuje domyślny tryb strict (przełącznik wyłączony).

Analityka

Analityka → Źródła → Sukcesy po fallbacku; parametr śledzenia slfa=1.

Ponawianie płatności rekurencyjnych

Pola dostępne tylko przy włączonej subskrypcji (zakładka Podstawowe). Dotyczą automatycznych obciążeń z aliasem BLIK (BLIK_RECURRING), gdy kolejna płatność cykliczna się nie powiedzie.

• Liczba ponownych powtórzeń płatności (recurring.retryPolicy.maxAttempts) - ile razy system ponowi automatyczną płatność po nieudanej próbie (1-10, domyślnie 3). Po wyczerpaniu limitu subskrypcja zostaje anulowana.
• Odstęp między ponownymi płatnościami (recurring.retryPolicy.intervalDays) - ile dni odczekać przed kolejną automatyczną próbą (1-14, domyślnie 1).

W REST API ustaw recurring.retryPolicy w POST /qr, PUT /qr/{qrId}, POST /payments oraz POST /checkout-sessions. Gdy obiekt jest pominięty, obowiązują domyślne wartości maxAttempts: 3 i intervalDays: 1.

Wybór kraju zakupu

Po włączeniu klient widzi select kraju zakupu na checkout nad metodami płatności. Kraj wpływa na walidację NIP/VAT i kontekst fiskalny płatności.

• Włącz select (countrySelect.enabled) - pokazuje listę krajów płatnikowi.
• Domyślny kraj (countrySelect.defaultIso2) - kod ISO 3166-1 alpha-2 wstępnie zaznaczony (np. PL, DE). Puste pole oznacza Polskę (PL).

Priorytet kraju: gdy klient podaje NIP/VAT, kraj z numeru ma pierwszeństwo; bez NIP używany jest wybrany kraj; gdy select jest wyłączony - geolokalizacja.

W REST API ustaw countrySelect w POST /qr, PUT /qr/{qrId}, POST /payments oraz POST /checkout-sessions.

Zbieranie leadów podczas płatności

Konfiguracja dodatkowych pól i zgód na stronie płatności. Zebrane dane trafiają do płatności, subskrypcji, webhooków i modułu Leady.

Zbieraj dane firmy przy płatności

Gdy włączone, na checkout pojawia się opcja Chcę fakturę. Po jej zaznaczeniu wymagane są: NIP, nazwa firmy, ulica, kod pocztowy i miasto. Dane trafiają do płatności, subskrypcji i webhooków.

Nadpisz domyślny tekst regulaminu

Gdy włączone, możesz zastąpić domyślny tekst regulaminu Zevio własnym HTML (Własny tekst regulaminu). Dozwolone tagi HTML, np. linki <a href="...">.

Checkbox regulaminu

• Wyświetl checkbox regulaminu - pokazuje domyślny (lub nadpisany) checkbox regulaminu przy płatności.
• Wymagany checkbox - klient musi zaakceptować regulamin przed opłaceniem (widoczne gdy checkbox jest wyświetlany).

Dodatkowe zgody

Lista własnych checkboxów zgód (np. marketing, polityka prywatności). Dla każdej zgody:

• ID zgody - stały identyfikator (max 64 znaki) zapisywany w checkoutDetails.consents i webhookach; nie może duplikować innych zgód ani ID zarezerwowanego dla regulaminu.
• Treść zgody (HTML) - tekst widoczny dla płatnika.
• Wyświetl checkbox / Wymagany checkbox - jak przy regulaminie.

Wiele subskrypcji na klienta

Pole dostępne tylko przy włączonej subskrypcji (zakładka Podstawowe). Steruje tym, czy ten sam klient może mieć wiele równoległych subskrypcji tej oferty, czy obowiązuje reguła jedna subskrypcja na klienta z automatycznym wznowieniem anulowanej / zakończonej zamiast tworzenia nowej.

W REST API ustaw recurring.allowMultipleSubscriptions w POST /qr i PUT /qr/{qrId}. Pole jest zwracane w odpowiedziach GET w obiekcie recurring.

Gdy opcja jest włączona

Ten sam klient może kupić wiele równoległych subskrypcji tej samej oferty (np. plany rodzinne, wiele miejsc, kolejne zakupy). Checkout nie przechwytuje płatności pod wznowienie - każda płatność może utworzyć nową subskrypcję.

Gdy opcja jest wyłączona (domyślnie)

Każdy klient może mieć co najwyżej jedną subskrypcję w ramach oferty. Ponowny zakup anulowanej subskrypcji (zaplanowane anulowanie albo już zakończona) wznawia istniejącą na tym samym subscriptionId zamiast tworzyć drugą. Subskrypcje COMPLETED, EXPIRED oraz te z allowResume = false (np. po archiwizacji oferty cyklicznej) nie wchodzą w ten flow.

Kiedy subskrypcja jest wznawialna

• PENDING_CANCELLATION albo cancelAtPeriodEnd = true - anulowanie zaplanowane na koniec opłaconego okresu; dostęp nadal obowiązuje.
• CANCELLED z ustawionym endedAt i cancelAtPeriodEnd = false - subskrypcja już się zakończyła.
• Wymagane: allowResume !== false oraz dopasowanie klienta (customerId) do oferty (qrId).

Wariant 1: zaplanowane anulowanie (PENDING_CANCELLATION)

• Kwota dziś: 0 PLN - tylko rejestracja / odświeżenie metody płatności (token karty lub alias BLIK).
• Typ płatności: subscription_resume (ścieżka / initiation kind SUBSCRIPTION_RESUME).
• Skutek: czyszczenie flag anulowania (cancelAtPeriodEnd, canceledAt, currentPeriodEnd), przywrócenie statusu TRIAL lub ACTIVE według promocji i liczby płatności cyklowych.
• Data następnej płatności: bez zmiany - zostaje dotychczasowa nextPaymentDate.
• Promocje: płatność 0 PLN nie zużywa limitu trialu ani innych promocji liczonych po liczbie płatności cyklowych.

Wariant 2: zakończona subskrypcja (CANCELLED)

• Kwota dziś: należna faktura wznowienia (jak kolejny cykl) - uwzględnia pozostałe promocje oferty i wpisy na subskrypcji (trial, rabaty, kupony, referral).
• Typ płatności: subscription_reactivate (też ścieżka SUBSCRIPTION_RESUME).
• Skutek: ponowne podpięcie metody, rozliczenie kwoty, kontynuacja cyklu życia na tym samym subscriptionId.
• Data następnej płatności: dzień wznowienia + interwał (np. wznowienie 10.08 przy 1M → następna 10.09). Nie wraca stary kalendarz sprzed anulowania. Jawny monthlyAnchorDay z oferty, jeśli ustawiony; w przeciwnym razie kotwica od dnia wznowienia.
• Promocje: licznik to udane płatności cyklowe (bez subscription_resume i bez proration contents). Jeśli trial „2 płatności” i jedna już była - zostaje 1; po wyczerpaniu - cena bazowa oferty.

Gdzie widać flow

• Strona płatności oferty (`/pay`) - przy zidentyfikowanym kliencie checkout przechwytuje tworzenie płatności i startuje wznowienie. Oferta zwraca m.in. resumableSubscriptionId, resumeTotalDueToday, resumeNextPaymentDate, resumeCompletedPaymentCount. Breakdown (netto, VAT, rabat, „obowiązuje przez N płatności”, data następnej płatności) jak przy zwykłym checkoutcie, z pozostałymi promocjami; w sandbox - od zegara symulacji subskrypcji.
• Panel merchant - szczegóły subskrypcji - przycisk Wznów subskrypcję (gdy status na to pozwala i allowResume). Modal: kwota dziś (0 PLN albo faktura reactivate), promocje i data następnej płatności - spójnie z /pay.
• Portal klienta (sesja) - akcja Wznów dla wznawialnych subskrypcji; te same reguły kwot i dat.

Płatności, ścieżka i historia

• W historii płatności subskrypcji i na liście transakcji kolumna Ścieżka (initiationKind) pokazuje Wznowienie (SUBSCRIPTION_RESUME).
• Płatność subscription_resume (0 PLN) nie zwiększa completedOccurrences ani nie zużywa trialu. subscription_reactivate liczy się jak płatność cyklowa. Licznik cyklu jest spójny z udanymi płatnościami cyklowymi (bez resume 0 PLN i proration contents).
• Kolejna próba wznowienia przy wiszącym PENDING poprzedniego resume anuluje stare PENDING (supersede) i startuje nowe.

Webhooki przy udanym wznowieniu

Oczekiwana kolejność: payment.pending → payment.success → jeden subscription.updated (status TRIAL/ACTIVE itd.). Bez wcześniejszego „gołego” subscription.updated tylko od zdjęcia anulowania. Payload może zawierać paymentId i paymentProcessedAt po sukcesie płatności. Szczegóły zdarzeń: dokumentacja Webhooki.

Symulacja czasu (sandbox / test)

Gdy na subskrypcji ustawiono zegar symulacji, faktura reactivate i data następnej płatności na /pay oraz w szczegółach liczą się od daty symulacji (np. symulacja 5.09 przy 1M → następna 5.10), a nie od prawdziwego „dziś”.

Blokada anulowania subskrypcji

Pole dostępne tylko przy włączonej subskrypcji (zakładka Podstawowe). Określa minimalny okres od startu subskrypcji, w którym klient nie może anulować subskrypcji w portalu klienta. Po upływie tego okresu anulowanie zostaje odblokowane.

• Brak ograniczeń - klient może anulować w dowolnym momencie (domyślnie).
• Gotowe presety - miesiąc, kwartał, pół roku, rok.
• Inne - własna liczba i jednostka (dni, tygodnie, miesiące, lata).

Organizacja może anulować subskrypcję w panelu w dowolnym momencie, niezależnie od blokady.

Grupa ofert

Łączy tę ofertę z innymi wariantami tego samego produktu (np. plany Basic / Pro). Grupa może zawierać maksymalnie 3 oferty łącznie z bieżącą. Wszystkie oferty muszą należeć do tej samej organizacji.

Oferty w grupie

Wybierz do 2 innych ofert (offerGroupMemberQrIds), które wraz z bieżącą tworzą grupę. Po zapisaniu członkowie grupy są zwracani w odpowiedzi oferty jako offerGroupResolved.members.

Przełączanie na checkout

Gdy włączone Zezwól na przełączanie między ofertami w checkout (offerGroup.switchingEnabled, domyślnie włączone), klient na stronie płatności widzi listę wariantów z kwotami i może wybrać inną ofertę z grupy - strona przeładowuje się na wybrany qrId.

Zmiana planu w aktywnej subskrypcji

Gdy włączone Zezwól klientom na zmianę planu w aktywnej subskrypcji (offerGroup.subscriptionSwitchingEnabled), klient w portalu subskrypcji widzi sekcję zmiany planu między członkami grupy. Organizacja widzi tę opcję w panelu zawsze.

W panelu i API oferty ustaw offerGroupMemberQrIds oraz opcjonalnie offerGroup (switchingEnabled, subscriptionSwitchingEnabled) przy tworzeniu i aktualizacji oferty (POST /qr, PUT /qr/{qrId}).

Oferta retencyjna (anti-churn)

Dostępna tylko przy włączonej rekurencji z modelem BLIK M lub O. Gdy klient anuluje subskrypcję tej oferty, zamiast od razu zakończyć flow, system może zaproponować przejście na inną ofertę (tańszy plan, wariant roczny itd.).

• Włącz ofertę retencyjną (recurring.retentionOffer.enabled).
• Oferta docelowa (recurring.retentionOffer.targetQrId) - oferta z tej samej organizacji, na którą klient może przejść zamiast rezygnacji.

Propozycja pojawia się w portalu klienta przy anulowaniu subskrypcji. Po wyborze planu retencyjnego subskrypcja jest przełączana na ofertę docelową zamiast anulowania.

Przy tworzeniu i aktualizacji oferty ustaw recurring.retentionOffer (POST /qr, PUT /qr/{qrId}).

Strona podziękowania

Określa, co klient widzi po udanej płatności na /pay lub w osadzonym checkout. Trzy tryby:

• Domyślna - ekran sukcesu Zevio ze standardowym tytułem, opisem i akcjami.
• Zewnętrzny URL - opcjonalne przekierowanie HTTPS po sukcesie. Gdy ustawione, klient trafia na Twoją stronę zamiast ekranu Zevio.
• Własna strona domyślna - ekran sukcesu Zevio z własnym tytułem, opisem i opcjonalnym przyciskiem (etykieta + URL). Ustaw button.enabled na false, aby ukryć przycisk i domyślne akcje.

W REST API użyj successUrl do zewnętrznego przekierowania oraz resultPages.success do personalizacji. W odpowiedziach personalizacja jest w links.resultPages.success oferty.

W checkout osadzonym (iframe/popup) do strony nadrzędnej wysyłane są zdarzenia postMessage: CHECKOUT_STARTED po zatwierdzeniu płatności przez klienta oraz CHECKOUT_SUCCESS przy końcowym sukcesie - niezależnie od tego, czy podano własny URL.

Strona błędu

Określa, co klient widzi po anulowaniu płatności lub błędzie, gdy nie zadziałał fallback (albo fallback nie był skonfigurowany). Trzy tryby:

• Domyślna - ekran błędu Zevio ze standardowym tytułem, opisem i akcjami.
• Zewnętrzny URL - opcjonalne przekierowanie HTTPS po błędzie lub anulowaniu.
• Własna strona domyślna - ekran błędu Zevio z własnym tytułem, opisem, ponowieniem płatności (retryEnabled) i opcjonalnym przyciskiem (etykieta + URL).

W REST API użyj cancelUrl do zewnętrznego przekierowania oraz resultPages.failed do personalizacji (w tym retryEnabled). W odpowiedziach personalizacja jest w links.resultPages.failed oferty.

W osadzonym checkout do strony nadrzędnej wysyłane są zdarzenia postMessage: CHECKOUT_STARTED po zatwierdzeniu płatności oraz CHECKOUT_FAILED przy końcowym błędzie lub anulowaniu. Własny URL błędu powoduje dodatkowe przekierowanie tylko wtedy, gdy adres jest podany.

Metadane

Lista par klucz-wartość (do 50 wpisów, klucz max 255 znaków) przekazywanych do płatności, sesji checkout i webhooków: payment.success, payment.failed, qr.created, qr.updated. Przykłady: order_id, cart_id, source - przydatne do integracji z CRM, ERP lub własnym backendem.

Raport Stripe

Przełącznik włącza raportowanie transakcji tej oferty do Stripe. Dostępny tylko gdy organizacja ma aktywną integrację Stripe (Deweloperzy → Stripe). Gdy integracja nie jest skonfigurowana, pole jest nieaktywne.