Stripe — jak płacić: integracje i bezpieczeństwo

Stripe API łączy sklep z usługą płatności Stripe. Dzięki temu sklep może przyjmować karty kredytowe, debetowe oraz portfele cyfrowe, w tym Apple Pay i Google Pay.¹ W artykule wyjaśniamy, jak przebiega płatność klienta oraz co firma robi z jej wynikiem, zwrotem lub błędem.
Stripe obsługuje ponad 125 metod płatności dostępnych klientom na różnych rynkach².

Czym jest integracja Stripe API z perspektywy małej firmy?

Integracja Stripe API przekazuje dane potrzebne do płatności i odbiera wynik transakcji. Mała firma musi ustawić dostęp, przetestować zakup i zadbać o aktualizację statusu zamówienia. Komunikat pokazany klientowi nie wystarczy – sklep powinien sprawdzić wynik we własnym systemie.
Połączenie ze Stripe API wymaga co najmniej protokołu TLS 1.2³.

Konfigurację zaczyna się od rozdzielenia środowiska testowego i produkcyjnego. Klucze API uwierzytelniają żądania wysyłane do Stripe API.⁴ Gdy sklep przechodzi na rzeczywiste płatności, musi zastąpić klucze testowe produkcyjnymi.⁴
Klucze testowe mają prefiksy pk_test_ i sk_test_, a produkcyjne – pk_live_ i sk_live_; pk_ oznacza klucz publiczny, sk_ – tajny⁴.

Do czego służą klucze API przy łączeniu sklepu ze Stripe?

Stripe rozpoznaje żądania sklepu za pomocą kluczy API. Właściciel umieszcza właściwy klucz w ustawieniach modułu albo przekazuje go osobie wdrażającej połączenie. Klucz testowy służy do prób, a produkcyjny do przyjmowania zapłaty.
Stripe udostępnia również klucze z ograniczonymi uprawnieniami: mają prefiks rk_, na przykład rk_live_ w środowisku produkcyjnym⁴.

Tabela pokazuje, do czego służą klucze w obu środowiskach sklepu. Testy nie pobierają rzeczywistych płatności; środowisko produkcyjne już je przyjmuje⁴.

Jak sklep przekazuje płatność do Stripe i odbiera jej wynik?

Połączony ze Stripe sklep wysyła żądanie płatności, a potem wykorzystuje jej wynik przy obsłudze zamówienia. Stripe zaleca tworzenie dokładnie jednego PaymentIntent dla każdego zamówienia lub sesji zakupowej⁵.

• Sklep przygotowuje zamówienie i ustala kwotę do zapłaty.
• Integracja wysyła do Stripe żądanie dotyczące płatności.
• Klient wykonuje czynności wymagane przez wybraną metodę płatności.
• Sklep odczytuje wynik i aktualizuje na jego podstawie status zamówienia.

Status zamówienia ma odpowiadać wynikowi płatności, nie samemu powrotowi klienta na stronę sklepu. Status PaymentIntent „succeeded” wskazuje udaną płatność; pozostałe mogą oznaczać potrzebę dalszych działań⁶.

Jak sprawdzić przebieg płatności w trybie testowym?

Tryb testowy Stripe pozwala przejść przez zakup bez pobierania pieniędzy. Karta testowa 4242 4242 4242 4242 symuluje udaną płatność bez rzeczywistego obciążenia⁷.

• Konfiguracja testowa uruchamia sklep z dostępem właściwym dla środowiska testowego.
• Zamówienie testowe pozwala prześledzić drogę od koszyka do komunikatu o płatności.
• Status płatności i zamówienia pokazuje, czy sklep zapisał wynik zgodnie z przebiegiem próby.

Na koniec warto porównać ekran klienta ze statusem widocznym dla obsługi sklepu.
Karta testowa 4000 0000 0000 0002 symuluje odrzucenie płatności, dzięki czemu można sprawdzić reakcję obu paneli⁷.

Gdzie sprawdzić, czy żądanie do Stripe zostało przyjęte?

