WooCommerce Stripe – błąd „No such customer” blokuje automatyczne odnawianie subskrypcji

WooCommerce Stripe – błąd „No such customer” może blokować automatyczne odnawianie subskrypcji

W integracji WooCommerce Stripe Gateway zgłoszono poważny problem, który może uniemożliwiać automatyczne odnawianie subskrypcji po zmianie operatora obsługującego płatności. W określonych warunkach klient może pomyślnie opłacić zaległe zamówienie, ale każda kolejna próba automatycznego pobrania należności kończy się komunikatem „No such customer”.

Problem został zgłoszony 7 listopada 2026 roku w oficjalnym repozytorium WooCommerce Stripe Gateway na GitHubie, pod numerem #6177. Autor przedstawił szczegółową analizę sześciu subskrypcji dotkniętych błędem w jednym sklepie. W dwóch przypadkach przeprowadzono dokładną diagnostykę i potwierdzono ten sam mechanizm nieprawidłowego działania.

Przyczyną jest konflikt identyfikatorów klientów Stripe zapisywanych przez dwa różne rozszerzenia płatnicze: WooPayments oraz WooCommerce Stripe Gateway. Gdy integracje korzystają z odrębnych kont Stripe, nieprawidłowe powiązanie danych może spowodować, że system próbuje pobrać pieniądze, wykorzystując identyfikator klienta pochodzący z niewłaściwego konta operatora.

W rezultacie Stripe odrzuca transakcję, a sklep nie otrzymuje kolejnej płatności subskrypcyjnej. Problem ma szczególne znaczenie dla sklepów oferujących abonamenty, cykliczne dostawy produktów, dostęp do usług online oraz inne rozwiązania wymagające regularnego pobierania należności.

Dokładny komunikat błędu WooCommerce Stripe

W zgłoszonym przypadku kolejne automatyczne odnowienie subskrypcji kończy się odpowiedzią Stripe:

No such customer: 'cus_xxx'

Identyfikatory klientów Stripe rozpoczynają się od prefiksu cus_. Każdy identyfikator odnosi się do konkretnego rekordu klienta w określonym koncie Stripe.

Komunikat „No such customer” oznacza, że w kontekście konta obsługującego żądanie Stripe nie może odnaleźć wskazanego identyfikatora klienta.

Nie zawsze oznacza to, że konto kupującego zostało usunięte z WooCommerce lub że klient nie istnieje w systemie płatniczym. Przyczyną może być próba wykorzystania identyfikatora pochodzącego z innego konta Stripe.

To właśnie taki przypadek został opisany w zgłoszeniu #6177.

Jak dochodzi do błędu podczas migracji z WooPayments do Stripe Gateway?

Problem pojawia się wtedy, gdy sklep korzysta równocześnie z WooPayments i WooCommerce Stripe Gateway, a każda wtyczka jest połączona z innym kontem Stripe.

Oba rozszerzenia wykorzystują część podobnych identyfikatorów i metadanych zamówień. Nie oznacza to jednak, że identyfikatory klientów są wymienne pomiędzy różnymi kontami operatora.

W zgłoszonym scenariuszu klient posiada subskrypcję utworzoną wcześniej przez WooPayments. Następnie, po nieudanej próbie automatycznego pobrania należności, opłaca zaległe zamówienie za pomocą metody SEPA Direct Debit obsługiwanej przez oddzielną wtyczkę Stripe Gateway.

Ręczna płatność zostaje zaakceptowana, ale dane zapisane w subskrypcji pozostają niespójne.

Przebieg problemu krok po kroku

