Historia awarii Payplug

1. 20 czerwca 2026 10:52 UTCinvestigating

   FR Zidentyfikowaliśmy incydent mający wpływ na wysyłanie powiadomień po płatnościach za pomocą naszych modułów. Incydent jest w trakcie analizy. EN Zidentyfikowaliśmy incydent mający wpływ na dostarczanie powiadomień po płatności dla sprzedawców korzystających z naszych modułów. Incydent jest obecnie przedmiotem dochodzenia.

2. 20 czerwca 2026 13:40 UTCresolved

   TSR-3421 - Początek/ Początek: 19/06/2026 18:00:00 CEST - Zakończenie: 20/06/2026 15:17:00 CEST - Kategoria/ Kategoria: Produkcja/Przetwórstwo - Odpowiedzialność/Odpowiedzialność: Zewnętrzna - Priorytet/Priorytet: P1 FR Incydent, który wpłynął na wysyłanie powiadomień po płatnościach dla rynków korzystających z modułów, został rozwiązany. Usługa była regulowana do 15h17 i działała normalnie. Operacje zostaną podane w celu przeglądania powiadomień, które nie mogą być wysyłane od początku zdarzenia, które pojawią się tutaj o 18:00. EN Incydent mający wpływ na dostarczanie powiadomień po płatnościach dla sprzedawców korzystających z modułów został rozwiązany. Usługa została przywrócona o 15:17 i teraz działa normalnie. Przeprowadzone zostaną operacje w celu powtórzenia powiadomień, których nie można wysłać od początku incydentu, który rozpoczął się wczoraj o 18:00.

3. 26 czerwca 2026 09:27 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-3421 **Usługa objęta** Powiadomienia o płatnościach. **Klient wpływu** Powiadomienia o płatnościach nie są wysyłane do rynków. **Syntezę incydentu** * **19 czerwca 18h: ** wysłanie masywnego wolumenu płatności. * **19 czerwca 18h30: Początek incydentu. ** * **20 czerwca 10h33: ** naprawa alertu o problemie z powiadomieniem. * **20 czerwca 11h46: ** utworzenie uszkodzonej komórki kryzysowej. Początek dochodzeń. * **20 czerwca 11h48: ** Identyfikacja braku zgłoszeń płatniczych. Dlaczego śledztwo. * **20 czerwca 12h50: identyfikacja pierwotnej przyczyny. ** * **20 czerwca 13h02 - 15h15: ** uruchomienie różnych działań korekcyjnych. * **20 czerwca 15h17: koniec incydentu. ** * **20 czerwca 22h32: ** Uruchomienie automatów do odnawiania powiadomień. * **21 czerwca 11h57: ** potwierdzenie zwrotu zgłoszeń. ‌ **Przyczyna korzenia** Nieprawidłowo ustawiony wolumen powiadomień, powiązany z automatycznymi próbami wysyłania na niedostępny adres URL, przesyła plik przetwarzania powiadomień. To nasycenie przez co blokuje wysyłanie powiadomień. **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Brak określonego ostrzeżenia w pliku przetwarzania powiadomień. | Dodaj ostrzeżenie specjalne do wykrywania i zapobiegania całkowitemu nasyceniu pliku przetwarzania. | | Brak limitu żądań płatniczych na rynek | Aktualizacja zamiast limitu na rynek, aby ograniczyć przepływ powiadomień i zapobiec całkowitemu nasyceniu pliku przetwarzania. | | Niedostosowane zarządzanie limitami czasu | Zmiana przekroczenia limitu czasu, aby zapobiec nasyceniu plików przetwarzania powiadomień. | | Opóźnienie w ściganiu odpowiedzialnym za incydent | Rewizja procesu incydentu w nieotwartych godzinach i komunikacji z określonymi zespołami. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-3421 **Usługi płatnicze dotknięte incydentem** Powiadomienia o płatnościach. **Wpływ klienta** Powiadomienia o płatnościach nie były już wysyłane do sprzedawców. **Przegląd incydentów** * **19 czerwca 18:00: ** przetworzono dużą liczbę transakcji płatniczych. * **19 czerwca 18:30: rozpoczął się incydent. ** * **20 czerwca 10:33: ** podniesiony alert dotyczący problemu z powiadomieniem. * **20 czerwca 11:46: ** powołano dedykowany zespół zarządzania kryzysowego. Rozpoczęły się dochodzenia. * **20 czerwca 11:48: ** stwierdzono brak wysłania powiadomień o płatnościach. Dochodzenia trwały. * **20 czerwca 12:50: zidentyfikowano pierwotną przyczynę. ** * **20 czerwca 13:02 — 15:15: ** wdrożono różne działania naprawcze. * **20 czerwca 15:17: incydent rozwiązany. ** * **20 czerwca 22:32: ** uruchomiono zautomatyzowane procesy ponownego wysyłania powiadomień. * **21 czerwca 11:57: ** potwierdzenie, że wszystkie powiadomienia zostały ponownie wysłane. ‌ **Przyczyna korzenia** Nienormalnie duża liczba nieudanych powiadomień w połączeniu z automatycznymi próbami ponownej próby niedostępnego adresu URL nasycała kolejkę przetwarzania powiadomień. W rezultacie nasycenie uniemożliwiło wysyłanie powiadomień o płatnościach. **Działania do podjęcia przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | W kolejce przetwarzania powiadomień nie wprowadzono konkretnego ostrzegania. | Wprowadzono specjalne alerty w celu wykrycia i proaktywnego przewidywania nasycenia kolejki przetwarzania. | | Nie obowiązywał limitu na sprzedawcę w przypadku składania wniosków o płatność. | Wdrożono limit na sprzedawcę, aby kontrolować ruch powiadomień i zapobiec nasyceniu kolejki przetwarzania. | | Niewłaściwe ustawienia limitu czasu | Trwa przegląd progów limitu czasu, aby zapobiec nasyceniu kolejek przetwarzania powiadomień. | | Opóźnienie w reagowaniu na incydenty. | Procedura zarządzania incydentami poza godzinami pracy jest obecnie poddawana przeglądowi i zostanie przekazana odpowiednim zespołom. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 czerwca 2026 10:24 UTCinvestigating

   FR Dzisiejsze zwroty z 13, 14 i 15 czerwca nie mogły być odwrócone w ich integralności. Nasze zespoły są w pełni zmobilizowane, aby naprawić sytuację w najlepszych czasach i przywrócić normalną procedurę zwrotów. Jesteśmy poinformowani o ewolucji sytuacji, w której dostępne są nowe informacje. EN Rozliczenia dotyczące 13, 14 i 15 czerwca, które zostały zaplanowane na dziś, nie mogły zostać rozpatrzone w całości. Nasze zespoły są w pełni zmobilizowane, aby jak najszybciej rozwiązać sytuację i przywrócić normalne przetwarzanie rozliczeń. Będziemy Cię informować o wszelkich wydarzeniach, gdy tylko będą dostępne dalsze informacje. TO Przesłanki z 13, 14 i 15 czerwca na dziś nie mogły być całkowicie zrealizowane. Nasz zespół zdecydowanie powstrzymuje się, aby rozwiązać sytuację w możliwie krótszym czasie i przywrócić normalny proces zbierania funduszy. Poinformujemy Cię o tym, że nowe informacje będą dostępne w niedalekiej sytuacji.

2. 16 czerwca 2026 08:58 UTCmonitoring

   TSR-3389 - Początek/Początek/Początek: 16/06/2026 - Fin/Koniec /dobra: 17/06/2026 - Kategoria/Kategoria/Kategoria: Odwrócenie produkcyjne/ rozliczenia/wersamento - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Payplug - Priorytet/Priorytet/Priorytet: P2. FR Pozostałe fundusze nie mogą być tutaj odwrócone, będą dziś dostępne. Twoja część nie jest wymagana żadna akcja, a tapety będą dostępne na Twoich kontach jak zwykle. EN Pozostałe środki, które nie mogły zostać rozliczone wczoraj, zostaną rozliczone dzisiaj. Z Twojej strony nie są wymagane żadne działania, a środki będą dostępne na Twoich kontach jak zwykle. TO Podstawowe fundusze, które nie mogły zostać wydane wczoraj, zostaną dziś akredytowane. Nie żądasz żadnych działań ze swojej strony, a fundusze będą dostępne na Twoich kontach jako konsumpcja.

3. 16 czerwca 2026 09:17 UTCresolved

   Ten incydent został rozwiązany.

4. 16 czerwca 2026 13:27 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-3389 **Usługa objęta** Odwrócenie transakcji. **Klient wpływu** Niemożność przeprowadzenia odwrócenia integralności transakcji w czasie trwania zdarzenia, powodując opóźnienie regulacji transakcji. ‌ **Syntezę incydentu** * **15 czerwca 10h10: ** naprawy ostrzeżeń wskazujących, że niektóre marchandy nie mają żadnych funduszy. **Początek incydentu** i początek pierwszych analiz. * **15 czerwca 10h36: ** utworzenie uszkodzonej komórki kryzysowej. * **15 czerwca 10h37: ** Identyfikacja problemu generowania pewnych żądań żywiołowych. * **15 czerwca 10h52: ** identyfikacja drugiego incydentu wpływającego na walidację wirementów. * **15 czerwca 11h11: ** rozwiązanie zdarzenia mającego wpływ na walidację zmian. * **15 czerwca 11h14: ** poproś o weryfikację transakcji weekendowych i przeprowadzenie dochodzeń dotyczących błędu generowania niektórych żądań zwrotnych. * **15 czerwca 11h34: ** weryfikacja weekendowych wniosków i śledztwa w celu umożliwienia wysłania funduszy, które pozwolą na usunięcie limitu. * **15 czerwca 11h55: Identyfikacja pochodzenia incydentu. ** * **15 czerwca o godz. 12h22: ** opracowanie planu działania, aby umożliwić wysłanie funduszy bez obciążenia. * **15 czerwca 15h: ** uruchomienie korygujących działań pod nadzorem drużyn. * **15 czerwca 17h10: ** zakończenie działań korekcyjnych. **Koniec incydentu. ** * **16 czerwca o godz. 7h30**: brak ostrzeżenia wskazującego na błędy. * **16 czerwca 9h30: ** weryfikacja dobrej generacji żądań wirowych. * **16 czerwca 10h57: ** kontrolowanie zmian zespołów technicznych. * **16 czerwca 10h59: ** Różne kontrakty potwierdzają odwrócenie zebrania tablic. **Przyczyna korzenia** Błąd podczas dezaktywacji wyzwalacza spowodował przerwanie generowania plików wirementowych i spowodował odwrócenie niektórych funduszy. ‌ **Akcje przyznane przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Brak specyficznego ostrzeżenia o braku generowania pliku. | Dodaj ostrzeżenie w celu wykrycia błędów braku generowania pliku i zapobiegania incydentowi odwrócenia. | | Brak specyficznego ostrzeżenia na osłonie wyzwalacza. | Przeprowadzane są zgięcia w celu dodania ostrzeżeń, które powodują naprawę ostrzeżeń do wyzwalacza. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-3389 **Usługi płatnicze dotknięte incydentem** Rozliczenie transakcji **Wpływ klienta** Niemożność rozliczenia wszystkich transakcji podczas incydentu, co skutkuje opóźnieniem rozliczeń handlowych. ‌ **Przegląd incydentów** * **15 czerwca 10:10: ** podniesiono alerty wskazujące, że niektórzy kupcy nie otrzymali środków. **Początek incydentu** i rozpoczęcie wstępnych dochodzeń. * **15 czerwca 10:36: ** powołano dedykowany zespół zarządzania kryzysowego. * **15 czerwca 10:37: ** zidentyfikowano problem mający wpływ na generowanie niektórych wniosków o przelew bankowy. * **15 czerwca 10:52: ** zidentyfikowano drugi incydent mający wpływ na walidację transferu. * **15 czerwca 11:11: ** incydent mający wpływ na walidację transferu został rozwiązany. * **15 czerwca 11:14: ** złożono wniosek o walidację przelewów zawierających transakcje weekendowe, podczas gdy dochodzenia w sprawie błędu wpływającego na generowanie niektórych wniosków o przeniesienie nadal trwały. * **15 czerwca 11:34: ** zatwierdzone transfery weekendowe. Kontynuowano dochodzenia, aby umożliwić wysłanie brakujących środków następnego dnia ze względu na przekroczenie terminu granicznego. * **15 czerwca 11:55: ** **zidentyfikowano główną przyczynę incydentu. ** * **15 czerwca 12:22: ** opracowano plan działania, który umożliwi wysłanie brakujących środków następnego dnia. * **15 czerwca 15:00: ** działania naprawcze realizowane pod nadzorem zespołu. * **15 czerwca 17:10: ** zakończone działania naprawcze. ** Incydent rozwiązany. ** * **16 czerwca 7:30: ** brak alertów wskazujących na jakiekolwiek błędy. * **16 czerwca 9:30: ** weryfikacja prawidłowego generowania żądań transferu. * **16 czerwca 10:57: ** transfery sprawdzane przez zespoły techniczne. * **16 czerwca 10:59: ** wszystkie czeki potwierdziły, że wszystkie środki zostały pomyślnie rozliczone. **Przyczyna korzenia** Błąd w wyzwalaniu harmonogramu zadań przerwał generowanie plików przelewów bankowych, uniemożliwiając rozliczenie niektórych środków. ‌ **Działania podjęte przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | Nie wprowadzono specjalnego alertu, który mógłby wykryć niepowodzenie w generowaniu pliku. | Dodano alert w celu wykrycia błędów generowania plików i proaktywnej identyfikacji potencjalnych incydentów rozliczeniowych. | | Nie wprowadzono specjalnego alertu w celu wykrycia awarii harmonogramu zadań. | Trwają dyskusje dotyczące wdrożenia alertów zdolnych do zgłaszania błędów w harmonogramie zadań. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 7 czerwca 2026 04:43 UTCinvestigating

   FR Zidentyfikowaliśmy problemy z płatnościami online i w sklepach. Incydent jest w trakcie analizy. EN Zidentyfikowaliśmy problemy wpływające na płatności online i w sklepie. Trwa śledztwo. TO Zidentyfikowaliśmy trudności związane z płatnościami online i punktami sprzedaży. Incydent jest w fazie analizy.