Panel Stripe pokazuje, co stało się z żądaniem płatniczym. Panel sklepu pozwala z kolei sprawdzić, jak zapisano wynik przy zamówieniu. Pełne dane zdarzeń pozostają dostępne w panelu Stripe przez 30 dni; starsze widać tylko jako podsumowanie⁸.

• Panel Stripe pomaga sprawdzić płatność i komunikaty związane z jej obsługą.
• Panel sklepu pokazuje status zamówienia zapisany przez integrację.

Przyjęte żądanie nie oznacza jeszcze, że klient zapłacił. Jeśli panele pokazują różne informacje, trzeba zestawić wynik płatności ze statusem zamówienia.
Odpowiedź HTTP 200 potwierdza poprawną obsługę żądania API; zapłatę potwierdza status PaymentIntent „succeeded”, a nie „requires_action”⁹.

Połączenie działa zgodnie z celem dopiero wtedy, gdy wynik płatności trafia do właściwego zamówienia¹⁰.

Czym są webhooki Stripe i jak informują sklep o zdarzeniach?

Webhooki Stripe powiadamiają sklep o zdarzeniach dotyczących płatności. Dzięki nim zamówienie może zmienić status, nawet jeśli klient zamknął stronę płatności. Powiadomienie trafia na skonfigurowany adres, a sklep przypisuje zdarzenie do zamówienia.
W środowisku produkcyjnym Stripe ponawia próby dostarczenia webhooka przez maksymalnie trzy dni¹¹.

Powrót klienta i webhook mają różne zadania. Powrót prowadzi kupującego do dalszego ekranu, a webhook przekazuje zdarzenie systemowi sklepu. O obsłudze zamówienia powinien decydować ustalony wynik płatności, nie samo otwarcie strony potwierdzenia. W Checkout zdarzenie „checkout.session.completed” dotyczy zakończenia sesji, a „checkout.session.async_payment_succeeded” informuje o powodzeniu płatności potwierdzonej później¹².

Jak przygotować sklep do odbierania powiadomień o płatnościach?

Sklep konfiguruje odbiór webhooków, aby przypisywać zdarzenia płatnicze do zamówień. Biblioteki Stripe domyślnie dopuszczają pięć minut różnicy między znacznikiem czasu zdarzenia a bieżącym czasem przy weryfikacji podpisu¹¹.

• Osoba konfigurująca sklep podaje adres odbiorczy webhooków w ustawieniach integracji.
• Osoba konfigurująca Stripe wybiera zdarzenia potrzebne sklepowi do obsługi płatności i zwrotów.
• Integracja sklepu sprawdza autentyczność powiadomienia za pomocą sekretu podpisu webhooka, który jest odrębny od klucza API.
• Sklep przypisuje zdarzenie do zamówienia i aktualizuje jego status.
• Obsługa sklepu sprawdza, czy status zmienia się także bez powrotu klienta na stronę potwierdzenia.

Odebrany webhook pozwala sklepowi zareagować na zdarzenie niezależnie od tego, co kupujący widzi w przeglądarce¹³.

Stripe API w sklepie i na platformie: płatności oraz Connect

Stripe API łączy zakup z obsługą płatności we własnym sklepie. Stripe Connect służy natomiast platformom przyjmującym płatności na rzecz sprzedawców. Sklep rozlicza własne zamówienie, a operator marketplace musi również przypisać płatność odpowiedniemu sprzedawcy.
Tradycyjny podział kont połączonych w Stripe Connect obejmuje trzy typy: Standard, Express i Custom¹⁴.

Stripe Radar dotyczy innego zadania. Jego API wykorzystuje uczenie maszynowe do wykrywania oszukańczych transakcji i zapobiegania im.¹ Właściciel sklepu powinien więc oddzielić przyjmowanie płatności od kontroli ryzyka.

Co upraszcza Stripe przy przyjmowaniu płatności online?

Stripe pozwala powiązać zapłatę z zamówieniem bez ręcznego uzgadniania każdego potwierdzenia. Klient wybiera metodę płatności w formularzu, a sklep otrzymuje wynik potrzebny do dalszej obsługi. Wynik transakcji i status zamówienia nie są jednak tym samym: status zapisuje sklep.

Kiedy Stripe Connect przydaje się platformie obsługującej sprzedawców?