1. Klient kupuje produkt subskrypcyjny i płaci kartą przez WooPayments.
2. WooPayments tworzy powiązanie z klientem Stripe i zapisuje identyfikator cus_A, należący do konta wykorzystywanego przez WooPayments.
3. Podczas kolejnego odnowienia subskrypcji płatność nie dochodzi do skutku, na przykład z powodu wygaśnięcia karty albo odmowy autoryzacji.
4. WooPayments odtwarza dane zapisanej metody płatności i zapisuje identyfikator cus_A w metadanych subskrypcji.
5. Klient otrzymuje możliwość ponownego opłacenia zaległego zamówienia.
6. Tym razem wybiera SEPA Direct Debit, obsługiwane przez osobne rozszerzenie WooCommerce Stripe Gateway.
7. Stripe Gateway przetwarza płatność na swoim koncie Stripe, wykorzystując prawidłowy identyfikator klienta cus_B.
8. Płatność zostaje zaakceptowana, a w subskrypcji zapisywany jest identyfikator nowej metody płatności.
9. W polu identyfikatora klienta subskrypcji nadal pozostaje wcześniejsza wartość cus_A, pochodząca z WooPayments.
10. Przy następnym automatycznym odnowieniu WooCommerce Stripe Gateway próbuje wykorzystać metodę płatności należącą do swojego konta Stripe wraz z identyfikatorem klienta z konta WooPayments.
11. Stripe odrzuca transakcję, zwracając komunikat No such customer.

Najbardziej problematyczne jest to, że jednorazowe opłacenie zaległego zamówienia nie usuwa przyczyny błędu. Klient może ponownie zapłacić ręcznie, lecz następne automatyczne odnowienie może zakończyć się identycznym niepowodzeniem.

Dlaczego dwa konta Stripe powodują konflikt identyfikatorów?

WooPayments oraz oficjalne rozszerzenie WooCommerce Stripe Gateway mogą wykorzystywać infrastrukturę Stripe, ale nie muszą korzystać z tego samego konta sprzedawcy.

Jeżeli sklep ma dwa odrębne połączenia, identyfikatory klientów utworzone w jednym koncie nie mogą być automatycznie traktowane jako prawidłowe identyfikatory w drugim.

Jeżeli WooCommerce podczas odnawiania subskrypcji przekaże do konta B identyfikator klienta cus_A, Stripe nie odnajdzie odpowiedniego rekordu.

Nie jest to problem z wysokością płatności, samym numerem konta bankowego ani terminem odnowienia. Wynika z nieprawidłowego powiązania informacji identyfikujących klienta i jego metodę płatności.

Techniczna przyczyna błędu: _stripe_customer_id i _stripe_source_id

Analiza zgłoszenia wskazuje na sposób zapisywania metadanych subskrypcji.

Oba rozszerzenia mogą korzystać z pola:

_stripe_customer_id

W tym polu zapisywany jest identyfikator klienta Stripe.

Z kolei WooCommerce Stripe Gateway wykorzystuje również pole:

_stripe_source_id

Może ono zawierać identyfikator metody płatności, na przykład rozpoczynający się od pm_.

W prawidłowo skonfigurowanej subskrypcji identyfikator klienta oraz identyfikator metody płatności powinny odnosić się do właściwego konta Stripe.

Co dokładnie zostaje zapisane nieprawidłowo?

Według autora zgłoszenia po ręcznym opłaceniu zaległego zamówienia rozszerzenie Stripe Gateway aktualizuje identyfikator metody płatności:

_stripe_source_id = pm_...

Jednak nie zastępuje wcześniejszego identyfikatora klienta:

_stripe_customer_id = cus_A

W efekcie powstaje niespójność. Subskrypcja wskazuje metodę płatności należącą do nowego konta Stripe, ale nadal zawiera identyfikator klienta z poprzedniego konta.

Podczas kolejnego automatycznego odnowienia te dane są przekazywane do Stripe, który odrzuca operację.

Dlaczego ręczna płatność może być udana?

Podczas ręcznego opłacania zaległego zamówienia rozszerzenie Stripe Gateway może wykorzystać prawidłowy identyfikator klienta zapisany w danych użytkownika WordPressa.