2. 7 czerwca 2026 05:05 UTCinvestigating

   FR Zidentyfikowaliśmy problemy na platformie płatniczej. Po analizie urządzenie, którego zdarzenie jest zewnętrzne na naszej platformie. Jesteśmy poinformowani o ewolucji, ponieważ nowe informacje będą dostępne. EN Zidentyfikowaliśmy problemy na platformie płatniczej. Po analizie okazuje się, że incydent jest poza naszą platformą. Będziemy Cię informować o wszelkich wydarzeniach, gdy tylko będą dostępne dalsze informacje. TO Zidentyfikowaliśmy trudności na platformie płatniczej. Po analizie okazuje się, że incydent jest na zewnątrz naszej platformy. Zaktualizujemy, że nowe informacje nie będą już dostępne.

3. 7 czerwca 2026 05:28 UTCresolved

   TSR-XXXX - Początek/ Rozpoczęcie: 07/06/2026 06:15:00 CEST - Zakończenie: 07/06/2026 06:58:00 CEST - Kategoria/ Kategoria: Produkcja/Przetwórstwo - Odpowiedzialność/Odpowiedzialność: Zewnętrzna - Priorytet/Priorytet: P1 FR Incydent jest teraz rozwiązany, a usługa jest naprawiona. Nadal obserwujemy powtórkę usługi. EN Incydent został rozwiązany, a usługa przywrócona. Odzyskiwanie usług jest nadal monitorowane.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 7 maja 2026 09:00 UTCmonitoring

   FR Zidentyfikowaliśmy trudności w płatnościach online i w sklepach między 9h58 a 10h12. Incydent jest teraz rozwiązany, a usługa jest naprawiona. Nadal obserwujemy powtórkę usługi. EN Zidentyfikowaliśmy problemy dotyczące płatności online i w sklepie od 9:58 do 10:12. Incydent został rozwiązany, a usługa przywrócona. Odzyskiwanie usług jest nadal monitorowane. TO Zidentyfikowaliśmy trudności związane z płatnościami online i punktami sprzedaży między 9:58 a 10:12. Incydent został rozwiązany, a usługa została przywrócona. Nadal monitorujemy odzyskiwanie usługi.

2. 7 maja 2026 14:15 UTCresolved

   Ten incydent został rozwiązany.

3. 15 maja 2026 13:32 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-3279 **Usługa objęta** Płatności e-commerce, 3DS i sklepy. **Klient wpływu** Niemożność dokonywania płatności przez portatorów. **Syntezę incydentu** * **7 maja 9h58: ** **Początek incydentu. ** * **7 maja 9h59: ** naprawa alertów. Rozpoczęcie śledztwa. * **7 maja 10h03: ** utworzenie wykrytej komórki kryzysowej i przeprowadzenie badań. * **7 maja 10h09: Identyfikacja pochodzenia incydentu. ** * **7 maja 10h10: ** rozpoczęcie działań korekcyjnych. * **7 maja 10h12: koniec incydentu. ** ‌ **Przyczyna korzenia** Aktualizacja komponentu technicznego aktywowała opcję bezpieczeństwa, która spowodowała zmianę połączenia serwerów również z bazy danych. Serwery mogą być przesunięte przed bazą danych, nie mogą nazywać ustawień rynków prezentowanych w tej bazie danych, co spowodowało wystąpienie płatności. **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Automatyczne odtwarzanie serwerów zgodnych z aktualizacją tego składnika technicznego. | Wyłączenie automatycznego odtwarzania wiąże się ze specyficznym składem technicznym. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-3279 **Usługi płatnicze dotknięte incydentem** Handel elektroniczny, 3DS i płatności w sklepie. **Wpływ klienta** Posiadacze kart nie mogli dokonywać płatności. **Przegląd incydentów** * **7 maja 9:58: początek incydentu. ** * **7 maja 9:59: ** podniesiony alert. Rozpoczęto dochodzenie. * **7 maja 10:03: ** utworzono dedykowaną komórkę kryzysową i kontynuowano dochodzenia. * **7 maja 10:09: zidentyfikowano pierwotną przyczynę. ** * **7 maja 10:10: ** rozpoczęto działania naprawcze. * **7 maja 10:12: ** **koniec incydentu. ** ‌ **Przyczyna korzenia** Aktualizacja komponentu technicznego umożliwiła opcję zabezpieczeń, która spowodowała ponowne uruchomienie wszystkich serwerów, a także bazy danych. Ponieważ serwery zostały ponownie uruchomione przed bazą danych, nie były w stanie odzyskać konfiguracji sprzedawców przechowywanych w bazie danych, co spowodowało awarie płatności. **Działania do podjęcia przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | Automatyczne ponowne uruchomienie serwera po aktualizacji tego komponentu technicznego. | Wyłączenie automatycznego ponownego uruchamiania połączonego z tym konkretnym komponentem technicznym. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 7 kwietnia 2026 09:50 UTCmonitoring

   FR Dokonano zwrotów w dniach 3,4 i 5 kwietnia. Dzisiaj, początkowo od 6 do 7 kwietnia, będą miały miejsce mniej. Twoja część nie wymaga żadnej akcji, a tapety będą dostępne na Twoich kontach jak zwykle. Szczegóły odnośnych zasobów zostaną zaktualizowane dzisiaj. EN Rozliczenia na 3, 4 i 5 kwietnia zostały zakończone. Te na 6 i 7 kwietnia, początkowo zaplanowane na dziś, zostaną przeprowadzone jutro. Z Twojej strony nie są wymagane żadne działania, a środki będą dostępne na Twoich kontach jak zwykle. Szczegóły dotyczące odpowiednich przelewów zostaną udostępnione dzisiaj. TO Zrealizowano zbiory z 3, 4 i 5 kwietnia. Od 6 do 7 kwietnia, początkowo przewidywane do dziś, będą efekty domowe. Nie żądasz żadnych działań ze swojej strony, a fundusze będą dostępne na Twoich kontach jako konsumpcja. Szczegóły odnoszących się do nagród będą dotyczyć dzisiejszego urządzenia.

2. 8 kwietnia 2026 09:05 UTCmonitoring

   FR Fundusze z 6 i 7 kwietnia zostały odwrócone. Dzisiaj, początkowo 8 kwietnia, nastąpi niepowodzenie. Twoja część nie jest wymagana żadna akcja, a tapety będą dostępne na Twoich kontach jak zwykle. EN Środki za 6 i 7 kwietnia zostały rozliczone. Te na 8 kwietnia, początkowo zaplanowane na dziś, zostaną przeprowadzone jutro. Z Twojej strony nie są wymagane żadne działania, a środki będą dostępne na Twoich kontach jak zwykle. TO Fundusze z 6 i 7 kwietnia zostały przeniesione. Te z 8 kwietnia, początkowo przewidywane na dziś, będą wyglądały na długie efekty. Nie żądasz żadnych działań ze swojej strony, a fundusze będą dostępne na Twoich kontach jako konsumpcja.

3. 9 kwietnia 2026 09:16 UTCresolved

   FR Integralność funduszy zostanie odwrócona w ciągu dnia. Szczegóły odnośnych zasobów zostaną zaktualizowane dzisiaj. EN Wszystkie środki zostaną przekazane w ciągu dnia. Szczegóły dotyczące odpowiednich przelewów zostaną udostępnione dzisiaj. TO Całkowita wartość funduszy zostanie przeniesiona w ciągu dnia. Szczegóły odnoszących się do nagród będą dotyczyć dzisiejszego urządzenia.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 marca 2026 10:58 UTCidentified

   TSR-3077 - Początek/ Początek: 16/03/2026 - Fin/Koniec: Na bieżący/w toku - Kategoria/ Kategoria: Wypłaty/Rozliczenia - Odpowiedzialność/Odpowiedzialność: Potwierdzająca/Do potwierdzenia - Priorytet/Priorytet: P1 FR Incydent ma obecnie wpływ na emisję zagrożeń. Dzisiaj pojawiające się zjawiska nie mogły zostać zrealizowane. Nasze zespoły są zmobilizowane, aby naprawić sytuację i jesteśmy poinformowani o tym, że mogą zostać wysłane zmiany. EN Incydent ma obecnie wpływ na wydawanie rozliczeń. Rozliczenia zaplanowane na dziś nie będą mogły zostać przeprowadzone. Nasze zespoły aktywnie pracują nad rozwiązaniem sytuacji, a my będziemy Cię informować, gdy tylko przelewy będą mogły zostać wysłane. TO Incydent obecnie wpływa na emisję wersamentów. Przewidywane dziś nagrody nie mogą być efektowne. Nasz zespół jest zmobilizowany, aby rozwiązać tę sytuację, a my nie tylko informujemy, że nagrody mogą zostać wysłane.

2. 17 marca 2026 08:48 UTCidentified

   TSR-3077 - Początek/ Początek: 16/03/2026 - Fin/Koniec: Na bieżący/w toku - Kategoria/ Kategoria: Wypłaty/Rozliczenia - Odpowiedzialność/Odpowiedzialność: Payplug - Priorytet/Priorytet: P1 FR Działania korekcyjne zostały przeprowadzone w celu śledzenia plików zwrotnych tutaj. Mimo to, problem, który obecnie wiąże się z ich walidacją. Nasze zespoły są zmobilizowane, aby naprawić sytuację w najkrótszym czasie. EN Przeprowadzono działania naprawcze w celu odzyskania wczorajszych plików rozliczeń. Jednak obecnie problem uniemożliwia ich walidację. Nasze zespoły pracują nad jak najszybszym przywróceniem sytuacji. TO Wprowadzono poprawne akcje, aby odzyskać pliki pochodzących z poprzedniego okresu. Niemniej jednak problem obecnie utrudnia ich walidację. Nasz zespół jest zmobilizowany, aby przywrócić sytuację w jak najkrótszym czasie.

3. 17 marca 2026 11:12 UTCmonitoring

   TSR-3077 - Początek/ Początek: 16/03/2026 - Zakończenie/Koniec: Na bieżąco/17/03/2026 - Kategoria/ Kategoria: Wypłaty/Rozliczenia - Odpowiedzialność/Odpowiedzialność: Payplug - Priorytet/Priorytet: P1 FR Zwroty z 16 i 17 marca zostały zweryfikowane. Tapety będą dostępne w ciągu dnia. EN Uliczenia na 16 i 17 marca zostały zatwierdzone. Środki będą dostępne już dziś. TO Wnioski z 16 i 17 marca zostały zweryfikowane. Fundusze będą dostępne w ciągu dnia.

4. 17 marca 2026 13:29 UTCresolved

   Ten incydent został rozwiązany.

5. 27 marca 2026 10:49 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-3077 **Usługa objęta** Odwrócenie opłat w handlu elektronicznym i sklepie. **Klient wpływu** Niemożność przeprowadzenia odwrócenia transakcji w czasie trwania incydentu, powodując opóźnienie w regułach handlowych. ‌ **Syntezę incydentu** * **16 marca 11h02: ** utworzenie wykrytej komórki kryzysowej i rozpoczęcie badań. * **16 marca 11h05: ** identyfikacja skrzynki depozytowej plików zwrotnych. * **16 marca 11h15: ** Identyfikacja drugiego problemu: niemożność dostępu do narzędzia umożliwiającego sprawdzanie poprawności. * **16 marca 11h15 - 12h: ** do śledztwa. * **16 marca 12h: ** potwierdzenie niemożności odblokowania funduszy w tym samym dniu. * **16 marca 12h - 18h30: ** do śledztwa. * **17 marca 9h: ** powtórzenie komórki kryzysowej. * **17 marca 9h28: ** odzyskiwanie plików wirementowych. Dla śledztwa. * **17 marca 10h23: identyfikacja rozwiązania konturowego umożliwiającego odprowadzanie podkładów. ** * **17 marca 10h23 - 11h15: ** testy sprawdzające dobre działanie rozwiązania. Testy końcowe. * **17 marca 11h30: ** weryfikacja plików zwrotnych. **Koniec incydentu. ** * **17 marca 12h09: ** potwierdzenie obsługi plików i przeniesienia funduszy w ciągu dnia. ‌ **Przyczyna korzenia** Operacja migracji wprowadza inkoherencję do danych technik stosowanych przez system walidacji wirementów z powodu rozpadu dwóch mechanizmów. Ta sytuacja blokuje normalną procedurę walidacji. **Akcje przyznane przez Payplug** Powrót do ostatniej wersji stabilnej został uruchomiony w celu przywrócenia usługi. Ta operacja pozwala na ponowne połączenie funkcji sprawdzania poprawności wierzytelnych sposobów. ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-3077 **Usługi płatnicze dotknięte incydentem** Handel elektroniczny i rozliczanie płatności w sklepie. **Wpływ klienta** Niemożność przetworzenia odwrócenia transakcji w okresie incydentu, skutkująca opóźnieniem w rozliczeniu handlowym. ‌ **Przegląd incydentów** * **16 marca 11:02: ** utworzenie dedykowanego zespołu kryzysowego i rozpoczęcie dochodzeń. * **16 marca 11:05: ** identyfikacja niepowodzenia w składaniu akt wypłat. * **16 marca 11:15: ** Identyfikacja drugiego problemu: niemożność dostępu do narzędzia służącego do walidacji transferów. * **16 marca 11:15 — 12:00: ** trwające dochodzenia. * **16 marca 12:00: ** potwierdzenie, że środki nie mogły zostać zwolnione tego samego dnia. * **16 marca 12:00 — 18:30: ** trwające dochodzenia. * **17 marca 9:00: ** Zespół kryzysowy wznowiony. * **17 marca 9:28: ** odzyskiwanie plików transferowych z poprzedniego dnia. Trwające dochodzenia. * **17 marca 10:23: ** **identyfikacja obejścia umożliwiającego wysłanie środków. ** * **17 marca 10:23 — 11:15: ** testowanie w celu weryfikacji rozwiązania. Testy udane. * **17 marca 11:30: ** walidacja plików wypłat. ** Incydent rozwiązany. ** * **17 marca 12:09: ** potwierdzenie, że pliki zostały przetworzone, a środki zostaną przekazane w ciągu dnia. ‌ **Przyczyna korzenia** Migracja wprowadziła niespójność danych technicznych wykorzystywanych przez system walidacji transferu, z powodu rozbieżności między dwoma mechanizmami, co uniemożliwiło normalne przetwarzanie walidacji. **Działania podjęte przez Payplug** Aby przywrócić usługę, zainicjowano wycofanie do ostatniej wersji stabilnej. Ta operacja pomyślnie przywróciła wszystkie funkcje walidacji transferu.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 2 marca 2026 11:46 UTCinvestigating

   FR Zidentyfikowaliśmy problemy na platformie płatniczej. Incydent jest w trakcie analizy. EN Zidentyfikowaliśmy ciągłe trudności na platformie płatniczej. Trwa śledztwo. TO Zidentyfikowaliśmy trudności w przetwarzaniu płatności. Incydent jest w fazie analizy.