Stripe Connect odpowiada potrzebom platformy, która pośredniczy w sprzedaży różnych sprzedawców. Jej operator musi przypisać płatność sprzedawcy oraz ustalić sposób obsługi rozliczeń i zwrotów. Firma sprzedająca wyłącznie własne produkty nie mierzy się z tym samym zadaniem organizacyjnym.

Czym różni się Stripe API od gotowej wtyczki sklepowej?

Stripe API pozwala oprogramowaniu wymieniać dane ze Stripe. Wtyczka sklepowa jest natomiast gotowym połączeniem przygotowanym dla określonej platformy. W WooCommerce, PrestaShop lub Shopify sklep działa w granicach ustawień wybranego modułu. Własna integracja daje większą kontrolę nad przebiegiem zamówienia, ale firma musi ją utrzymywać.

Jak zacząć przyjmować płatności przez Stripe?

Przed konfiguracją płatności firma powinna ustalić, czy sprzedaje we własnym imieniu, czy prowadzi platformę dla innych sprzedawców. Od tej decyzji zależy zakres wdrożenia.

• Właściciel sklepu zakłada konto do obsługi płatności i uzupełnia wymagane informacje o firmie.
• Osoba konfigurująca sklep wybiera integrację dla używanej platformy albo zleca połączenie przez API.
• Obsługa sklepu przechodzi próbny zakup i porównuje wynik płatności ze statusem zamówienia.
• Osoba odpowiedzialna za uruchomienie sprzedaży przełącza integrację na środowisko produkcyjne przed przyjęciem rzeczywistej zapłaty.

Inaczej uruchamia się płatności we własnym sklepie, a inaczej na platformie obsługującej sprzedawców.

API płatnicze bez żargonu: działanie i dostępne rozwiązania

API płatnicze umożliwia wymianę informacji między sklepem a usługą płatności. Sklep wysyła żądanie i ustala wynik transakcji. Klient widzi formularz oraz komunikat, lecz obsługa potrzebuje wyniku przypisanego do zamówienia.
Sposób połączenia zależy od wyboru modułu, gotowego formularza lub własnej integracji.

Czym jest API płatnicze z punktu widzenia sklepu?

Oprogramowanie sklepu wysyła przez API dane potrzebne do rozpoczęcia płatności. Potem wykorzystuje otrzymaną odpowiedź przy obsłudze zamówienia. Właściciel firmy nie musi sam tworzyć żądań; robi to skonfigurowane oprogramowanie. Dla obsługi najważniejsze jest jednoznaczne powiązanie wyniku transakcji z zakupem.

Jak informacja o płatności wraca do sklepu?

Integracja płatnicza przekazuje sklepowi wynik transakcji, aby mógł odpowiednio oznaczyć zamówienie. Powiązanie z konkretnym zakupem trzeba zachować na każdym etapie.

• Sklep zapisuje zamówienie, którego dotyczy płatność.
• Usługa płatności obsługuje próbę zapłaty i ustala jej wynik.
• Integracja sklepu odbiera wynik i dopasowuje go do zamówienia.
• Panel sklepu pokazuje status, na którego podstawie działa obsługa.

Komunikat dla klienta nie zastępuje wyniku zapisanego przy zamówieniu. Takie powiązanie przydaje się również wtedy, gdy kupujący zgłasza problem już po opuszczeniu strony płatności.

Jakie zadania poza przyjęciem płatności może obsługiwać API?

Stripe API pomaga łączyć informacje o klientach, płatnościach i zwrotach z danymi sklepu. Parametr metadata dodaje pary klucz–wartość do aktualizowalnych obiektów Stripe: Customer (danych klienta), PaymentIntent (próby płatności), Refund (zwrotu) i Subscription (subskrypcji).⁹ Sklep może umieścić tam własny identyfikator, aby łatwiej znaleźć odpowiadający mu obiekt Stripe.⁹

Identyfikator zamówienia pomaga obsłudze odnaleźć transakcję podczas wyjaśniania sprawy klienta. Metadane ułatwiają identyfikację, ale nie zastępują statusu płatności. Nie należy więc traktować ich jako potwierdzenia zapłaty.