W zgłoszonym przypadku był to identyfikator cus_B, należący do konta obsługiwanego przez Stripe Gateway.

Ręczna operacja zakończyła się sukcesem, ponieważ zamówienie odnowieniowe nie zawierało jeszcze błędnego identyfikatora klienta w swoich metadanych.

Problem pojawił się dopiero przy następnej automatycznej płatności, kiedy zamówienie odnowieniowe odziedziczyło niespójne dane zapisane w subskrypcji.

Które wersje WooCommerce i Stripe są dotknięte problemem?

Autor zgłoszenia podał następującą konfigurację środowiska:

W zgłoszeniu nie wskazano dokładnej wersji podstawowej wtyczki WooCommerce ani wersji PHP.

Nie przedstawiono również dowodów, że wszystkie instalacje Stripe Gateway 11.1.1 są dotknięte problemem.

Kluczowym warunkiem jest szczególna konfiguracja integracji oraz przejście subskrypcji pomiędzy metodami płatniczymi powiązanymi z różnymi kontami Stripe.

Włączenie HPOS zostało odnotowane w środowisku zgłaszającego, lecz nie wykazano, że sam HPOS jest przyczyną nieprawidłowego przypisania identyfikatorów.

Ile subskrypcji zostało dotkniętych błędem?

Autor zgłoszenia poinformował, że problem zaobserwowano w sześciu subskrypcjach w jednym sklepie internetowym.

Dwie z nich przeanalizowano szczegółowo. W obu przypadkach potwierdzono ten sam przebieg: nieudane odnowienie przez WooPayments, ręczna zapłata przez Stripe Gateway oraz błąd kolejnego automatycznego pobrania należności.

Nie przedstawiono jednak danych statystycznych pozwalających ocenić skalę problemu w innych sklepach WooCommerce.

Nie można zatem uznać, że błąd występuje we wszystkich sklepach korzystających z płatności subskrypcyjnych albo że jest powszechną awarią Stripe.

Jakie konsekwencje może mieć błąd dla sprzedaży subskrypcyjnej?

Brak wpływów z automatycznych odnowień

Najważniejszym skutkiem jest niemożność pobrania kolejnej należności od klienta, mimo że wcześniej prawidłowo opłacił zaległe zamówienie.

Jeżeli sklep sprzedaje usługi abonamentowe, dostęp do materiałów cyfrowych lub cykliczne dostawy produktów, problem może bezpośrednio wpływać na przychody.

W przypadku większej liczby subskrypcji nierozpoznana przyczyna może prowadzić do powtarzających się nieudanych odnowień.

Powtarzające się płatności ręczne

Klient może otrzymywać kolejne powiadomienia o nieudanej płatności i samodzielnie opłacać zaległe zamówienia.

Nie naprawia to jednak błędnego przypisania identyfikatora klienta w subskrypcji.

W efekcie problem może powracać przy każdym kolejnym terminie automatycznego odnowienia.

Ryzyko zawieszenia subskrypcji

WooCommerce Subscriptions może reagować na nieudane płatności zgodnie z ustawieniami ponawiania i obsługi odnowień.

W zależności od konfiguracji sklepu brak zapłaty może prowadzić do zmiany stanu subskrypcji lub ograniczenia dostępu do opłacanej usługi.

Warto sprawdzić oficjalną dokumentację ustawień WooCommerce Subscriptions, ponieważ skutki nieudanego odnowienia zależą od zastosowanych mechanizmów.

Nieprawidłowe dane w systemach zewnętrznych

Jeżeli subskrypcje są połączone z systemem księgowym, ERP albo narzędziem automatycznej obsługi zamówień, powtarzające się nieudane odnowienia mogą prowadzić do dodatkowych rozbieżności.

Znaczenie spójnej obsługi zamówień i integracji z zapleczem sprzedażowym opisano również w artykule realizacja zamówień w sklepie internetowym i zarządzanie procesami operacyjnymi.