2. 2 marca 2026 12:09 UTCmonitoring

   TSR-3011 - Początek/ Początek: 02/03/2026 12h28 CET - Zakończenie: 02/03/2026 13h01 CET - Kategoria/Kategoria: Przetwórstwo produkcji - Odpowiedzialność/Odpowiedzialność: Payplug - Priorytet/Priorytet: P1 FR Incydent jest teraz rozwiązany, a usługa jest naprawiona. Nadal obserwujemy powtórkę usługi. EN Incydent został rozwiązany, a usługa przywrócona. Odzyskiwanie usług jest nadal monitorowane. TO Incydent został rozwiązany, a usługa została przywrócona. Nadal monitorujemy odzyskiwanie usługi.

3. 2 marca 2026 14:15 UTCresolved

   Ten incydent został rozwiązany.

4. 5 marca 2026 15:09 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-3011 **Usługa objęta** Płatności e-commerce, 3DS i sklepy. **Klient wpływu** Niemożność dokonywania płatności przez portatorów. **Syntezę incydentu** * **2 marca 12h26: ** uruchomienie aktualizacji produkcyjnej. * **2 marca 12h28: początek incydentu. ** * **2 marca 12h29: ** pierwsza naprawa alertów. * **2 marca 12h33: ** utworzenie uszkodzonej komórki kryzysowej. Rozpoczęcie śledztwa. * **2 marca 12h37: ** identyfikacja błędów w usłudze. * **2 marca 12h56: Identyfikacja pochodzenia incydentu. ** * **2 marca 13h: ** aktualizacja poprawnych działań. * **2 marca 13h01: przegląd ruchu e-commerce i 3DS. ** * **2 marca 13h38: ** naprawa błędów w niektórych płatnościach w sklepach. Dla śledztwa. * **2 marca 13h50: ** identyfikacja i poprawa błędów usług. **Koniec incydentu. ** ‌ **Konteksto** NIE DOTYCZY **Przyczyna korzenia** Uruchomienie produkcyjne spowodowało zatrzymanie punktów wejściowych usług akceptujących transakcje. Te punkty wejściowe pozostały w przerwie, nie akceptują więcej transakcji i spowodowały przerwę w ruchu. ‌ **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Uruchomienie aktualizacji produkcji w czasie krytycznym. | Zdejmij proces eksploatacji, aby przyspieszyć misje produkcyjne w czasie krytycznym. | | Monitorowanie nieprawidłowych punktów wejściowych usług akceptujących transakcje. | Wzmocnienie monitorowania punktów wejściowych i usług obsługujących transakcje. | | Brak kontrolki do specyficznego certyfikatu dotyczącego uruchomienia instalacji produkcyjnej | Dodaj kontroler, aby sprawdzić stan certyfikatu po uruchomieniu aktualizacji. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-3011 **Usługi płatnicze dotknięte incydentem** Płatności e-commerce, 3DS i płatności w sklepie. **Wpływ klienta** Posiadacze kart nie mogli dokonywać płatności. **Przegląd incydentów** * **2 marca 12:26: ** wdrożenie produkcji. * **2** **Marzec 12:28: ** **rozpoczęcie incydentu. ** * **2 marca 12:29: ** podniesiony pierwszy alert. * **2 marca 12:33: ** powołano dedykowany zespół kryzysowy. Rozpoczynają się dochodzenia. * **2 marca 12:37: ** błędy zidentyfikowane w usłudze. * **2 marca 12:56: ** **zidentyfikowano główną przyczynę incydentu. ** * **2 marca 13:00: ** wdrożone działania naprawcze. * **2 marca 13:01: wznowienie handlu elektronicznego i ruchu 3DS. ** * **2 marca 13:38: ** błędy zgłoszone przy niektórych płatnościach w sklepie. Dochodzenia trwają. * **2 marca 13:50: ** identyfikacja i ponowne uruchomienie dotkniętych usług. ** Koniec incydentu. ** ‌ **Kontekst** NIE DOTYCZY **Przyczyna korzenia** Wdrożenie produkcji spowodowało wstrzymanie punktów wejścia usług obsługujących transakcje. Ponieważ te punkty wejścia zostały wstrzymane, nie akceptowały już transakcji, co spowodowało przerwanie ruchu. ‌ **Działania do podjęcia przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | Wdrażanie produkcji przeprowadzane w krytycznym oknie czasowym | Przypomnienie o procesie wdrażania w celu uniknięcia wdrażania produkcji w krytycznych oknach czasowych. | | Niewystarczające monitorowanie punktów wejścia usług akceptujących transakcje. | Wzmocnienie monitoringu punktów wejścia i usług dystrybuujących transakcje. | | Brak weryfikacji określonego certyfikatu po wdrożeniu produkcji. | Dodawanie kontroli w celu weryfikacji statusu certyfikatu po wdrożeniu produkcyjnym. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 lutego 2026 08:39 UTCmonitoring

   Witam, Zaburzenia trwają od godziny 8:00 tego dnia, jeśli chodzi o 3-D Secure Authentication. Ten zewnętrzny incydent na naszej platformie dotyczy portatorów kart rolniczych Crédit. Poinformujemy Cię, że incydent będzie rozwiązany. -------------- W języku włoskim: Dobry dzień, Istnieją pewne zakłócenia w toku od 9:00 do dziś, które wymagają uwierzytelniania 3-D Secure. Zainteresowane są głównie tytuły kart MasterCard. Ten przypadek, na zewnątrz naszej platformy, dotyczy około 30 do 50% żądań uwierzytelniania 3-D Secure. Informujemy, że incydent nie zostanie rozwiązany. -------------- W języku angielskim: Witam, Od 8:00 tego dnia trwają zakłócenia dotyczące uwierzytelniania 3D-Secure. Ten incydent jest poza naszą platformą. Dotyczy to głównie posiadaczy kart Crédit Agricole. Będziemy Cię informować, gdy tylko incydent zostanie rozwiązany.

2. 21 lutego 2026 12:26 UTCmonitoring

   Zdarzenie zewnętrzne jest zawsze w toku. Będziemy informowani o zmianach. --------------- Incydent nadal trwa. Będziemy Cię informować na bieżąco w przypadku jakichkolwiek zmian.

3. 21 lutego 2026 14:52 UTCresolved

   ZEWNĘTRZNE - Trwające dysfunkcje związane z autoryzacją 3-D Secure (9:00 CET - 15:00 CET) FR Incydent jest teraz rozwiązany, a usługa jest naprawiona. Nadal obserwujemy powtórkę usługi. EN Incydent został rozwiązany, a usługa przywrócona. Odzyskiwanie usług jest nadal monitorowane. TO Incydent został rozwiązany, a usługa została przywrócona. Nadal monitorujemy odzyskiwanie usługi.

4. 23 lutego 2026 09:12 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-2981 **Usługa objęta** Płatności e-commerce i 3DS. **Klient wpływu** Niemożność dokonywania płatności dla portatorów. **Syntezę incydentu** * **21 lutego 5h: początek incydentu. ** * **21 lutego 6h23: ** naprawa alertów. Sposób błędu jest zbyt niski w tym stadionie, aby odblokować strzał. * **21 lutego 8h32: ** utworzenie komórki kryzysowej wywołanej przez gwiazdę. Początek dochodzeń. * **21 lutego o godz. 8h34: ** identyfikacja wypłat pochodzących ze specyficznej sieci bankowej. * **21 lutego 9h-13h: ** na potrzeby analiz. * **21 lutego 13h30: koniec incydentu. ** * **21 lutego 14h41: ** potwierdzenie przez sieć zdarzenia w tym miejscu. **Konteksto** NIE DOTYCZY **Przyczyna korzenia** Zewnętrzny incydent spowodowany siecią bankową. ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-2981 **Usługi płatnicze dotknięte incydentem** Płatności e-commerce i 3DS. **Wpływ klienta** Posiadacze kart nie mogli dokonywać płatności. **Przegląd incydentów** * **21 lutego 5:00: początek incydentu. ** * **21 lutego 6:23: ** podniesiony alert. Próg błędu jest na tym etapie zbyt niski, aby uruchomić zespół ds. eskalacji dyżurów. * **21 lutego 8:32: ** dedykowany zespół kryzysowy utworzony przez zespół dyżurów. Rozpoczynają się dochodzenia. * **21 lutego 8:34: ** zidentyfikowane niepowodzenia płatności pochodzące z określonej sieci bankowej. * **21 lutego 9:00 — 13:00: ** analiza trwająca. * **21 lutego 13:30: koniec incydentu. ** * **21 lutego 14:41: ** potwierdzenie z sieci incydentu po ich stronie. **Kontekst** NIE DOTYCZY **Przyczyna korzenia** Incydent zewnętrzny pochodzący z sieci bankowej.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 19 lutego 2026 09:59 UTCidentified

   FR Zidentyfikowaliśmy problemy na platformie płatniczej. Dotychczasowe transakcje są wyłącznie celami celnymi za pośrednictwem Crédit Agricole. Pierwsze analizy wskazują, że pochodzenie incydentu jest zewnętrzne na naszej platformie. EN Zidentyfikowaliśmy ciągłe trudności na platformie płatniczej. Transakcje, których dotyczy problem, są ograniczone do transakcji przetwarzanych za pośrednictwem Crédit Agricole. Wstępne dochodzenia wskazują, że podstawowa przyczyna incydentu jest poza naszą platformą.

2. 19 lutego 2026 10:25 UTCmonitoring

   FR Incydent jest teraz rozwiązany, a usługa jest naprawiona. Nadal obserwujemy powtórkę usługi. EN Incydent został rozwiązany, a usługa przywrócona. Odzyskiwanie usług jest nadal monitorowane.

3. 19 lutego 2026 16:19 UTCresolved

   Ten incydent został rozwiązany.

4. 20 lutego 2026 13:54 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-2964 **Usługa objęta** Płatności e-commerce i 3DS. **Klient wpływu** Niemożność dokonywania płatności dla portatorów. **Syntezę incydentu** * **19 lutego 10h19: początek incydentu. ** * **19 lutego 10h24: ** utworzenie wykrytej komórki kryzysowej i rozpoczęcie dochodzeń. * **19 lutego 10h27: ** identyfikacja błędów pochodzących ze specyficznej zewnętrznej grupy bankowej. * **19 lutego 10h29: ** skontaktuj się z partnerem w celu uzyskania dodatkowych informacji dotyczących incydentu. * **19 lutego 10h39: ** powrót partnera potwierdza incydent w zewnętrznej grupie bankowej. * **19 lutego 10h51: ** kontakt z koncertową grupą bankową. * **19 lutego 10h56: koniec incydentu. ** * **19 lutego 11h: ** Grupa bankowa wskazuje, że zdarzenie jest spowodowane przez zewnętrzny prestator. **Konteksto** NIE DOTYCZY **Przyczyna korzenia** Zewnętrzny incydent z prestatorem zewnętrznej grupy bankowej. ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-2964 **Usługi płatnicze dotknięte incydentem** Płatności e-commerce i 3DS. **Wpływ klienta** Posiadacze kart nie mogli dokonywać płatności. **Przegląd incydentów** * **19 lutego 10:19: początek incydentu. ** * **19 lutego 10:24: ** powołano dedykowany zespół kryzysowy i rozpoczynają się dochodzenia. * **19 lutego 10:27: ** zidentyfikowane błędy pochodzące z określonej zewnętrznej grupy bankowej. * **19 lutego 10:29: ** skontaktujemy się z partnerem w celu uzyskania dalszych informacji dotyczących incydentu. * **19 lutego 10:39: ** informacje zwrotne od partnera potwierdzające incydent w ramach zewnętrznej grupy bankowej. * **19 lutego 10:51: ** kontaktujemy się z daną grupą bankową. * **19 lutego 10:56: koniec incydentu. ** * **19 lutego 11:00: ** grupa bankowa wskazuje, że incydent pochodzi od zewnętrznego usługodawcy. **Kontekst** NIE DOTYCZY **Przyczyna korzenia** Incydent zewnętrzny u usługodawcy zewnętrznej grupy bankowej.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 17 lutego 2026 16:11 UTCinvestigating

   FR Zidentyfikowaliśmy problemy w portalu Payplug. Incydent jest w trakcie analizy. EN Zidentyfikowaliśmy problemy z Payplug Poral. Dochodzenie jest w toku. TO Zidentyfikowaliśmy trudności za pomocą portalu Payplug. Incydent jest w fazie analizy.

2. 18 lutego 2026 07:23 UTCmonitoring

   TSR-2951 - Początek/ Start/Początek: 17/02/2026 16h CET - Fine/Koniec /finał: 17/02/2026 18h52 CET - Kategoria/Kategoria/ Kategoria: Produkcja Portail. - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Payplug. - Priorytet/Priorytet/Priorytet: P1. FR Sytuacja przynosi normalny przychód z powodu poprawnej eksploatacji. Ciągle monitorujemy usługę. EN Sytuacja wróciła do normy po wdrożeniu poprawki. Nadal monitorujemy usługę. TO Sytuacja wróciła do normalności po ujawnieniu poprawki. Kontynuujemy monitorowanie usługi.

3. 18 lutego 2026 14:32 UTCresolved

   Ten incydent został rozwiązany.