Czym różnią się gotowy moduł, formularz płatności i własna integracja?

Gotowy moduł, formularz płatności i własna integracja rozwiązują różne problemy sklepu. Moduł łączy platformę z usługą płatności, a formularz daje klientowi miejsce do zapłaty. Własna integracja określa wymianę danych i sposób obsługi zamówienia. Sam formularz nie zapisze wyniku płatności w systemie sklepu.

Tabela zestawia zadanie każdego rozwiązania z jego ograniczeniem i sytuacją, w której nie będzie właściwym wyborem.

O wyborze powinny decydować przebieg zamówienia i możliwość utrzymania połączenia. Wygląd ekranu płatności nie mówi jeszcze, jak sklep zapisze wynik transakcji.

Płatność klienta krok po kroku: od wyboru metody do potwierdzenia

Klient wybiera metodę płatności, podaje wymagane dane i otrzymuje wynik transakcji. Sklep odpowiada za powiązanie tej transakcji z zamówieniem. Stripe.js, Stripe Elements i Checkout Sessions API mogą tworzyć zaplecze strony płatności; kupujący nie obsługuje ich osobno.

• Stripe.js działa w przeglądarce klienta, a dokumentacja opisuje obiekty i metody tej biblioteki JavaScript.¹⁵ Kupujący korzysta ze strony zakupu bez instalowania biblioteki.
• Stripe Elements udostępnia pola na dane płatnicze. Integracja Stripe.js wymaga klucza publikowalnego, a Elements osadza w formularzu ramkę iframe do bezpiecznego zbierania tych danych.¹⁵
• Checkout Sessions API może służyć do przygotowania strony płatności; Stripe opisuje jej budowę z użyciem React i Stripe Elements.¹⁵ Klient przechodzi zakup, nie wybiera sposobu wdrożenia strony.

Kupujący wybiera dostępną metodę, wpisuje dane i w razie potrzeby potwierdza płatność. Sklep powinien ustalić wynik transakcji przed oznaczeniem zamówienia jako opłaconego. Powrót klienta na stronę potwierdzenia nie wystarcza.

Potwierdzenie zakupu powinno odpowiadać rzeczywistemu statusowi płatności przypisanej do zamówienia. Ma to znaczenie zarówno dla komunikatu widocznego dla kupującego, jak i dla dalszej pracy sklepu.

Błędy Stripe API: co widzi klient, a co może sprawdzić sklep?

Klient widzi komunikat na stronie, a sklep może zestawić status zamówienia z wynikiem żądania do Stripe. Stripe API używa kodów odpowiedzi HTTP do sygnalizowania powodzenia lub błędu żądania; zakres 2xx oznacza powodzenie.⁹
Poprawne żądanie nie dowodzi jeszcze, że klient zapłacił¹⁶.

Tabela pokazuje, co zgłasza klient i jakie informacje sklep powinien sprawdzić w każdej z tych sytuacji.

Klient, który nie zna wyniku poprzedniej próby, powinien wstrzymać ponowną zapłatę i przekazać sklepowi dane zamówienia. Sklep najpierw ustala status płatności, a dopiero potem udziela odpowiedzi. Rozstrzyga wynik konkretnej transakcji, nie komunikat w przeglądarce.

API w prostych słowach: połączenie sklepu z usługą płatności

Stripe API umożliwia oprogramowaniu sklepu wysyłanie żądań i odczytywanie odpowiedzi. Firma korzysta z tego przy wyszukiwaniu transakcji, uzgadnianiu zamówień i obsłudze zwrotów. Te czynności wykonuje integracja; właściciel sklepu nie wpisuje ręcznie poleceń API.

Dokumentacja Stripe API domyślnie pokazuje żądania HTTP zapisane dla narzędzia curl. Przykłady można przełączyć na oficjalne biblioteki klienckie, czyli gotowe narzędzia dla programistów.⁹ Taki wybór dotyczy osoby wdrażającej połączenie, nie klienta płacącego za zakup.