Jak sprawdzić, czy subskrypcje WooCommerce mają błędne identyfikatory Stripe?

Diagnostykę należy rozpocząć od zebrania informacji o nieudanych odnowieniach oraz porównania zapisanych identyfikatorów z rzeczywistymi danymi operatora płatności.

1. Sprawdź historię nieudanych odnowień

W panelu WordPressa przejdź do WooCommerce → Subscriptions, jeżeli rozszerzenie udostępnia tę pozycję menu, albo otwórz odpowiedni ekran subskrypcji w panelu WooCommerce.

Odszukaj subskrypcje, przy których występowały nieudane automatyczne płatności.

Sprawdź historię powiązanych zamówień oraz metodę płatności wykorzystywaną przy pierwotnym zakupie.

Szczególną uwagę zwróć na przypadki, w których klient zmienił operatora płatności z WooPayments na Stripe Gateway.

2. Sprawdź logi Stripe

W panelu WooCommerce otwórz WooCommerce → Status → Logi.

Wybierz logi związane ze Stripe Gateway, jeżeli rejestrowanie zdarzeń było wcześniej włączone.

Poszukaj komunikatu:

No such customer

Następnie ustal, którego zamówienia odnowieniowego dotyczy błąd.

Warto również sprawdzić dziennik żądań API w panelu Stripe. Operator udostępnia informacje o żądaniach zakończonych niepowodzeniem oraz odpowiednich kodach błędów.

Więcej informacji o klasyfikacji i obsłudze błędów znajduje się w dokumentacji kodów błędów Stripe.

3. Porównaj identyfikatory klientów

W metadanych problematycznej subskrypcji sprawdź:

_stripe_customer_id
_stripe_source_id

Jeżeli sklep korzysta także z WooPayments, należy zweryfikować odpowiednie identyfikatory tego rozszerzenia:

_wcpay_customer_id_live
_wcpay_customer_id_test

Nie należy jednak zakładać, że każda instalacja przechowuje wszystkie te wartości w identycznym miejscu.

W przypadku WooCommerce wykorzystującego HPOS dostęp do odpowiednich metadanych należy uzyskać przez zgodne z WooCommerce mechanizmy odczytu zamówień i subskrypcji.

Nie zaleca się wykonywania przypadkowych zapytań i zmian bezpośrednio w tabelach bazy danych.

4. Sprawdź, do którego konta Stripe należy identyfikator

Jeżeli w sklepie używane są dwa konta Stripe, trzeba ustalić, czy identyfikator klienta zapisany w subskrypcji należy do konta używanego przez aktualną metodę płatności.

Przykładowo nieprawidłowa konfiguracja może wyglądać następująco:

Payment gateway: Stripe Gateway
Stripe account: B
Customer ID: cus_A
Payment method: pm_B

W takiej sytuacji identyfikator klienta pochodzi z konta A, natomiast metoda płatności została utworzona na koncie B.

To niespójność wymagająca wyjaśnienia przed kolejną próbą pobrania należności.

Dlaczego nie należy automatycznie ponawiać wszystkich nieudanych płatności?

Jeżeli WooCommerce pokazuje nieopłacone zamówienie, nie oznacza to jeszcze, że pieniądze nie zostały pobrane przez operatora.

W przypadku błędu „No such customer” Stripe odrzuca konkretną próbę wykorzystania nieprawidłowego identyfikatora. Jednak w historii tego samego klienta mogą istnieć inne, prawidłowo zakończone płatności.

Przed ponowieniem obciążenia należy ustalić rzeczywisty stan każdej transakcji.

Szczególnie ważne jest odróżnienie nieudanego automatycznego odnowienia od ręcznej płatności, która mogła już zakończyć się sukcesem.

Podobne problemy z interpretacją statusów zamówień opisano w artykule klient zapłacił, a WooCommerce nadal pokazuje „Oczekuje na płatność” – diagnostyka i zapobieganie podwójnemu pobraniu pieniędzy.