4. 18 lutego 2026 15:05 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-2951 **Usługa objęta** Portał **Klient wpływu** Problemy z połączeniem w celu uzyskania dostępu do portalu i komunikatów o błędach są niezwłocznie połączone. **Syntezę incydentu** * **16 lutego 15h15: ** uruchomienie aktualizacji produkcyjnej. * **16 lutego 15h18: ** problemy z połączeniami - odłączanie się również, jeśli komunikaty o błędach pojawiły się w Portalu. **Początek incydentu. ** * **16 lutego 15h34: ** naprawa alertów. Początek dochodzeń. * **16 lutego 15h53: ** utworzenie wyższej incydentnej komórki. * **16 lutego 15h58: ** komunikacja Strona statusu. Identyfikacja awarii produkcyjnej zgodnej z początkiem incydentu. Rozpoczęcie obrotu produkcyjnego. * **16 lutego 1608: ** zakończenie aktualizacji produkcji. * **16 lutego 16.25: Identyfikacja pochodzenia incydentu. ** * **16 lutego 1633: ** problemy z ciągłymi połączeniami. Uruchomienie powrotu do wcześniejszej wersji niektórych zidentyfikowanych usług niewłaściwych. * **16 lutego 16:54: ** zmiana usług z poprzednią wersją. * **16 lutego 1659: ** koniec problemów z połączeniami na Portalu. * **16 lutego 1706: ** zakończenie komunikatów o błędach w Portalu. **Koniec incydentu. ** * **17 lutego 16: ** **Poprawianie błędów. ** * **17 lutego 1629-18h35: ** utworzenie komórki kryzysowej i powtórzenie analiz. * **17 lutego 18h40: Identyfikacja pochodzenia incydentu i uruchomienie korekty. ** * **17 lutego 18h52: Koniec incydentu. ** **Konteksto** NIE DOTYCZY **Przyczyna korzenia** Aktualizacja produkcji spowodowała problemy z dostępem między naszymi usługami wewnętrznymi. Problemy te spowodowały przymusowe odłączenie użytkownika, który wrócił na stronę uwierzytelniania. Drugie wydarzenie zostało wywołane przez nową aktualizację produkcyjną, która spowodowała, że złe identyfikowalne elementy wycofywały się z powrotem. ‌ **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Dezsynchronizacja niektórych parametrów interfejsu API | Aktualizacja połączenia zsynchronizowanych ustawień. | | Automatyczne odnawianie interfejsu API clef. | Trwają badania w celu automatycznego odnawiania interfejsu API clef. | | Brak alertów dotyczących desynchronizacji niektórych parametrów interfejsu API. | Dodawanie komunikatów o błędach w przypadku desynchronizacji ustawień i poprawy alertów. | | Złożoność usługi deploiement. | Poprawianie operacji w usłudze za pomocą tajemnic\ (API KEY, wewnętrzne hasła...\) . | | Wymagane odłączenie, jeśli usługa w zespole jest niedostępna. | Trwają poprawki, aby uniemożliwić użytkownikom odłączenie się z usługą, gdy usługa jest niedostępna. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-2951 **Usługi płatnicze dotknięte incydentem** Portal **Wpływ klienta** Problemy z połączeniem podczas uzyskiwania dostępu do Portalu i nieoczekiwane komunikaty o błędach po zalogowaniu. **Przegląd incydentów** * **16 lutego 15:15: ** wdrożenie do produkcji. * **16 lutego 15:18: ** problemy z połączeniem — rozłączenia oraz komunikaty o błędach pojawiają się na Portalu. ** Początek incydentu. ** * **16 lutego 15:34: ** podniesiony alert. Rozpoczynają się dochodzenia. * **16 lutego 15:53: ** Utworzono zespół ds. poważnych incydentów. * **16 lutego 15:58: ** Wydano komunikat na stronie statusu. Zidentyfikowano wdrożenie produkcji zbiegające się z początkiem incydentu. Wycofanie zainicjowanego wdrożenia. * **16 lutego 16:08: ** cofnięcie wdrożenia produkcji nie powiodło się. * **16 lutego 16:25: zidentyfikowano główną przyczynę incydentu. ** * **16 lutego 16:33: ** problemy z połączeniem nadal występują. Wrócenie do poprzedniej wersji niektórych zidentyfikowanych wadliwych usług zainicjowanych. * **16 lutego 16:54: ** usługi zostały ponownie uruchomione z poprzednią wersją. * **16 lutego 16:59: ** zakończenie problemów z połączeniem w Portalu. * **16 lutego 17:06: ** koniec komunikatów o błędach w Portalu. ** Incydent rozwiązany. ** * **17 lutego 16:16: Powtarzanie błędów. ** * **17 lutego 16:29-18:35: ** powołano zespół kryzysowy i wznowiono dochodzenia. * **17 lutego 18:40: zidentyfikowano główną przyczynę i wdrożono poprawkę. ** * **17 lutego 18:52: incydent rozwiązany. ** **Kontekst** NIE DOTYCZY **Przyczyna korzenia** Wdrożenie produkcyjne spowodowało problemy z dostępem między naszymi wewnętrznymi usługami. Problemy te spowodowały, że użytkownicy zostali przymusowo wylogowani i przekierowani z powrotem na stronę uwierzytelniania. Drugie zdarzenie zostało wywołane przez późniejsze wdrożenie produkcyjne, które odzyskało nieprawidłowe dane uwierzytelniające po wycofaniu przeprowadzonym poprzedniego dnia. **Działania do podjęcia przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | Desynchronizacja niektórych kluczowych parametrów API. | Aktualizacja wszystkich zdezsynchronizowanych parametrów. | | Automatyczne odnawianie klucza API. | Trwają dochodzenia mające na celu zapobieżenie automatycznemu odnawianiu klucza API. | | Brak alertu dotyczącego desynchronizacji niektórych parametrów API. | Dodawanie komunikatów o błędach w przypadku desynchronizacji parametrów i poprawy alertowania. | | Złożoność w ramach usługi wdrażania. | Ulepszenia wdrożeń w usłudze zarządzającej tajemnicami\ (klucze API, hasła wewnętrzne itp.\) . | | Wymuszone wylogowanie, jeśli jakakolwiek usługa w ekosystemie stanie się niedostępna. | Trwają ulepszenia, aby zapobiec wylogowaniu użytkowników, gdy tylko usługa stanie się niedostępna. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 lutego 2026 14:58 UTCinvestigating

   FR Zidentyfikowaliśmy problemy w portalu Payplug. Incydent jest w trakcie analizy. EN Zidentyfikowaliśmy problemy z Payplug Poral. Dochodzenie jest w toku. TO Zidentyfikowaliśmy trudności za pomocą portalu Payplug. Incydent jest w fazie analizy.

2. 16 lutego 2026 15:10 UTCinvestigating

   FR Dochodzenia są zawsze w toku. Wrócimy do ciebie w ciągu 15 minut. EN Dochodzenia wciąż trwają. Skontaktujemy się z tobą za 15 minut. TO Uczniowie są jeszcze na bieżąco. Skontaktujemy się z Tobą w ciągu 15 minut.

3. 16 lutego 2026 15:25 UTCidentified

   FR Dochodzenia są zawsze w toku. Wrócimy do ciebie w ciągu 15 minut. EN Dochodzenia wciąż trwają. Skontaktujemy się z tobą za 15 minut. TO Uczniowie są jeszcze na bieżąco. Skontaktujemy się z Tobą w ciągu 15 minut.

4. 16 lutego 2026 15:40 UTCidentified

   TSR-2951 - Początek/ Start/Początek: 16/02/2026 15h18 CET - Fin/End /fine: Na bieżący/Bieżący/W toku. - Kategoria/Kategoria/ Kategoria: Produkcja Portail. - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Potwierdzająca/Do potwierdzenia/Da confermare. - Priorytet/Priorytet/Priorytet: P2. FR Dochodzenia są zawsze w toku. Wrócimy do ciebie w ciągu 15 minut. EN Dochodzenia wciąż trwają. Skontaktujemy się z tobą za 15 minut. TO Uczniowie są jeszcze na bieżąco. Skontaktujemy się z Tobą w ciągu 15 minut.

5. 16 lutego 2026 15:53 UTCidentified

   TSR-2951 - Początek/ Start/Początek: 16/02/2026 15h18 CET - Fin/End /fine: Na bieżący/Bieżący/W toku. - Kategoria/Kategoria/ Kategoria: Produkcja Portail. - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Potwierdzająca/Do potwierdzenia/Da confermare. - Priorytet/Priorytet/Priorytet: P2. FR Żądania zwrotu i dostęp do Portaila są obecnie przerywane. Urządzenie może pojawić się po rozłączeniu i komunikaty o błędach. Pracujemy nad tym, aby obsługa była możliwa. EN Żądania transferu i dostęp do Portalu są obecnie zakłócone. Użytkownicy mogą doświadczyć nieoczekiwanych wylogowań i komunikatów o błędach. Pracujemy nad przywróceniem usługi tak szybko, jak to możliwe. TO Prośba o pobranie i dostęp do Portalu są obecnie niepokojące. Możliwe jest weryfikowanie niepowiązań i komunikatów o błędach. Pracujemy nad przywróceniem usługi w miarę możliwości.

6. 16 lutego 2026 16:05 UTCmonitoring

   TSR-2951 - Początek/ Start/Początek: 16/02/2026 15h18 CET - Fina/Koniec /finał: 16/02/2026 16th 59 CET - Kategoria/Kategoria/ Kategoria: Produkcja Portail. - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Potwierdzająca/Do potwierdzenia/Da confermare. - Priorytet/Priorytet/Priorytet: P2. FR Sytuacja powraca do normy od godziny 1659. Nadal monitorujemy usługę. EN Sytuacja stopniowo wraca do normy od 16:59 po południu. Nadal monitorujemy usługę. TO Sytuacja stopniowo wraca do normy od 16:59. Nadal monitorujemy usługę.

7. 16 lutego 2026 16:11 UTCresolved

   Ten incydent został rozwiązany.

8. 18 lutego 2026 15:00 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-2951 **Usługa objęta** Portał **Klient wpływu** Problemy z połączeniem w celu uzyskania dostępu do portalu i komunikatów o błędach są niezwłocznie połączone. **Syntezę incydentu** * **16 lutego 15h15: ** uruchomienie aktualizacji produkcyjnej. * **16 lutego 15h18: ** problemy z połączeniami - odłączanie się również, jeśli komunikaty o błędach pojawiły się w Portalu. **Początek incydentu. ** * **16 lutego 15h34: ** naprawa alertów. Początek dochodzeń. * **16 lutego 15h53: ** utworzenie wyższej incydentnej komórki. * **16 lutego 15h58: ** komunikacja Strona statusu. Identyfikacja awarii produkcyjnej zgodnej z początkiem incydentu. Rozpoczęcie obrotu produkcyjnego. * **16 lutego 1608: ** zakończenie aktualizacji produkcji. * **16 lutego 16.25: Identyfikacja pochodzenia incydentu. ** * **16 lutego 1633: ** problemy z ciągłymi połączeniami. Uruchomienie powrotu do wcześniejszej wersji niektórych zidentyfikowanych usług niewłaściwych. * **16 lutego 16:54: ** zmiana usług z poprzednią wersją. * **16 lutego 1659: ** koniec problemów z połączeniami na Portalu. * **16 lutego 1706: ** zakończenie komunikatów o błędach w Portalu. **Koniec incydentu. ** * **17 lutego 16: ** **Poprawianie błędów. ** * **17 lutego 1629-18h35: ** utworzenie komórki kryzysowej i powtórzenie analiz. * **17 lutego 18h40: Identyfikacja pochodzenia incydentu i uruchomienie korekty. ** * **17 lutego 18h52: Koniec incydentu. ** **Konteksto** NIE DOTYCZY **Przyczyna korzenia** Aktualizacja produkcji spowodowała problemy z dostępem między naszymi usługami wewnętrznymi. Problemy te spowodowały przymusowe odłączenie użytkownika, który wrócił na stronę uwierzytelniania. Drugie wydarzenie zostało wywołane przez nową aktualizację produkcyjną, która spowodowała, że złe identyfikowalne elementy wycofywały się z powrotem. ‌ **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Dezsynchronizacja niektórych parametrów interfejsu API | Aktualizacja połączenia zsynchronizowanych ustawień. | | Automatyczne odnawianie interfejsu API clef. | Trwają badania w celu automatycznego odnawiania interfejsu API clef. | | Brak alertów dotyczących desynchronizacji niektórych parametrów interfejsu API. | Dodawanie komunikatów o błędach w przypadku desynchronizacji ustawień i poprawy alertów. | | Złożoność usługi deploiement. | Poprawianie operacji w usłudze za pomocą tajemnic\ (API KEY, wewnętrzne hasła...\) . | | Wymagane odłączenie, jeśli usługa w zespole jest niedostępna. | Trwają poprawki, aby uniemożliwić użytkownikom odłączenie się z usługą, gdy usługa jest niedostępna. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-2951 **Usługi płatnicze dotknięte incydentem** Portal **Wpływ klienta** Problemy z połączeniem podczas uzyskiwania dostępu do Portalu i nieoczekiwane komunikaty o błędach po zalogowaniu. **Przegląd incydentów** * **16 lutego 15:15: ** wdrożenie do produkcji. * **16 lutego 15:18: ** problemy z połączeniem — rozłączenia oraz komunikaty o błędach pojawiają się na Portalu. ** Początek incydentu. ** * **16 lutego 15:34: ** podniesiony alert. Rozpoczynają się dochodzenia. * **16 lutego 15:53: ** Utworzono zespół ds. poważnych incydentów. * **16 lutego 15:58: ** Wydano komunikat na stronie statusu. Zidentyfikowano wdrożenie produkcji zbiegające się z początkiem incydentu. Wycofanie zainicjowanego wdrożenia. * **16 lutego 16:08: ** cofnięcie wdrożenia produkcji nie powiodło się. * **16 lutego 16:25: zidentyfikowano główną przyczynę incydentu. ** * **16 lutego 16:33: ** problemy z połączeniem nadal występują. Wrócenie do poprzedniej wersji niektórych zidentyfikowanych wadliwych usług zainicjowanych. * **16 lutego 16:54: ** usługi zostały ponownie uruchomione z poprzednią wersją. * **16 lutego 16:59: ** zakończenie problemów z połączeniem w Portalu. * **16 lutego 17:06: ** koniec komunikatów o błędach w Portalu. ** Incydent rozwiązany. ** * **17 lutego 16:16: Powtarzanie błędów. ** * **17 lutego 16:29-18:35: ** powołano zespół kryzysowy i wznowiono dochodzenia. * **17 lutego 18:40: zidentyfikowano główną przyczynę i wdrożono poprawkę. ** * **17 lutego 18:52: incydent rozwiązany. ** **Kontekst** NIE DOTYCZY **Przyczyna korzenia** Wdrożenie produkcyjne spowodowało problemy z dostępem między naszymi wewnętrznymi usługami. Problemy te spowodowały, że użytkownicy zostali przymusowo wylogowani i przekierowani z powrotem na stronę uwierzytelniania. Drugie zdarzenie zostało wywołane przez późniejsze wdrożenie produkcyjne, które odzyskało nieprawidłowe dane uwierzytelniające po wycofaniu przeprowadzonym poprzedniego dnia. **Działania do podjęcia przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | Desynchronizacja niektórych kluczowych parametrów API. | Aktualizacja wszystkich zdezsynchronizowanych parametrów. | | Automatyczne odnawianie klucza API. | Trwają dochodzenia mające na celu zapobieżenie automatycznemu odnawianiu klucza API. | | Brak alertu dotyczącego desynchronizacji niektórych parametrów API. | Dodawanie komunikatów o błędach w przypadku desynchronizacji parametrów i poprawy alertowania. | | Złożoność w ramach usługi wdrażania. | Ulepszenia wdrożeń w usłudze zarządzającej tajemnicami\ (klucze API, hasła wewnętrzne itp.\) . | | Wymuszone wylogowanie, jeśli jakakolwiek usługa w ekosystemie stanie się niedostępna. | Trwają ulepszenia, aby zapobiec wylogowaniu użytkowników, gdy tylko usługa stanie się niedostępna. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 5 grudnia 2025 09:00 UTCinvestigating

   FR Zidentyfikowaliśmy trudności związane z przetwarzaniem płatności, które wydają się być związane z incydentem w Cloudflare. EN Zidentyfikowaliśmy trudności z przetwarzaniem płatności, które wydają się być związane z incydentem w Cloudflare. TO Dostrzegamy trudności związane z przetwarzaniem płatności, które wydają się być powiązane z incydentem, który miał miejsce w Cloudflare.