• Aktualizacja obiektu obejmuje 1 obiektu na żądanie; Stripe API nie obsługuje zbiorczej aktualizacji obiektów.⁹ Integracja musi więc aktualizować różne transakcje osobno.
• Odpowiedź listowa zawiera tablicę data z wynikami podzielonymi na strony według parametrów żądania.⁹ Przy przeglądaniu historii sklep musi uwzględnić kolejne strony.
• Wyszukiwanie wymaga parametru query, który określa poszukiwane dane.⁹ Własny identyfikator zamówienia pomaga powiązać znalezioną transakcję ze sprawą klienta.

Zmiana danych, przeglądanie listy i wyszukiwanie transakcji to odrębne czynności. Osoba wdrażająca integrację dobiera ich sposób wykonania do zadania sklepu.

Klucze dostępu do Stripe: kto powinien nimi zarządzać?

Kluczami Stripe API powinien zarządzać właściciel konta lub upoważniona osoba utrzymująca integrację. Dostęp do ustawień konta nie jest tym samym co dostęp do wartości klucza. Pracownik wyjaśniający status zamówienia klientowi nie potrzebuje tajnego klucza.
Poza backendem aplikacji można bezpiecznie udostępniać tylko klucze publikowalne; tajne oraz te z ograniczonymi uprawnieniami wymagają ochrony⁴.

Gdzie właściciel sklepu zarządza kluczami API?

Właściciel konta Stripe zarządza kluczami w jego ustawieniach. Osoba wdrażająca płatności umieszcza odpowiedni klucz w konfiguracji sklepu, bez publicznego pokazywania danych dostępowych. Uprawnienia do ustawień kluczy powinny mieć osoby uruchamiające lub utrzymujące płatności. Obsługa zamówień może pracować na statusach transakcji bez odczytywania kluczy.

Kiedy trzeba wyświetlić klucz API?

Tajny klucz Stripe API trzeba odczytać podczas konfiguracji albo bezpiecznie przekazać osobie wdrażającej integrację. Wartości utworzonego tajnego klucza nie da się później ponownie pobrać.⁴ Nie wolno umieszczać go w wiadomości do klienta, publicznym zgłoszeniu ani kodzie strony widocznym w przeglądarce.

Co oznacza wygaśnięcie klucza dla płatności?

Wygaśnięcie lub unieważnienie klucza odbiera korzystającej z niego integracji możliwość wysyłania żądań wymagających tego dostępu. Sklep musi odróżnić taki problem od odmowy płatności konkretnego klienta. Błąd na stronie zakupu sam nie wskazuje przyczyny. Osoba utrzymująca połączenie bada dostęp, a obsługa ustala wynik zgłoszonej transakcji.

Jak przywrócić działanie integracji po utracie dostępu?

Po utracie dostępu integrację przywraca osoba upoważniona do zarządzania kontem i konfiguracją sklepu. Przed wznowieniem sprzedaży trzeba sprawdzić również zapis wyniku płatności.

• Administrator sklepu ustala, która integracja korzystała z niedostępnego klucza.
• Osoba zarządzająca kontem Stripe tworzy odpowiedni nowy klucz, jeśli poprzedni został utracony lub unieważniony.
• Osoba utrzymująca integrację zastępuje klucz w bezpiecznej konfiguracji sklepu.
• Obsługa sklepu sprawdza przebieg płatności i zgodność jej wyniku ze statusem zamówienia przed wznowieniem sprzedaży.

Do przywrócenia sprzedaży potrzebne są zarówno działający dostęp do Stripe, jak i poprawny zapis płatności w sklepie⁴.

Klucze API dla autonomicznych agentów: granice dostępu do płatności

Klucz Stripe API z ograniczonymi uprawnieniami pozwala wyznaczyć zakres działań autonomicznego agenta bez przyznawania mu pełnego dostępu. Można oznaczyć taki klucz jako należący do agenta.⁴ Oznaczenie wyjaśnia jego zastosowanie, ale to uprawnienia określają możliwe działania.

Właściciel sklepu powinien zdecydować, czy agent tylko odczytuje transakcje, czy również zmienia dane. Innej decyzji wymaga sprawdzanie statusu, a innej inicjowanie zwrotów. Autonomiczny agent powinien otrzymać uprawnienia potrzebne do swojego zadania. Zakres dostępu trzeba więc powiązać z konkretną czynnością.