Najważniejsza zasada polega na porównaniu danych zamówienia z rzeczywistą historią transakcji w panelu operatora.

Jak bezpiecznie naprawić błąd „No such customer”?

Autor zgłoszenia opracował obejście wykorzystujące mechanizmy zapisu zamówień i subskrypcji WooCommerce.

Rozwiązanie polega na sprawdzaniu identyfikatora klienta przed zapisaniem danych.

Jeżeli subskrypcja korzysta z metody płatności Stripe Gateway, a zapisany identyfikator klienta odpowiada identyfikatorowi z konta WooPayments, mechanizm zastępuje go prawidłową wartością przypisaną do konta używanego przez Stripe Gateway.

W przypadku braku prawidłowego identyfikatora pochodzącego z właściwego konta nie należy przypisywać przypadkowej wartości.

Mechanizmy wykorzystane w obejściu

Autor zastosował następujące hooki WooCommerce:

woocommerce_before_order_object_save
woocommerce_before_subscription_object_save

Pozwalają one wykonać dodatkową kontrolę danych przed zapisaniem odpowiedniego obiektu.

W opisanym rozwiązaniu weryfikowane są między innymi:

• aktualna metoda płatności subskrypcji;
• identyfikator klienta Stripe zapisany w subskrypcji;
• identyfikator klienta pochodzący z WooPayments;
• identyfikator zapisany dla właściwego konta Stripe Gateway.

Jeżeli wykryta zostanie niezgodność, system koryguje zapisane powiązanie przed kolejnym automatycznym odnowieniem.

Czy można ręcznie zmienić _stripe_customer_id?

Technicznie możliwe jest skorygowanie danych subskrypcji, ale wymaga to szczególnej ostrożności.

Nieprawidłowa zmiana identyfikatora może spowodować kolejne nieudane płatności albo powiązanie subskrypcji z niewłaściwym rekordem klienta.

Przed ingerencją należy potwierdzić, że identyfikator rzeczywiście należy do właściwego konta Stripe i odpowiada metodzie płatności zapisanej w subskrypcji.

Nie należy przenosić identyfikatorów pomiędzy środowiskiem testowym i produkcyjnym ani kopiować ich pomiędzy niezależnymi kontami operatora.

Zmiany powinny zostać wykonane po utworzeniu kopii zapasowej i przetestowaniu sposobu działania na środowisku stagingowym.

Czy samodzielna zmiana metody płatności przez klienta rozwiązuje problem?

Nie zawsze.

W udokumentowanym przypadku klient mógł samodzielnie opłacić zaległe zamówienie za pomocą nowej metody płatności.

Problem polegał jednak na tym, że zmiana metody nie powodowała prawidłowej aktualizacji wszystkich danych identyfikujących klienta Stripe.

W rezultacie kolejny automatyczny cykl rozliczeniowy ponownie kończył się niepowodzeniem.

To ważna różnica pomiędzy zwykłą odmową płatności a błędem integracji.

Przy standardowej odmowie klient może często rozwiązać problem poprzez zmianę karty albo innego instrumentu płatniczego.

Jeżeli przyczyną jest nieprawidłowe powiązanie identyfikatora klienta z kontem operatora, sama zmiana metody płatności może nie wystarczyć.

Czy podobne błędy występują również w PayPal Payments?

Problemy z identyfikatorami i stanem płatności nie ograniczają się wyłącznie do Stripe.

W WooCommerce PayPal Payments 4.2.0 opisano odrębny przypadek, w którym po przerwaniu płatności u jednego operatora i ponowieniu jej przez PayPal sklep może zwrócić wynik sugerujący sukces, mimo że PayPal nie przechwycił pieniędzy.

W obu sytuacjach źródłem problemu jest nieprawidłowe wykorzystanie danych pozostawionych przez wcześniejszą bramkę płatniczą.