2. 5 grudnia 2025 09:06 UTCinvestigating

   Nadal badamy tę kwestię.

3. 5 grudnia 2025 09:17 UTCmonitoring

   TSR-2651 - Początek/ Początek: 04/12/2025 09h48 CET - Końców/ Koniec: 04/12/2025 10h13 CET - Kategoria/Kategoria: Przetwórstwo produkcji - Odpowiedzialność/Odpowiedzialność: Zewnętrzna/Zewnętrzna - Priorytet/Priorytet: P1 FR Przetwarzanie odbywa się w pociągu powrotnym od 10h13. Nadal monitorujemy usługę. EN Przetwarzanie odzyskiwane jest od 10:13. Nadal monitorujemy usługę. Przetwarzanie powraca od 10:13. Nadal monitorujemy usługę.

4. 5 grudnia 2025 14:44 UTCresolved

   Ten incydent został rozwiązany.

5. 9 grudnia 2025 09:21 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-2651 **Usługa objęta** Płatności e-commerce i 3DS. **Klient wpływu** Niemożność dokonywania płatności dla portatorów. ‌ **Syntezę incydentu** * **5 grudnia 09h48: początek incydentu** i naprawy alertów. * **5 grudnia 09h52: ** utworzenie dedykowanej komórki kryzysowej. Rozpoczęcie śledztwa i podejrzenia o incydent w Clouflare. * **5 grudnia 09h54: ** potwierdzenie incydentu w Cloudflare. * **5 grudnia 10h: ** Strona statusu komunikacji. * **5 grudnia 10h13: koniec incydentu. ** ‌ **Konteksto** NIE DOTYCZY **Przyczyna korzenia** Incydent w Clouflare. **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Brak alternatywy w przypadku awarii Cloudflare. | Zapoznaj się z alternatywami, aby uzyskać rozwiązanie do tworzenia kopii zapasowych w razie incydentu. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-2651 **Usługi płatnicze dotknięte incydentem** Płatności e-commerce i 3DS. **Wpływ klienta** Brak możliwości dokonywania płatności przez posiadaczy kart. ‌ **Przegląd incydentów** * **5 grudnia 09:48: początek incydentu** i podniesione alerty. * **5 grudnia 09:52: ** utworzenie dedykowanej jednostki kryzysowej. Rozpoczęcie śledztwa i podejrzenie incydentu w Cloudflare. * **5 grudnia 09:54: ** potwierdzenie incydentu w Cloudflare. * **5 grudnia 10:00: ** Komunikacja na stronie statusu. * **5 grudnia 10:13: koniec incydentu. ** ‌ **Kontekst** NIE DOTYCZY **Przyczyna korzenia** Incydent w Cloudflare. **Działania do podjęcia przez Payplug** | **Objawy | **Działanie** | | --- | --- | | Brak alternatywy w przypadku awarii Cloudflare. | Obecnie trwają badania nad alternatywami zapewniającymi rozwiązanie do tworzenia kopii zapasowych w przypadku incydentu. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 3 grudnia 2025 10:36 UTCinvestigating

   FR Zwroty z 2 grudnia, które początkowo miały miejsce dzisiaj, będą miały miejsce w krótkim czasie. Twoja część nie wymaga żadnej akcji, a tapety będą dostępne na Twoich kontach jak zwykle. Szczegóły odnośnych zasobów zostaną zaktualizowane dzisiaj. EN Wypłaty na 2 grudnia, pierwotnie zaplanowane na dziś, zostaną rozpatrzone jutro. Z Twojej strony nie są wymagane żadne działania, a środki będą dostępne na Twoich kontach jak zwykle. Szczegóły dotyczące odpowiednich przelewów zostaną udostępnione dzisiaj.

2. 3 grudnia 2025 10:44 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

3. 4 grudnia 2025 10:39 UTCmonitoring

   FR Zwroty z 2 grudnia zostały dobrze wykonane. W rewansie, zwroty z 3 grudnia, które początkowo miały miejsce dzisiaj, będą miały miejsce w bardzo krótkim czasie. Twoja część nie wymaga żadnej akcji, a tapety będą dostępne na Twoich kontach jak zwykle. Szczegóły odnośnych zasobów zostaną zaktualizowane dzisiaj. EN Wypłaty za 2 grudnia zostały pomyślnie przetworzone. Jednak wypłaty na 3 grudnia, które pierwotnie były zaplanowane na dziś, zostaną przetworzone jutro. Z Twojej strony nie są wymagane żadne działania, a środki będą dostępne na Twoich kontach jak zwykle. Szczegóły dotyczące odpowiednich przelewów zostaną udostępnione dzisiaj.

4. 5 grudnia 2025 11:20 UTCresolved

   FR Potwierdzamy odwrócenie transakcji 3 grudnia. Jesteśmy na bieżąco z odwróceniami. EN Potwierdzamy wypłaty transakcji od 3 grudnia. Jesteśmy na bieżąco z wypłatami. TO Zlecamy zwrot transakcji z 3 grudnia. Jesteśmy na bieżąco aktualizowani.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 października 2025 08:02 UTCinvestigating

   FR Dokumenty obliczeniowe nie mogą być obecnie eksportowane z portalu. Dokumenty są nadal dostępne online. Nasze zespoły aktywnie badają przyczynę problemu. EN Dokumenty księgowe nie mogą być obecnie eksportowane z Portalu. Dokumenty pozostają dostępne do przeglądania online. Nasze zespoły aktywnie badają przyczynę problemu. TO Dokumenty księgowe nie mogą być obecnie dłużej eksportowane z portalu. Dokumenty pozostają do konsultacji online. Nasz zespół aktywnie bada przyczynę problemu.

2. 21 października 2025 08:40 UTCinvestigating

   TSR- 2453 - Początek/Start/Początek: Potwierdzenie/Do potwierdzenia/Aby się potwierdzić. - Fin/End /fine: Na bieżący/Bieżący/W toku. - Kategoria/Kategoria/ Kategoria: Produkcja Portail. - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Potwierdzająca/Do potwierdzenia/Da confermare. - Priorytet/Priorytet/Priorytet: P3. FR Wydaje się, że incydent wpływa tylko na rzeczywiste próby eksportu za pomocą przeglądarki Google Chrome. Dokumenty obliczeniowe można pobrać za pomocą Firefoksa. Nasze zespoły nieustannie inwestują, aby odkryć pochodzenie incydentu. EN Wydaje się, że incydent dotyczy tylko prób eksportu dokonanych w przeglądarce Google Chrome. Dokumenty księgowe można pobrać za pomocą Firefoksa. Nasze zespoły kontynuują śledztwo w celu ustalenia źródła incydentu. TO Wydaje się, że incydent wpływa tylko na próby eksportu przeprowadzone w przeglądarce Google Chrome. Dokumenty księgowe można pobrać za pomocą Firefoksa. Nasz zespół kontynuuje badania w celu ustalenia pochodzenia incydentu.

3. 21 października 2025 12:00 UTCmonitoring

   TSR- 2453 - Początek/ Start/Początek: 21/10/2025 8h30 - Płetwa/Koniec /finał: 21/10/2025 13h54 - Kategoria/Kategoria/ Kategoria: Produkcja Portail. - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Potwierdzająca/Do potwierdzenia/Da confermare. - Priorytet/Priorytet/Priorytet: P3. FR Dokumenty obliczeniowe są do pobrania od nowa z Google Chrome. Nasze zespoły nieustannie monitorują usługę. EN Dokumenty księgowe można teraz pobrać ponownie za pomocą Google Chrome. Nasze zespoły nadal monitorują usługę. TO Dokumenty księgowe można bezpośrednio pobierać za pośrednictwem przeglądarki Google Chrome. Nasz zespół nadal monitoruje usługę.

4. 23 października 2025 06:10 UTCresolved

   Ten incydent został rozwiązany.

5. 13 listopada 2025 10:58 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-2453 **Usługa objęta** Marchand portail. **Klient wpływu** Niemożność eksportowania dokumentów obliczeniowych na rynku. **Syntezę incydentu** * **21 października 8h30: ** Wielkość zapotrzebowania na eksport zadeklarowane przez użytkownika. **Początek incydentu. ** * **21 października 9h48: ** naprawy alertów o niedostępności dokumentów obliczeniowych. * **21 października 9h50: ** tworzenie biletu na zespoły techniczne. Początek dochodzeń. * **21 października 10h02: ** Strona statusu komunikacji. * **21 października 10h07: ** wzrost biletu. * **21 października 10h30: ** identyfikacja rozwiązania konturowego przekazu do rynków. * **21 października 11h19: ** Identyfikacja pochodzenia incydentu. * **22 października 1643: ** Uruchomienie akcji w celu usunięcia odtwarzania zdarzenia. **Koniec incydentu. ** * **Od 23 października: ** w celu przeprowadzenia dochodzeń w celu wyjaśnienia głębokiej przyczyny. ‌ **Konteksto** NIE DOTYCZY **Przyczyna korzenia** Na usługę generowania eksportu obliczeniowego wpłynęły bardzo duże zapotrzebowanie i powtórzone przez użytkowników. Te żądania utworzyły dopłatę i sprawiają, że usługa jest niedostępna. ‌ **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Kontrola wpływu wolumenu popytu i odzysku eksportu | Aktualizacja zamiast ostrzeżenia, że wymagany jest ważny eksport. Reagowanie procesu w przypadku reprodukcji sytuacji. | | Nasycenie usługi generowania eksportu obliczeniowego | Dochodzenia w toku. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-2453 **Usługi płatnicze dotknięte incydentem** Portal handlowy. **Wpływ klienta** Sprzedawcy nie mogą eksportować dokumentów księgowych. **Przegląd incydentów** * **21 października 8:30: ** powtarzane duże żądania eksportu przez użytkownika. ** Początek incydentu. ** * **21 października 9:48: ** zgłoszone ostrzeżenia dotyczące niedostępności dokumentów księgowych. * **21 października 9:50: ** bilet stworzony dla zespołów technicznych. Rozpoczęcie dochodzeń. * **21 października 10:02am: ** Wydano komunikat na stronie statusu. * **21 października 10:07: ** bilet eskalowany. * **21 października 10:30: ** identyfikacja obejścia udostępnionego handlowcom. * **21 października 11:19: ** identyfikacja pierwotnej przyczyny incydentu. * **22 października 16:43: ** wdrożenie środków zapobiegających nawrotom. ** Koniec incydentu. ** * **Od 23 października: ** Trwające dochodzenia mające na celu rozwiązanie podstawowej przyczyny. ‌ **Kontekst** NIE DOTYCZY **Przyczyna korzenia** Na usługę generowania eksportu księgowego wpłynęły bardzo duże i powtarzające się żądania złożone przez kilku użytkowników. Żądania te spowodowały przeciążenie, przez co usługa była niedostępna. ‌ **Działania do podjęcia przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | Brak świadomości wpływu dużych i powtarzających się żądań eksportowych. | Wdrożenie alertu za każdym razem, gdy żądany jest duży eksport. Opracowanie procedury na wypadek powtórzenia się sytuacji. | | Nasycenie księgowej usługi generowania eksportu. | Trwają dochodzenia. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 4 września 2025 09:23 UTCidentified

   TSR-2228 - Początek/ Początek: 04/09/2025 - Końców/Koniec: En-cours/w toku - Kategoria/Kategoria: Odwrócenie/Rozliczenie - Odpowiedzialność/Odpowiedzialność: Payplug - Priorytet/Priorytet: P2 FR Odwrócenie niektórych operacji płatniczych e-commerce i sklepów, które pojawiły się dzisiaj, nie mogło być realizowane w czasie. Odpowiednie porozumienie finansowe zostanie zaktualizowane dzisiaj. Pochodzenie incydentu zostało zidentyfikowane, a niewywołane zagrożenia zostaną automatycznie zgłaszane i uszkodzone, bez konieczności wykonywania jakichkolwiek działań z Twojej części. EN Wypłata niektórych transakcji płatniczych w handlu elektronicznym i sklepu, które powinny być przeprowadzone dzisiaj, nie mogła zostać zakończona na czas. Odpowiednie uzgodnienie finansowe zostanie udostępnione dzisiaj. Przyczyna incydentu została zidentyfikowana, a niewykonane płatności zostaną automatycznie odroczone i przetworzone jutro, bez konieczności podjęcia działań z Twojej strony.