Ograniczony dostęp do klucza API jako zabezpieczenie sklepu

Zasady dostępu do kluczy Stripe API mogą ograniczać źródła żądań wysyłanych przez integrację. Reguły uwzględniają adresy IP, zakresy CIDR, identyfikatory sieci ASN, kraje oraz źródła takie jak publiczne i domowe serwery proxy.⁴ Kontrola źródła uzupełnia uprawnienia klucza, ale ich nie zastępuje.

Kiedy ograniczenie dostępu do wybranych adresów IP ma sens?

Ograniczenie według adresu IP ma sens, gdy serwer sklepu wysyła żądania ze stałego, znanego adresu. Właściciel integracji może wtedy dopuścić to źródło i odrzucić ruch spoza wskazanej sieci. Jeśli adres serwera się zmienia, reguła może zablokować prawidłowe żądania. Taką zmianę trzeba uwzględnić w konfiguracji.

Zasada dostępu powinna odpowiadać rzeczywistemu działaniu sklepu. Chroni wtedy klucz bez blokowania płatności. Osoba utrzymująca integrację musi uwzględnić źródło żądań wysyłanych przez sklep.

Wymiana klucza API bez gubienia informacji o integracji

Wymiana klucza Stripe API zaczyna się od ustalenia, która integracja z niego korzysta. Właściciel sklepu powinien przypisać klucz do konkretnego zastosowania, na przykład połączenia z płatnościami. Taki opis ułatwia odnalezienie konfiguracji wymagającej zmiany i zmniejsza ryzyko pominięcia działającego połączenia⁴.

Po co nadawać kluczowi nazwę i dopisywać notatkę?

Nazwa i notatka dotycząca klucza API pomagają rozpoznać jego zastosowanie oraz osobę odpowiedzialną za integrację. Opis powinien wskazywać system, środowisko i właściciela konfiguracji, lecz nie zawierać wartości klucza. Przy wymianie administrator łatwiej znajdzie właściwe połączenie i sprawdzi je po zmianie.

Opis identyfikuje integrację; nie służy do przechowywania danych dostępowych. Powinien być czytelny także dla osoby, która później przejmie utrzymanie połączenia.

Dziennik żądań API: od czego zacząć szukanie przyczyny błędu?

Dziennik żądań Stripe API pomaga ustalić, czy żądanie dotarło do Stripe i jaką otrzymało odpowiedź. Dzienniki powiązane z kluczem API są dostępne w Workbench w Stripe Dashboard.⁴ Osoba utrzymująca integrację może znaleźć żądanie dotyczące zgłoszonej płatności i porównać je ze statusem zamówienia.

Brak żądania w dzienniku kieruje uwagę na połączenie sklepu ze Stripe. Odpowiedź z błędem wskazuje z kolei na problem z samym żądaniem. Nawet poprawnie przyjęte żądanie nie potwierdza zapłaty, więc wynik płatności trzeba ustalić osobno.

Wersja specyfikacji OpenAPI a zgodność integracji ze Stripe

Specyfikacja OpenAPI Stripe opisuje interfejs dla osoby wdrażającej płatności. Wybrany wariant decyduje o zakresie endpointów widocznych w dokumentacji. Repozytorium Stripe rozróżnia wariant ogólnie dostępny, wariant z publiczną wersją zapoznawczą oraz starszy wariant o węższym zakresie.¹⁷

• /latest/ obejmuje ogólnie dostępne endpointy API v1 i v2.¹⁷ To punkt odniesienia dla integracji używającej publicznie dostępnych funkcji.
• /preview/ zawiera również endpointy w publicznej wersji zapoznawczej.¹⁷ Przed wdrożeniem firma powinna odróżnić je od funkcji ogólnie dostępnych.
• /openapi/ jest starszym wariantem obejmującym tylko API v1.¹⁷ Nie pokazuje całego zakresu nowszych wariantów.

Publiczne specyfikacje OpenAPI wystarczają do większości zastosowań. Warianty SDK zawierają z kolei adnotacje i funkcje wspierające generowanie bibliotek Stripe API.¹⁷ Wybór dokumentacji powinien wynikać z zakresu integracji, nie z wyglądu formularza.