Szczegóły tamtego błędu przedstawia artykuł WooCommerce PayPal Payments 4.2.0 – błąd potwierdzania zamówień bez pobrania płatności.

Nie oznacza to jednak, że oba problemy mają identyczną przyczynę techniczną.

W przypadku Stripe chodzi o nieprawidłowy identyfikator klienta podczas automatycznego odnawiania subskrypcji. W przypadku PayPal problem dotyczy błędnego potraktowania istniejącego identyfikatora transakcji jako powodu do pominięcia nowej płatności.

Jak zapobiegać problemom z płatnościami podczas migracji pomiędzy operatorami?

Migracja pomiędzy bramkami płatniczymi wymaga więcej niż wyłączenia jednej wtyczki i aktywowania drugiej.

Szczególnie w sklepach subskrypcyjnych trzeba uwzględnić dane zapisanych metod płatności, identyfikatory klientów, harmonogramy automatycznych odnowień oraz zasady obsługi transakcji wykonywanych bez udziału klienta.

Sprawdź pochodzenie identyfikatorów klientów

Jeżeli sklep korzysta z kilku kont Stripe, każda integracja powinna wykorzystywać identyfikatory należące do właściwego konta.

Przed migracją warto ustalić, które metadane są zapisywane przez WooPayments, a które przez Stripe Gateway.

Przetestuj nie tylko pierwszą płatność

Pomyślne opłacenie nowej subskrypcji nie gwarantuje prawidłowego działania kolejnych odnowień.

Test powinien obejmować także nieudaną płatność, zmianę metody płatniczej, ręczne opłacenie zaległego zamówienia oraz następną automatyczną próbę pobrania należności.

Monitoruj zamówienia odnowieniowe

Warto regularnie kontrolować liczbę nieudanych automatycznych odnowień i analizować ich przyczyny.

Jeżeli po migracji operatora nagle rośnie liczba błędów „No such customer”, należy sprawdzić zgodność identyfikatorów zamiast automatycznie przypisywać wszystkie odmowy problemom z kartami klientów.

Zachowaj kopie danych przed zmianami

Przy migracji rozliczeń subskrypcyjnych szczególne znaczenie ma zachowanie spójności danych zamówień i subskrypcji.

Kopia zapasowa powinna obejmować bazę danych WooCommerce oraz odpowiednią konfigurację wtyczek płatniczych.

Nie należy jednak kopiować danych produkcyjnych metod płatności do nieodpowiednio zabezpieczonych środowisk testowych.

Dlaczego poprawne odnawianie subskrypcji jest ważne dla sklepu?

Model abonamentowy opiera się na regularnym pobieraniu należności bez konieczności każdorazowego przechodzenia przez pełną procedurę zakupową.

Jeżeli automatyczne odnowienia przestają działać, sprzedawca może tracić przewidywalne przychody, a klienci mogą doświadczać przerw w dostępie do usług.

Dlatego sklep internetowy oferujący produkty subskrypcyjne powinien regularnie kontrolować nie tylko pierwsze transakcje, ale również wszystkie kolejne cykle rozliczeniowe.

Ważne jest porównywanie stanu subskrypcji w WooCommerce z rzeczywistymi płatnościami operatora, a także monitorowanie błędów po zmianach integracji.

W przypadku bardziej rozbudowanych instalacji warto również zadbać o odpowiednie testy po aktualizacjach WooCommerce, Subscriptions i rozszerzeń płatniczych.

Czy producent potwierdził już oficjalną poprawkę?

Według stanu publicznego zgłoszenia z 8 listopada 2026 roku problem pozostaje otwarty.

Autor przedstawił szczegółowy scenariusz odtworzenia oraz własne obejście polegające na korygowaniu identyfikatora klienta przed zapisaniem danych subskrypcji.

Nie potwierdzono jednak opublikowania oficjalnej poprawki WooCommerce Stripe Gateway ani wydania, które jednoznacznie eliminuje ten problem.