2. 4 września 2025 12:35 UTCmonitoring

   TSR-2228 - Początek/ Początek: 04/09/2025 - Końców/Koniec: En-cours/w toku - Kategoria/Kategoria: Odwrócenie/Rozliczenie - Odpowiedzialność/Odpowiedzialność: Payplug - Priorytet/Priorytet: P2 FR Potwierdzamy utratę zjawisk, które zostaną odwrócone. Ciągle monitorujemy usługę. EN Potwierdzamy odzyskanie przelewów, które zostaną wypłacone jutro. Nadal monitorujemy usługę.

3. 5 września 2025 08:43 UTCresolved

   TSR-2228 - Początek/ Początek: 04/09/2025 - Fina/Koniec: 05/09/2025 - Kategoria/Kategoria: Odwrócenie/Rozliczenie - Odpowiedzialność/Odpowiedzialność: Payplug - Priorytet/Priorytet: P2 FR Opcje płatności e-commerce i sklepu, które nie zostały odwrócone tutaj, zostały dziś odwrócone. Korespondencja finansowa wiąże się z transakcjami ratowanymi. EN Operacje e-commerce i płatności w sklepie, które nie zostały rozliczone wczoraj, zostały rozliczone dzisiaj. Odpowiednie uzgodnienie finansowe dokładnie obejmuje odzyskane transakcje.

4. 5 września 2025 12:16 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-2228 **Usługa objęta** Odwrócenie opłat w handlu elektronicznym i sklepie. **Klient wpływu** Częściowo odwrócenie transakcji. **Syntezę incydentu** * **4 września 7h30: ** Początek nasycenia plików o różnym strumieniu. **Początek incydentu. ** * **4 września 8h50: ** wykrycie opóźnienia w leczeniu wirementów. Tworzenie wykrytej komórki kryzysowej i rozpoczęcie analiz. * **4 wrzesień 8h53: ** identyfikacja nasycenia strumienia po skręcie, która nieudaje się obracać w polu. * **4 września 8h56: ** testy do ponownego uruchomienia określonego przepływu na trasach wtórnych w celu zmniejszenia nasycenia. * **4 września 9h09: ** Usunięcie niektórych strumieni nie jest dotknięte incydentem na innych trasach. Po to, jak przeprowadzić analizy w celu wykrycia zmian w ciągu dnia. * **4 września 10h: ** relacja z zabiegami żywiołowymi po wielu wykonanych czynnościach, aby zapewnić utratę efektów uderzeń. * **4 września 11h57: ** zakończenie zabiegów po ograniczonym czasie. Niektóre wirementy będą realistyczne w przypadku Lendemain. * **5 września: ** odwrócenie transakcji. **Koniec incydentu. ** **Konteksto** NIE DOTYCZY **Przyczyna korzenia** Uruchomienie produkcyjne spowodowało przerwanie połączenia między dwoma interfejsami API. Wejście jest wpuszczane do kosza i zasyca różne trasy prowadzące do przepływu. ‌ **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Brak wykrywania ostrzeżeń. | Poprawa monitorowania w celu uzyskania najlepszej identyfikacji w przypadku incydentu. | | Blokowanie czynności spowodowanych błędem | Zmiana architektury plików ostrzegawczych, aby upewnić się, że błąd nie może zablokować połączenia operacji. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-2228 **Usługi płatnicze dotknięte incydentem** Handel elektroniczny i rozliczanie płatności w sklepie. **Wpływ klienta** Częściowe rozliczenie transakcji. **Przegląd incydentów** * **4 września 7:30 rano —** rozpoczęcie nasycenia kolejki przetwarzając różne przepływy. ** Początek incydentu. ** * **4 września 8:50am —** wykrycie opóźnienia w przetwarzaniu transferu. Stworzono dedykowaną jednostkę kryzysową i rozpoczęto analizę. * **4 września 8:53am —** identyfikacja nasycenia przepływu spowodowanego nieudaną pętlą zadania. * **4 września 8:56am —** testy w celu zmiany trasy niektórych przepływów przez ścieżki wtórne, aby uniknąć nasycenia. * **4 września 9:09 —** przeniesienie niektórych przepływów, na które nie ma wpływu incydent, na inne trasy. Dalsza analiza w celu próby ponownego uruchomienia transferów w ciągu dnia. * **4 września 10:00 —** przetwarzanie transferu zostało wznowione po kilku działaniach podjętych w celu uniknięcia skutków ubocznych. * **4 września 11:57 —** przetwarzanie zakończone po upływie przerwy. Niektóre transfery zostaną przeprowadzone następnego dnia. * **5 września —** transakcje wypłacone. ** Koniec incydentu. ** **Kontekst** NIE DOTYCZY **Przyczyna korzenia** Wdrożenie produkcyjne spowodowało przerwanie połączenia między dwoma interfejsami API. Zadanie weszło w pętlę i nasyciło różne trasy przetwarzające przepływy. **Działania do podjęcia przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | Brak wykrywania alertów. | Ulepszone monitorowanie w celu lepszej identyfikacji w przypadku incydentu. | | Blokowanie przetwarzania spowodowane błędem. | Przegląd architektury kolejki, aby upewnić się, że nieudane zadanie nie może zablokować całego przetwarzania. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 29 lipca 2025 12:57 UTCinvestigating

   FR Zidentyfikowaliśmy trudności związane z przetwarzaniem płatności. Incydent jest w trakcie analizy. EN Zidentyfikowaliśmy ciągłe trudności w przetwarzaniu płatności. Trwa śledztwo. TO Zidentyfikowaliśmy trudności w przetwarzaniu płatności. Incydent jest w fazie analizy.

2. 29 lipca 2025 13:14 UTCmonitoring

   TSR-2090 - Początek/ Start/Początek: 29/07/2025 14h43 CEST. - Fin/End /fine: Na bieżący/Bieżący/W toku. - Kategoria/Kategoria/Kategoria: Przetwórstwo produkcyjne - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Payplug - Priorytet/Priorytet/Priorytet: P2 FR Usługa wzrawia się stopniowo nominalnie od 15h 08. Ciągle monitorujemy usługę. EN Usługa nominalna jest obserwowana od 15:08 po południu. Nadal monitorujemy usługę. TO Usługa powraca stopniowo do normy od 15:08. Kontynuujemy monitorowanie usługi.

3. 29 lipca 2025 14:17 UTCresolved

   TSR-2090 - Początek/ Start/Początek: 29/07/2025 14h43 CEST. - Płetwa/Koniec /finał: 29/07/2025 15h08 CEST. - Kategoria/Kategoria/Kategoria: Przetwórstwo produkcji - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Payplug - Priorytet/Priorytet/Priorytet: P2 FR Zastosowano korekty. Usługa była realna. EN Zastosowano poprawkę. Usługa została przywrócona. TO Została zastosowana korekta. Usługa została przywrócona.

4. 30 lipca 2025 07:12 UTCpostmortem

   # _Wersja angielska poniżej_ # Post Mortem **Referencja incydentu** TSR-2090 **Usługa objęta** Płatności w handlu elektronicznym i sklepie. **Klient wpływu** Niezbędność ogólna. **Syntezę incydentu** * **23 lipca: ** Aktualizacja produkcji pierwszej grupy serwerów. * **24 lipca: ** Aktualizacja produkcji drugiej grupy serwerów. * **29 lipca 14h43**: Aktualizacja produkcji trzeciej grupy serwerów. **Początek incydentu. ** * **29 lipca 14h45**: naprawy alertów. * **29 lipca 14h48: ** utworzenie komórki incydentu wyższego i rozpoczęcie dochodzeń. * **29 lipca 14h51: ** Strona statusu komunikacji. * **29 lipca 14h51: ** ponowne uruchomienie usługi. * **29 lipca 15:05 :** progresywne powtórzenie usługi. * **29 lipca 15h08**: **koniec incydentu. ** ‌ **Konteksto** Zarządzanie poprawkami składa się z serii poprawek, które są uruchamiane co tydzień alternatywnie na trzech stronach serwerów produkcyjnych\ (wtorek, środa i czwartek\). **Przyczyna korzenia** Zarządzanie poprawkami kontynuuje produkcję serwerów. ‌ **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Wykrywanie aktualizacji przed produkcją serwerów | Dodaj kontrolki, aby być ostrzeżonym, że serwer jest moją produkcją. | | Aktualizacja produkcji najnowszego serwera. | Dodaj kontrolki, aby być ostrzeżonym, że nie pozostanie więcej niż aktywny serwer w produkcji. Zakaz automatycznej aktualizacji produkcji ostatniego serwera. | | Uruchom kolejną produkcję wszystkich serwerów produkcyjnych przez zarządzanie poprawkami. | Wyłączanie po nowej kolejności zarządzania poprawkami. Dochodzenia w toku. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-2090 **Usługi płatnicze dotknięte incydentem** E-commerce i płatności w sklepie. **Wpływ klienta** Powszechna niedostępność. **Przegląd incydentów** * **23 lipca: ** likwidacja pierwszej grupy serwerów. * **24 lipca: ** likwidacja drugiej grupy serwerów. * **29 lipca - 14:43: ** likwidacja trzeciej grupy serwerów. ** Początek incydentu. ** * **29 lipca - 14:45: ** uruchomione alerty. * **29 lipca - 14:48: ** utworzono grupę zadaniową ds. poważnych incydentów i rozpoczęto dochodzenia. * **29 lipca - 14:51: ** komunikacja na stronie statusu. * **29 lipca - 14:51: ** zmiana rozmieszczenia usług. * **29 lipca - 15:05: ** stopniowe odzyskiwanie usług. * **29 lipca - 15:08: koniec incydentu. ** ‌ **Kontekst** Zarządzanie poprawkami składa się z serii aktualizacji, które są wdrażane co tydzień w rotacji w każdej z trzech grup serwerów produkcyjnych\ (we wtorki, środy i czwartki\). **Przyczyna korzenia** Zarządzanie poprawkami sukcesywnie wycofywało każdy z serwerów. ‌ **Działania do podjęcia przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Brak wykrycia likwidacji serwera. | Dodawanie elementów sterujących do wyzwalania alertów zaraz po wycofaniu serwera. | | Wycofanie ostatniego serwera. | Dodawanie elementów sterujących w celu wyzwalania alertów, gdy pozostaje tylko jeden aktywny serwer produkcyjny. Blokowanie automatycznego likwidacji ostatniego serwera. | | Kolejne likwidacja wszystkich serwerów produkcyjnych przez zarządzanie poprawkami. | Zarządzanie poprawkami wyłączone do odwołania. Trwające dochodzenia. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 lipca 2025 08:41 UTCinvestigating

   FR Zidentyfikowaliśmy problemy z przetwarzaniem płatności Oney, które powodują całkowitą niepotrzebność usługi. Incydent jest w trakcie analizy. EN Zidentyfikowaliśmy problemy z przetwarzaniem płatności Oney, powodujące całkowitą niedostępność usługi. Trwa śledztwo. TO Zidentyfikowaliśmy trudności w przetwarzaniu płatności Oney, które charakteryzują się pełną niepotrzebnością usługi. Incydent jest w fazie analizy.

2. 15 lipca 2025 09:03 UTCmonitoring

   FR Incydent wpływający na przetwarzanie płatności Oney jest rozwiązany. Pochodzenie tego incydentu było zewnętrzne na naszej platformie. EN Incydent mający wpływ na przetwarzanie płatności Oney został rozwiązany. Pochodzenie tego incydentu było poza naszą platformą. TO Incydent, który interesował przetwarzanie płatności Oney, został rozwiązany. Pochodzenie tego zdarzenia było zewnętrzne na naszej platformie.

3. 15 lipca 2025 12:05 UTCresolved

   Ten incydent został rozwiązany.

4. 17 lipca 2025 13:19 UTCpostmortem

   # Post Mortem **Usługa objęta** Pieniądze. **Klient wpływu** Całkowita niedostępność średniej płatności Oney. **Syntezę incydentu** * **14 lipca 00h01**: **początek incydentu** przed uczestnikiem** . ** * **14 lipca 01h56**: oświadczenie o incydencie przez uczestników** . ** * **15 lipca 10h23**: **koniec incydentu**. **Konteksto** NIE DOTYCZY **Przyczyna korzenia** Niepowodzenie z partnerem. **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Późne wykrycie incydentu | Przegląd ostrzeżeń wprowadzonych do średniej opłaty Oney i modyfikacja ustawień w celu usunięcia rozliczenia. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Usługi płatnicze dotknięte incydentem** Pieniądze. **Wpływ klienta** Całkowita awaria metody płatności Oney. **Przegląd incydentów** * **14 lipca, 00:01 — rozpoczyna się incydent** u usługodawcy. * **14 lipca, 01:56 —** incydent zgłoszony przez usługodawcę. * **15 lipca, 10:23 — incydent rozwiązany. ** **Kontekst** NIE DOTYCZY **Przyczyna korzenia** Zakłócenie usług u partnera. **Działania do podjęcia przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | Opóźnione wykrycie incydentu. | Przegląd alertów związanych z metodą płatności Oney i dostosowanie parametrów w celu poprawy dokładności wyzwalania. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 4 lipca 2025 08:07 UTCidentified

   FR Zidentyfikowaliśmy problemy z przetwarzaniem płatności w Hosted Fields za pośrednictwem Shopify. Incydent jest w trakcie analizy. Zalecamy przejście na przekierowaną płatność w celu realizacji rozwiązania. EN Zidentyfikowaliśmy problemy z przetwarzaniem płatności za pomocą Hosted Fields za pośrednictwem Shopify. Incydent jest obecnie przedmiotem dochodzenia. W międzyczasie zalecamy przejście na przekierowaną płatność. TO Zidentyfikowaliśmy trudności podczas przetwarzania płatności za pośrednictwem Hosted Fields w Shopify. Incydent jest obecnie w fazie analizy. Zalecamy tymczasowe przejście do płatności przekierowanych w obliczu rozdzielczości.