Co oznacza wersja OpenAPI w dokumentacji integracji?

Wersja OpenAPI określa sposób opisania interfejsu w pliku specyfikacji. Sama nie potwierdza, z której wersji Stripe API korzysta sklep. Osoba utrzymująca połączenie powinna ustalić osobno wariant specyfikacji i wersję używaną przez działającą integrację. Dla właściciela sklepu liczy się również sprawdzenie płatności po zmianie dokumentacji.

Rozszerzenia dostawcy w specyfikacji: wskazówki dla osoby wdrażającej płatności

Rozszerzenia dostawcy w specyfikacji OpenAPI przekazują osobie wdrażającej wskazówki wykraczające poza standardowy opis żądań i odpowiedzi. Mogą z nich korzystać narzędzia generujące kod lub dokumentację. Klient nie wpisuje tych danych podczas płatności.

Osoba wdrażająca musi odróżniać wymagane dane żądania od wskazówek dla narzędzi programistycznych. Po zmianie sposobu generowania lub aktualizacji integracji powinna sprawdzić zapis wyniku i jego powiązanie z zamówieniem. Właściciel sklepu oceni skutek po działaniu zakupów, nie po samej zawartości specyfikacji¹⁷.

Kod waluty w płatności: co oznacza pole currency?

Pole currency określa walutę kwoty przekazywanej w żądaniu płatności. Sklep powinien powiązać ją z ceną widoczną w koszyku i walutą zapisaną przy zamówieniu. Rozbieżność utrudni później ustalenie, jaką kwotę klient miał zapłacić.

Klient powinien zobaczyć kwotę i walutę przed zatwierdzeniem płatności. Przy wyjaśnianiu transakcji obsługa porównuje walutę zamówienia z walutą płatności, a nie tylko same kwoty. Pole currency pozwala jednoznacznie odczytać wartość transakcji.

Tryb payment, setup czy subscription: jaki scenariusz wybiera sklep?

Stripe Checkout ma tryby odpowiadające różnym celom sklepu. payment służy jednorazowej zapłacie, setup przygotowuje metodę płatności na przyszłość, a subscription rozpoczyna subskrypcję. Wybór zależy od tego, czy klient płaci teraz, zapisuje metodę, czy rozpoczyna rozliczenie cykliczne.

Tabela zestawia cel każdego trybu z czynnością klienta i sytuacją, w której tryb nie pasuje.

Przygotowanie metody płatności nie oznacza pobrania pieniędzy. Jednorazowy zakup nie tworzy też subskrypcji. Tryb Stripe Checkout musi odpowiadać warunkom pokazanym klientowi przed potwierdzeniem.

Najczęściej zadawane pytania

Jaki minimalny protokół TLS wymaga połączenie ze Stripe API?

Połączenie musi obsługiwać co najmniej TLS 1.2.

Czy przez Stripe można przyjmować Apple Pay i Google Pay?

Tak. Stripe obsługuje portfele cyfrowe, w tym Apple Pay i Google Pay.

Ile metod płatności obsługuje Stripe na różnych rynkach?

Stripe obsługuje ponad 125 metod płatności dostępnych klientom na różnych rynkach.

Czy Stripe Radar służy do przyjmowania płatności?

Nie. Radar wykorzystuje uczenie maszynowe do wykrywania oszukańczych transakcji i zapobiegania im.

Do jakich obiektów Stripe można dodać metadane?

Metadane można dodawać między innymi do obiektów Customer, PaymentIntent, Refund i Subscription.

Czy metadane mogą pomóc znaleźć zwrot w Stripe?

Tak. Własny identyfikator zapisany w metadanych obiektu Refund może ułatwić jego odnalezienie.

Czy Stripe.js działa w przeglądarce klienta?

Tak. Stripe.js działa w przeglądarce; kupujący nie obsługuje go osobno.

Czy jeden PaymentIntent powinien obsługiwać kilka zamówień?

Nie. Stripe zaleca utworzenie dokładnie jednego PaymentIntent dla każdego zamówienia lub sesji zakupowej.