Zgłoszenie nie zawiera również informacji o zakończonym przeglądzie kodu i zaakceptowanej zmianie producenta.

Opis problemu, konfiguracja środowiska oraz dalsze ustalenia są dostępne w zgłoszeniu WooCommerce Stripe Gateway #6177.

Najczęściej zadawane pytania dotyczące błędu „No such customer”

Co oznacza błąd No such customer w Stripe?

Oznacza, że Stripe nie może odnaleźć wskazanego identyfikatora klienta w kontekście konta obsługującego żądanie. W opisywanym przypadku przyczyną jest wykorzystanie identyfikatora pochodzącego z innego konta Stripe.

Czy problem dotyczy wszystkich sklepów WooCommerce?

Nie. Zgłoszenie dotyczy określonej konfiguracji z WooPayments, Stripe Gateway i WooCommerce Subscriptions, w której płatności są przenoszone pomiędzy odrębnymi kontami operatora.

Czy problem może wystąpić po migracji z WooPayments?

Tak. To właśnie taki scenariusz został opisany przez autora zgłoszenia. Szczególnie istotna jest zmiana metody płatności aktywnej subskrypcji po wcześniejszej nieudanej próbie odnowienia.

Dlaczego klient może zapłacić ręcznie, ale nie automatycznie?

Płatność ręczna może wykorzystać prawidłowy identyfikator klienta zapisany w danych użytkownika. Kolejne automatyczne odnowienie może natomiast odczytać nieprawidłowy identyfikator zapisany wcześniej w metadanych subskrypcji.

Czy wystarczy zmienić kartę płatniczą?

Niekoniecznie. Jeżeli problem wynika z nieprawidłowego przypisania identyfikatorów klientów pomiędzy kontami Stripe, sama zmiana karty może nie usunąć przyczyny.

Czy HPOS jest przyczyną błędu?

Nie zostało to potwierdzone. HPOS było włączone w środowisku zgłaszającego, lecz analiza wskazuje na konflikt metadanych wykorzystywanych przez integracje płatnicze.

Czy można ręcznie poprawić identyfikator klienta?

Można skorygować nieprawidłowe powiązania, ale dopiero po ustaleniu, do którego konta Stripe należą identyfikatory klienta i metody płatności. Przypadkowa modyfikacja może spowodować dodatkowe błędy.

Czy WooCommerce opublikowało poprawkę?

Według stanu zgłoszenia z 8 listopada 2026 roku nie potwierdzono oficjalnej poprawki. Dostępne jest obejście opracowane przez autora zgłoszenia.

Podsumowanie: błędny identyfikator Stripe może powodować powtarzające się nieudane odnowienia

Problem zgłoszony w WooCommerce Stripe Gateway #6177 pokazuje, jak istotne jest zachowanie zgodności identyfikatorów klientów i metod płatności podczas migracji pomiędzy operatorami.

W opisanym przypadku klient opłacał zaległą subskrypcję przez Stripe Gateway, ale jej dane nadal zawierały identyfikator klienta należący do konta WooPayments.

Przy kolejnym automatycznym odnowieniu Stripe odrzucał transakcję komunikatem „No such customer”.

Problem zaobserwowano w sześciu subskrypcjach jednego sklepu, a dwie szczegółowo przeanalizowane wykazały identyczny mechanizm błędu.

Do czasu udostępnienia oficjalnej poprawki administratorzy sklepów korzystających z WooPayments i Stripe Gateway powinni zwracać szczególną uwagę na subskrypcje, w których klienci zmieniali metodę płatności.

Najważniejsze jest sprawdzenie, czy identyfikator klienta oraz przypisana metoda płatności należą do właściwego konta Stripe. Bez usunięcia tej niespójności kolejne automatyczne odnowienia mogą nadal kończyć się niepowodzeniem, nawet gdy wcześniejsze płatności ręczne zostały prawidłowo zrealizowane.