2. 4 lipca 2025 08:57 UTCidentified

   TSR-1977 - Początek/ Start/Początek: 03/07/2025 18h30 CEST. - Fin/End /fine: Na bieżący/Bieżący/W toku. - Kategoria/Kategoria/Kategoria: Przetwórstwo produkcyjne - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Potwierdzająca/Do potwierdzenia/Da confermare. - Priorytet/Priorytet/Priorytet: P2. FR Dochodzenia są zawsze w toku. Wróciliśmy do ciebie stąd o godzinę. EN Dochodzenia wciąż trwają. Skontaktujemy się z tobą w ciągu godziny. TO Uczniowie są jeszcze na bieżąco. Skontaktujemy się z Tobą w ciągu jednej godziny.

3. 4 lipca 2025 09:37 UTCmonitoring

   TSR-1977 - Początek/ Start/Początek: 03/07/2025 18h30 CEST. - Płetwa/Koniec /finał: 04/07/2025 11h34 CEST. - Kategoria/Kategoria/Kategoria: Przetwarzanie produkcji - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Potwierdzająca/Do potwierdzenia/Da confermare. - Priorytet/Priorytet/Priorytet: P2. FR Zastosowano korektor umożliwiający przywrócenie usługi. Nadal obserwujemy powtórkę usługi. EN Zastosowano poprawkę, umożliwiającą przywrócenie usługi. Kontynuujemy monitorowanie odzyskiwania usług. TO Zastosowano poprawkę, która pozwoliła na przywrócenie usługi. Nadal monitorujemy odzyskiwanie usługi.

4. 4 lipca 2025 16:10 UTCresolved

   TSR-1977 - Początek/ Start/Początek: 03/07/2025 18h30 CEST. - Płetwa/Koniec /finał: 04/07/2025 16th 30 CEST. - Kategoria/Kategoria/Kategoria: Przetwórstwo produkcyjne - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Potwierdzająca/Do potwierdzenia/Da confermare. - Priorytet/Priorytet/Priorytet: P2. FR Obsługa została odnowiona o 11:30. Platforma ma nominalny przychód w stanie 16h30. Incydent jest rozwiązany. EN Usługa została przywrócona o 11.30 rano. Platforma powróciła do statusu nominalnego o godzinie 16.30. Incydent został rozwiązany. TO Usługa została przywrócona o 11:30. Platforma powraca w nominalnym stanie o 16:30. Incydent został rozwiązany.

5. 7 lipca 2025 18:02 UTCpostmortem

   _Wersja angielska poniżej_ _Wersja włoska poniżej # Poczta śmiertelna **Referencja incydentu** TSR-1977 **Usługa objęta** Wbudowana strona płatności\ (Hosted Fields\) w Shopify **Klient wpływu** Płatności dokonywane są za pośrednictwem zintegrowanej strony płatności\ (Hosted Fields\) w Shopify. **Syntezę incydentu** * **2 lipca 18h10**: **Początek incydentu**. * **3 lipca 9h37**: naprawa alertów o zakłóceniach na zintegrowanej stronie płatności\ (Hosted Fields\) w Shopify. * **3 lipca 9h42**: utworzenie wyższej incydentnej komórki. * **3 lipca 09h53-10h30**: wielokrotne działania w celu przywrócenia usługi. * **3 lipca o godz. 10h30**: przesyłanie poczty w Shopify. * **3 lipca 10h50: ** identyfikacja powiązanych błędów w certyfikacie. * **3 lipca 11h11: ** wyślij drugą wiadomość e-mail do Shopify z więcej szczegółami. * **3 lipca 11h15: ** test zakłada wyłączenie hasła certyfikatu. Test końcowy. * **3 lipca 11h28: ** wyłączenie hasła certyfikatu zweryfikowanego na wszystkich serwerach. **Powtórzenie usługi. ** * **3 lipca 11h30: ** wyślij trzecią pocztę do Shopify. * **3 lipca 11h30-15h: ** Trwają badania w celu przywrócenia weryfikacji certyfikatu. * **3 lipca 15h: ** porównanie przyczyny głównej. * **3 lipca 16h: ** Dodanie starego Certificate Authority i reaktywacja hasła certyfikatu na serwerze. Test końcowy. * **3 lipca o godzinie 1629: ** Dodanie starego urzędu certyfikatu i ponowne włączenie hasła certyfikatu na wszystkich serwerach. **Koniec incydentu. ** **Konteksto** Urząd certyfikacji ma na celu sprawdzenie tożsamości witryny internetowej i wydanie „certyfikatu numerycznego”, aby sprawdzić, czy ta witryna jest dobra, jaka jest właściwa. W 2024 roku Shopify poinformował nas o uruchomieniu nowego Certificate Authority, który zastąpi starszego, który wygasa 26 października 2025 r. W sierpniu 2024 r. uruchomiliśmy nowy Urząd Certyfikatu, który został wyłączony w grudniu 2024 r. **Przyczyna korzenia** Ponowne wykorzystanie starego Certificate Authority przez Shopify dotyczy incydentu, ponieważ zostało to wyłączone. **Działania prowadzone przez Payplug** ‌‌ | **Symptomy** | **Działanie** | | --- | --- | | Wyjaśnienia dotyczące unieważnienia starego urzędu certyfikatu\ (CA\) przez Payplug wiąże się z nowym uruchomieniem | Wyjaśnienia dotyczące przyczyny odwołania starego urzędu urzędowego. Systematyczna ochrona dawnych CA aż do daty wygaśnięcia. | | Późne wykrywanie incydentu. | Odchylenie w celu zmniejszenia ostrzeżeń specjalnych przy każdym parkowaniu płatności\ (nie ma wpływu ten incydent\), nie wskazując na niską część przepływu platformy. Popraw naprawę błędów związanych z certyfikatami, aby uzyskać bardziej precyzyjne ostrzeżenia w tym przypadku. | | Doskonałe dane sprawdzania przyczyny głównej | Uzyskaj natychmiastowy kontakt w Shopify, aby ułatwić dochodzenie. | ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-1977 **Usługi płatnicze dotknięte incydentem** Zintegrowana strona płatności\ (Hosted Fields\) na Shopify **Wpływ klienta** Płatności dokonane za pośrednictwem zintegrowanej strony płatności\ (Hosted Fields\) w Shopify nie powiodły się. **Przegląd incydentów** * **2 lipca, 18:10: początek incydentu. ** * **3 lipca o godz. 9:37: ** powiadomienie o zakłóceniach na zintegrowanej stronie płatności\ (Hosted Fields\) w Shopify. * **3 lipca, 9:42: ** utworzono grupę zadaniową ds. poważnych incydentów. * **3 lipca, 9:53 — 10:30: ** podjęto wiele działań odzyskiwania. * **3 lipca, 10:30: ** wiadomość e-mail z eskalacją wysłana do Shopify. * **3 lipca, 10:50: ** błędy zidentyfikowane jako związane z certyfikatem. * **3 lipca, 11:11: ** druga wiadomość e-mail wysłana do Shopify z dodatkowymi szczegółami. * **3 lipca, 11:15: ** test przeprowadzony przez wyłączenie walidacji certyfikatu — pomyślny test. * **3 lipca, 11:28: ** walidacja certyfikatu wyłączona na wszystkich serwerach — **Usługa przywrócona. ** * **3 lipca, 11:30: ** trzeci e-mail wysłany do Shopify. * **3 lipca, 11:30 — 15:00: ** trwające dochodzenia w celu bezpiecznego ponownego włączenia walidacji certyfikatu. * **3 lipca, 15:00: ** zrozumiano podstawową przyczynę. * **3 lipca, godz. 16:00: ** stary urząd certyfikacji\ (CA\) został ponownie dodany i walidacja certyfikatu ponownie aktywowana na jednym serwerze — pomyślny test. * **3 lipca, 16:29: ** stary certyfikat został ponownie dodany i walidacja certyfikatu ponownie aktywowana na wszystkich serwerach — **Koniec incydentu. ** **Kontekst** Certyfikat\ (CA\) weryfikuje tożsamość strony internetowej i wydaje certyfikat cyfrowy w celu potwierdzenia jej autentyczności. W 2024 roku Shopify poinformował nas o nowym CA, który zastąpi obecny, który wygasa 26 października 2025 r. Wdrożyliśmy nowy CA w sierpniu 2024 r., a stary wyłączyliśmy w grudniu 2024 r. **Przyczyna korzenia** Ponowne użycie starego urzędu certyfikacji przez Shopify po incydencie, chociaż wcześniej go dezaktywowaliśmy. **Działania do podjęcia przez Payplug** ‌ | **Objawy** | **Działanie** | | --- | --- | | Nieporozumienie w sprawie cofnięcia starego urzędu certyfikacji\ (CA\) przez Payplug po wdrożeniu nowego. | Wyjaśnij przyczyny cofnięcia. Systematyczne przechowywanie starego CA do daty ich wygaśnięcia. | | Opóźnione wykrywanie incydentów | Rozważ wdrożenie określonych alertów na przepływ płatności\ (łącznie z tym, którego dotyczy), nawet jeśli każdy z nich reprezentuje niewielką część ruchu na platformie. Ulepsz mechanizmy ostrzegania, aby dokładniej wykrywać problemy związane z certyfikatami. | | Czas na zrozumienie podstawowej przyczyny może zostać poprawiony. | Nawiąż kontakt awaryjny z Shopify, aby ułatwić przyszłe dochodzenia. | ==============WERSJA WŁOSKA ============== # Poczta śmiertelna **Informacja o incydentu** TSR-1977 **Zainteresowana usług** Zintegrowana strona płatności\ (Hosted Fields\) w Shopify **Przeznaczone dla klientów** Płatności dokonywane za pośrednictwem zintegrowanej strony płatności\ (Hosted Fields\) w Shopify zostały spowodowane błędem. **Podsumowanie incydentu** * **2 lipca, godz. 18:10: początek incydentu** * **3 lipca, godz. 09:37: ** Ujawniono nieprawidłowości na zintegrowanej stronie płatności\ (Hosted Fields\) w Shopify. * **3 lipca, godz. 09:42: ** aktywacja grupy zadaniowej o większym incydencie. * **3 lipca, 09:53 — 10:30: ** różne akcje próbują przywrócić usługę. * **3 lipca, godz. 10:30: ** pierwsza wiadomość o eskalacji wysłana do Shopify. * **3 lipca, godz. 10:50: ** Identyfikacja błędów związanych z certyfikatami. * **3 lipca, godz. 11:11: ** zgodnie z wiadomością do Shopify z dodatkowymi szczegółami. * **3 lipca, godz. 11:15: ** test wyłączający kontrolę certyfikatu — Wyłączenie pozytywne. * **3 lipca, godz. 11:28: ** wyłączenie kontroli certyfikatu na wszystkich serwerach — **Usługa przywrócona. ** * **3 lipca, godz. 11:30: ** trzecia wiadomość do Shopify. * **3 lipca, 11:30 — 15:00: ** kontynuacja analizy w celu ponownego uruchomienia kontroli certyfikatu. * **3 lipca, godz. 15:00: ** Identyfikacja przyczyny głównej. * **3 lipca, godz. 16:00: ** dodanie starego urzędu certyfikatu i ponowne uruchomienie kontroli certyfikatu na serwerze — Test bezpieczeństwa. * **3 lipca, godz. 16:29: ** Dodano starą wersję Certificate Authority i ponowne uruchomienie kontroli certyfikatu na wszystkich serwerach — **Koniec incydentu. ** **Kontesto** Urząd certyfikacji\ (CA\) ma na celu sprawdzenie tożsamości witryny internetowej i wydanie certyfikatu cyfrowego, który nie potwierdza autentyczności. W 2024 roku Shopify poinformował nas o przejściu do nowej Kalifornii, zastępując istniejącą, która zakończyła się 26 października 2025 r. Wdrożyliśmy nowy CA w sierpniu 2024 r., a starszy wyłączyliśmy w grudniu 2024 r. **Przyczyna korzenia** Ponowne użycie starego urzędu certyfikatu z części Shopify w następstwie incydentu, który ostatnio został przez nas wyłączony. **Działania do wdrażania z części Payplug** | **Sintomi** | **Akcja** | | --- | --- | | Niezrozumienie odwołania starego autorytetu Certificate Authority\ (CA\) z części Payplug po wydaniu nowego | Wywołaj motywy odwołania. Systematyczne przechowywanie starych CA aż do daty upadku. | | Wczesne wykrywanie incydentu. | Oceń aktywację określonych alertów według przebiegu płatności, również w przypadku niewielkiej części ruchu drogowego. Popraw alerty, aby łatwiej wykryć problemy z certyfikatem. | | Ulepszony czas na identyfikację przyczyny źródłowej | Uzyskaj kontakt w nagłych wypadkach w Shopify, aby ułatwić przyszłe wpisy. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 maja 2025 08:33 UTCmonitoring

   TSR-1723 - Początek/Start/Początek: 03/05/2025 - Fin/End /fine: Na bieżący/Bieżący/W toku. - Kategoria/Kategoria/Kategoria: Produkcja - Oney - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Zewnętrzna/Zewnętrzna/Zewnętrzna FR Zostaliśmy poinformowani o incydencie, który miał wpływ na wiele dokumentów finansowych Oney otwieranych między sobotą 3 maja a poniedziałkiem 5 maja. Wpływające pliki pozostają ostrożnie. Działania prowadzone są przez Oney w celu zlikwidowania tych plików, ale odrzucone transakcje nie mogą być ważniejsze z powodu złego przyjęcia finansowania. Trwają działania mające na celu unieważnienie przyjętych dokumentów finansowych związanych z odrzuconymi transakcjami. EN Zostaliśmy poinformowani o incydencie, który wpłynął na kilka wniosków o finansowanie Oney, otwartych między sobotą 3 maja a rankiem w poniedziałek 5 maja. Wnioski, których dotyczy problem, pozostały w stanie oczekującym. Oney pracuje obecnie nad odzyskaniem tych aplikacji, ale transakcje, które zostały już odrzucone, nie mogą być już zatwierdzone, nawet jeśli finansowanie zostało zatwierdzone. Trwają również działania mające na celu anulowanie zatwierdzonych wniosków finansowych powiązanych z odrzuconymi transakcjami. TO Byliśmy poinformowani o incydencie, który interesował się różnymi praktykami finansowania Oney otwartym między sobotą 3 maja a poniedziałkową matką 5 maja. Interesujące praktyki są bardzo ważne. Oney obecnie pracuje nad odzyskaniem tych praktyk, ale transakcje już nie mogą być już zweryfikowane, nawet jeśli finansowanie zostało zatwierdzone. W toku są również działania mające na celu unieważnienie zatwierdzonych praktyk finansowania powiązanych z zleconymi transakcjami.

2. 13 maja 2025 11:54 UTCresolved

   TSR-1723 - Początek/Start/Początek: 03/05/2025 - Fina/Koniec /dobra: 07/05/2025 - Kategoria/Kategoria/Kategoria: Produkcja - Oney - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Zewnętrzna/Zewnętrzna/Zewnętrzna FR Dokumenty związane z odrzuconymi transakcjami zostały anulowane, więc Twoi klienci zostaną odrzuceni. EN Wnioski o finansowanie związane z odrzuconymi transakcjami zostały anulowane. Twoi klienci otrzymają zwrot pieniędzy. TO Praktyki związane z zleconymi transakcjami są anulowane. Twoi klienci zostaną wycofani.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 10 kwietnia 2025 12:25 UTCidentified

   FR Niektóre płatności w sklepie realizowanych na terminalach PAX (protokół Nexo) zostały pobrane dwukrotnie dla Twoich klientów portatorów kart. Akcja dotycząca płatności zrealizowana 7 kwietnia. Anomalia została szybko zidentyfikowana i poprawna jest w toku. - Dotyczące marszarzy będą kontaktować się bezpośrednio. - Wszystkie podwójne zostaną automatycznie anulowane. - Zwroty będą realizowane bez żadnych działań wymaganych przez twoją część ani klientów. - Regulowanie będzie widoczne na rachunkach portów pod niskim poziomem. EN Niektóre płatności w sklepie dokonywane za pośrednictwem terminali PAX (protokół NEXO) były obciążane dwukrotnie od klientów posiadających karty. Większość z tych zduplikowanych transakcji miała miejsce 7 kwietnia. Problem został szybko zidentyfikowany, a poprawka jest obecnie wdrażana. - Poszkodowani sprzedawcy zostaną skontaktowani bezpośrednio. - Wszystkie zduplikowane opłaty zostaną automatycznie anulowane. - Zwroty pieniędzy będą przetwarzane bez żadnych działań wymaganych od Ciebie lub Twoich klientów. - Korekty wkrótce będą widoczne na kontach posiadaczy kart. TO Niektóre płatności dokonywane w sklepie na terminalach PAX (protokół Nexo) mogą zostać dodane dwukrotnie Twoim klientom. Największa część płatności została dokonana 7 kwietnia. Anomalia została zidentyfikowana i postępujemy z poprawką. - Zainteresowane osoby będą kontaktować się bezpośrednio. - Wszystkie podwójne dodanki zostaną automatycznie usunięte. - Walizki będą realizowane bez żadnych działań ze strony Twojej lub klientów. - Regolaryzacja będzie widoczna na bieżących kontach klientów w krótkim czasie.

2. 11 kwietnia 2025 12:26 UTCmonitoring

   FR Płatności w sklepach niedozwolonych zostaną anulowane najpóźniej 15 kwietnia 2025 r. Twoi klienci stracili, aby zapłacić te płatności na swoim koncie najpóźniej 16 kwietnia 2025 r. EN Płatności w sklepie, które zostały błędnie obciążone, zostaną anulowane najpóźniej do 15 kwietnia 2025 r. Dlatego Twoi klienci zobaczą zwroty za te płatności na swoim koncie nie później niż 16 kwietnia 2025 r. TO Płatności dokonane w błędnie dodanych sklepach zostaną anulowane w okresie, a nie później niż 15 kwietnia 2025 r. Twoi klienci zobaczą więc zwrot tych płatności na ich koncie od 16 kwietnia 2025 r., a nie później.

3. 14 kwietnia 2025 15:54 UTCmonitoring

   TSR-1610 - Początek/Start/Początek: 07/04/2025 - Fin/End /fine: Na bieżący/Bieżący/W toku. - Kategoria/Kategoria/Kategoria: Produkcja - Przetwórstwo. - Odpowiedzialność/Odpowiedzialność/Odpowiedzialność: Payplug. - Priorytet/Priorytet/Priorytet: P2. FR Opłaty w sklepach obciążonych niedozwolonymi zostały anulowane. Twoi klienci nie będą musieli zapłacić tych opłat na swoim koncie od 15 kwietnia 2025 r., w ramach operacji międzybankowych. EN Płatności w sklepie, które zostały błędnie obciążone, zostały anulowane. W związku z tym Twoi klienci będą widzieć zwroty tych płatności na swoich kontach bankowych od 15 kwietnia 2025 r., w zależności od czasu przetwarzania międzybankowego. TO Płatności dokonane w sklepach dodanych z powodu błędu zostały anulowane. Twoi klienci zobaczą więc zwrot tych płatności na swoim koncie bankowym od 15 kwietnia 2025 r., w zależności od czasu przetwarzania międzybankowego.

4. 17 kwietnia 2025 07:46 UTCresolved

   Ten incydent został rozwiązany.

5. 17 kwietnia 2025 07:47 UTCpostmortem

   # _Angielska wersja poniżej/Wersja włoska w calce_ # Post Mortem **Referencja incydentu** TSR-1610 **Usługa objęta** Nekso. **Klient wpływu** Wielokrotne wartości płatności dokonywane na terminalu PAX\ (protokół Nexo\). **Syntezę incydentu** * **07 kwietnia: ** Aktualizacja zarządzania stanami transakcji Nexo. * **08 kwiecień - 09h12: ** Pierwsza seria transakcji została zaktualizowana, ale jej status nie został zaktualizowany na „debitny”. **Początek incydentu. ** * **09 kwietnia: ** drugi okres tej samej serii transakcji, z powodu podwójnego rozbicia. Niektóre z tych transakcji zachowują niepoprawny status. * **10 kwietnia: ** kontroler rutynowej identyfikacji 5000 bitów w tropie. * **10 kwietnia - 09h30: ** utworzenie komórki kryzysowej dla większych zdarzeń. Rozpoczęcie dochodzeń. * **10 kwietnia - 11h43: ** Ręczna aktualizacja stanu w celu uniknięcia nowego przypadkowego uszkodzenia transakcji. * **10 kwietnia - 15h25: ** poprawne wydanie, aby zapewnić dobrą automatyczną aktualizację stanu transakcji. Wysyłanie listy transakcji do przesyłania do naszego zewnętrznego dostawcy. **Nominalna powtórka usługi. ** * **11 kwiecień - 08h43: ** Relacja wysłana do naszego zewnętrznego urządzenia. * **14 kwietnia - 17h: ** podsumowanie danych dla klientów VISA & CB. * **15 kwietnia - 17h: ** podsumowanie danych dla klientów MASTERCARD. **Koniec incydentu. ** ‌ **Konteksto** Anulacja podwójnego bitu zbliżającego się do obrotów wewnętrznych jest ręczną i rozsądną operacją. Nasz wykonawca przyznał wszystkie niezbędne środki ostrożności, aby nie generować zrzeszonych domenów, co wyjaśnia obserwowane przez Ciebie uwagi. **Przyczyna korzenia** Incydent został spowodowany przez dodanie procesu aktualizacji stanu transakcji 7 kwietnia. Ten ostatni może okazjonalnie wejść w konflikt z istniejącym procesem, powodując aktualizację odnośnych transakcji. **Działania prowadzone przez Payplug** | **Symptomy** | **Działanie** | | --- | --- | | Późne wykrywanie podwójnych rozmiarów | Aktualizacja zamiast codziennego ręcznego monitorowania. Automatyzacja monitorowania średnioterminowego. | | Brak naprawy błędów w trakcie procesu | Aktualizacja zamiast dziennika\ + ostrzeżenia o zmianie stanu transakcji. Ulepszenie ponownej próby, aby automatycznie przywrócić aktualizację stanu. | | Nie wykryto błędu podczas fazy testowej. | Dodawanie systemowych testów do większego wolumenu transakcji. Badania nad nowymi testami ładowania. | ‌ ============ WERSJA ANGIELSKA ============== # Post Mortem **Odniesienie do incydentu** TSR-1610 **Usługi płatnicze dotknięte incydentem** Nekso. **Wpływ klienta** Wiele płatności pobranych z terminali PAX\ (protokół Nexo\). **Przegląd incydentów** * **7 kwietnia: ** aktualizacja zarządzania stanem transakcji Nexo. * **8 kwietnia — 9:12: ** pierwsza partia transakcji jest obciążana, ale ich status nie jest aktualizowany na „obciążone”. ** Incydent się zaczyna. ** * **9 kwietnia: ** następuje drugie obciążenie tej samej partii transakcji, powodując duplikaty opłat. Niektóre z tych transakcji zachowują niepoprawny status. * **10 kwietnia: ** rutynowa kontrola ujawnia 5000 nadwyżek obciążeń. * **10 kwietnia — 9:30: ** utworzono grupę zadaniową ds. poważnych incydentów. Rozpoczyna się analiza. * **10 kwietnia — 11:43: ** ręczna aktualizacja statusów, aby zapobiec dalszym przypadkowym obciążeniom. * **10 kwietnia — 15:25: ** dostarczenie poprawki zapewniającej prawidłową automatyczną aktualizację statusów transakcji. Lista transakcji do zwrotu jest wysyłana do naszego zewnętrznego dostawcy. ** Powrót do normalnej obsługi. ** * **11 kwietnia — 8:43: ** kontynuacja wysyłana do naszego zewnętrznego dostawcy. * **14 kwietnia — 17h: ** cofnięcie nieuzasadnionych opłat dla klientów VISA i CB. * **15 kwietnia — 17h: ** cofnięcie nienależnych opłat dla klientów. ** Koniec incydentu. ** ‌ **Kontekst** Odwrócenie duplikatu obciążenia i zwrot nienależnej opłaty jest operacją ręczną i delikatną. Nasz dostawca podjął wszelkie niezbędne środki ostrożności, aby uniknąć szkód ubocznych, co wyjaśnia obserwowane opóźnienie. **Przyczyna korzenia** Incydent został spowodowany dodaniem procesu aktualizacji statusu transakcji w kwietniu 7. Proces ten może czasami kolidować z istniejącym, uniemożliwiając aktualizację statusu transakcji, których dotyczy problem. ‌ **Działania do podjęcia przez Payplug** | **Objawy** | **Działanie** | | --- | --- | | Późne wykrywanie duplikatów obciążeń. | Wdrożenie krótkoterminowego codziennego monitorowania ręcznego. Średniookresowa automatyzacja monitoringu. | | Brak informacji zwrotnych o błędach podczas konfliktu procesu. | Implementacja rejestrowania\ + alert w przypadku konfliktu aktualizacji stanu. Poprawa logiki ponownej próby w celu automatycznej próby ponownej aktualizacji statusu. | | Niewykryty błąd podczas fazy testowania. | Systematyczne dodawanie testów z większymi ilościami transakcji. Badanie nowych metod testowania obciążenia. | ‌ ==============WERSJA WŁOSKA ============== # Poczta śmiertelna **Informacja o incydentu** TSR-1610 **Zainteresowana usług** Nekso. **Zaimponowany klientem** Dodaj wiele efektów do terminala PAX\ (protokół Nexo\). **Podsumowanie incydentu** * **7 kwiecień**: aktualizacja zarządzania stanami transakcji Nexo. * **8 kwietnia — 09:12**: pierwsza seria transakcji zostanie dodana, ale stan płatności nie jest zaktualizowany do „dodany”. **Początek incydentu. ** * **9 kwiecień**: drugi dodatek tej samej serii transakcji, powodując podwójny dodatek. Niektóre z tych transakcji wiążą się z błędem państwa. * **10 kwiecień**: indywidualna kontrola rutynowa obejmuje 5.000 dodatkowych osób. * **10 kwietnia — 09:30 **: utworzenie grupy zadaniowej w przypadku większych zdarzeń. Początek wniosków. * **10 kwietnia — 11:43**: ręczna aktualizacja stanów, aby uniknąć innych przypadkowych dodatków. * **10 kwietnia — 15:25**: Wyświetlenie poprawki w celu zagwarantowania prawidłowej automatycznej aktualizacji stanów transakcji. Wyślij listę transakcji do zwrotu do naszego zewnętrznego dostawcy. **Przywrócenie usługi. ** * **11 kwietnia — 08:43**: wysłane do zewnętrznego dostawcy. * **14 kwietnia — 17:00 **: Anulowanie nielegalnych dodatków dla klientów VISA i CB. * **15 kwietnia — 17:00 **: Anulowanie nielegalnych dodatków dla klientów MASTERCARD. **Do końca incydentu. ** ‌ **Kontesto** Anulowanie podwójnego dodatku i uzyskanie zwrotu jest ręczną i delikatną operacją. Nasz dostawca zastosował wszystkie niezbędne środki ostrożności, aby uniknąć uszkodzeń zabezpieczeń, które śledzą obserwowany powrót. **Przyczyna korzenia** Incydent został spowodowany przez dodanie, 7 kwietnia, procesu aktualizacji stanów transakcji. Ten nowy proces może czasami wiązać się z istniejącym procesem, uniemożliwiając aktualizację zainteresowanych transakcji. ‌ **Akcje do wdrażania przez Payplug** | **Sintomi** | **Akcja** | | --- | --- | | Wczesne wykrywanie dwóch dodanych | Krótkoterminowe wdrażanie codziennego ręcznego monitorowania. Automatyzacja monitorowania w średnim terminie. | | Brak zaznaczania błędów w przypadku konfliktu między procesami. | Implementacja dziennika\ + alarmu w przypadku wystąpienia błędu podczas aktualizacji stanu transakcji. Poprawa logiki ponownej próby w celu ponownego spróbowania aktualizacji stanu. | | Błąd nie wykryty podczas testów | Dodano systematykę testową o większej objętości transakcji. Analiza nowych testów obciążenia. |

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.