Wstęp
Zakres PCI to zbiór osób, procesów, technologii i komponentów systemu, które należy wziąć pod uwagę przy ocenie zgodności ze standardem PCI DSS.
Jeśli klient wpisze numer karty do formularza obsługiwanego i przetwarzanego przez Twoją aplikację, wówczas Twój interfejs użytkownika, zaplecze systemu, sieć, dzienniki, narzędzia monitorujące i usługi połączone mogą stać się istotne dla środowiska danych posiadacza karty.
Jeśli zamiast tego pola wrażliwe pochodzą bezpośrednio od sprawdzonego dostawcy usług płatniczych, a szczegóły karty są przesyłane z przeglądarki klienta do tego dostawcy z pominięciem Twojego zaplecza, Twoje narażenie znacznie spada.
Dlatego właśnie architektura ma znaczenie od samego początku.
Dobra integracja bramki płatniczej powinna pomóc Ci odpowiedzieć na pytania takie jak:
- Gdzie po raz pierwszy pojawia się numer karty?
- Która firma obsługuje pola płatnicze?
- Czy nasza aplikacja faktycznie potrafi odczytać dane karty?
- Czy dane wrażliwe pojawiają się w zapytaniach, logach, analizach lub narzędziach wsparcia?
- Co przechowujemy po dokonaniu płatności?
- Kto ma dostęp do panelu dostawcy płatności?
- Jak udowodnić zamierzony przepływ danych podczas przeglądu zgodności?
Poniżej przedstawiono główne techniki redukcji zakresu i wzorce architektury, na których się opierają.
Dlaczego zmniejszenie zakresu PCI ma znaczenie
Dodanie płatności kartą do produktu rzadko kiedy jest tak proste, jak podłączenie API i umieszczenie formularza płatności na stronie.
W momencie, gdy Twoja aplikacja przechowuje, przetwarza lub przesyła dane posiadaczy kart, znacznie więcej zaczyna się liczyć. Systemy, ludzie, procesy, infrastruktura – wszystko to może zostać objęte Twoimi obowiązkami w zakresie PCI DSS.
To może obejmować architekturę aplikacji, infrastrukturę chmurową, mechanizmy kontroli bezpieczeństwa, zarządzanie dostępem, rejestrowanie, procedury programistyczne, zarządzanie dostawcami, dokumentację zgodności i przygotowanie do audytu. Zasadniczo, promień rażenia rośnie.
PCI DSS Określa wymogi techniczne i operacyjne mające na celu ochronę danych rachunków płatniczych. Jego zakres nie ogranicza się do systemów, które bezpośrednio przetwarzają dane kart. Może on również obejmować systemy, które mogą wpływać na bezpieczeństwo środowiska danych posiadaczy kart, a zasięg tego obszaru jest szerszy, niż większość zespołów się spodziewa.
Dla założycieli firm i liderów produktów praktyczny cel jest zazwyczaj prosty: nie dopuszczać do systemów surowych danych z kart, chyba że firma naprawdę ich potrzebuje.
Dobrze zaplanowana integracja zmniejsza liczbę komponentów, które trzeba ocenić, obniża ryzyko operacyjne i sprawia, że przyszłe przeglądy bezpieczeństwa są mniej uciążliwe. Nie zlikwiduje ona Twoich obowiązków związanych z PCI. Może jednak zapobiec przekształceniu się dość zwykłego procesu weryfikacji w duży projekt zgodności.
Redukcja zakresu PCI jest decyzją architektoniczną
Nie można ograniczyć zakresu PCI, dodając zdanie do polityki bezpieczeństwa po wysłaniu kodu. Zakres jest kształtowany przez sposób, w jaki faktycznie przesyłane są dane dotyczące płatności.
Dobrym punktem wyjścia będzie zmapowanie czterech etapów:
- Wprowadzanie danych – gdzie klient wprowadza dane karty?
- Przenoszenie – które systemy je obsługują?
- Przetwarzanie – jaka usługa to upoważnia?
- Składowanie – jakie informacje dotyczące płatności pozostają po transakcji?
Celem jest wąska, zrozumiała ścieżka, po której poufne dane karty trafiają bezpośrednio do zweryfikowanego dostawcy, podczas gdy Twoja aplikacja działa wyłącznie z odniesieniami niebędącymi poufnymi, takimi jak identyfikatory płatności, identyfikatory klientów lub tokeny.
Ta pojedyncza zasada stanowi podstawę wszystkich kolejnych działań: pól hostowanych, tokenizacji, przechowywania danych przez dostawców oraz izolacji komponentów płatności.
1. Korzystaj z hostowanych stron płatności, aby zapewnić maksymalną separację
Strona płatności hostowanych przekierowuje klienta z Twojej aplikacji do strony płatności obsługiwanej przez dostawcę.
Przepływ wygląda następująco:
- Twój system zaplecza tworzy sesję realizacji transakcji.
- Dostawca zwraca adres URL hostowanej płatności.
- Klient zostaje przekierowany na stronę dostawcy.
- Klient wprowadza tam dane swojej karty.
- Dostawca zajmuje się uwierzytelnianiem i autoryzacją.
- Twoja aplikacja otrzymuje wynik za pomocą przekierowania i webhooka.
- Twój system przechowuje numer referencyjny płatności i status firmy.
Twoja witryna nigdy nie zawiera formularza do wprowadzania karty, a Twoje zaplecze nigdy nie widzi numeru karty.
Często jest to najbardziej praktyczne rozwiązanie dla MVP, produktu subskrypcyjnego lub każdej firmy, dla której ważniejsze jest szybkie wprowadzenie produktu na rynek i ograniczenie konieczności przestrzegania przepisów niż kontrolowanie każdego piksela procesu realizacji transakcji.
Co zyskujesz: silne rozdzielenie aplikacji i wprowadzania danych kartą, szybsza implementacja, uwierzytelnianie obsługiwane przez dostawcę, aktualizacje płatności zarządzane przez dostawcę, mniejsze ryzyko przypadkowego zarejestrowania danych karty oraz łatwiejsza dokumentacja przepływu danych.
Z czego rezygnujesz: Klienci na krótko opuszczają interfejs (lub widzą ekran hostowany przez dostawcę), kontrola nad brandingiem i układem może być ograniczona, analiza konwersji może wymagać dodatkowej konfiguracji, a przepływy przekierowań i powrotów wymagają starannego testowania. Doświadczenie związane z finalizacją transakcji zależy również częściowo od dostawcy.
Standard PCI SSC opisuje SAQ A jako mający zastosowanie do kwalifikujących się sprzedawców bez konieczności fizycznej obecności karty, którzy w pełni zlecają funkcje związane z danymi konta zweryfikowanym podmiotom zewnętrznym i nie przechowują, nie przetwarzają ani nie przesyłają elektronicznie danych konta we własnych systemach. Nadal musisz potwierdzić kwalifikowalność do konkretnego wdrożenia i spełnić swoje obowiązki w zakresie walidacji.
Hostowana płatność nie jest więc wyłącznikiem “zgodności”. Nadal potrzebujesz nadzoru ze strony dostawcy, bezpiecznej administracji, udokumentowanych obowiązków i ochrony przed atakami, które mogłyby zakłócić proces płatności.
2. Użyj pól hostowanych, jeśli potrzebujesz natywnego sposobu realizacji transakcji
Pola hostowane znajdują się pomiędzy przekierowaniem a w pełni dostosowanym formularzem karty.
Strona płatności pozostaje w Twojej aplikacji, ale pola wrażliwe – numer karty, data ważności, kod bezpieczeństwa – obsługiwane są przez dostawcę płatności, zwykle za pośrednictwem oddzielnych ramek lub komponentów kontrolowanych przez dostawcę.
Twoja aplikacja nadal jest właścicielem otaczającego ją interfejsu: podsumowania produktu, danych klienta, adresu rozliczeniowego, kodu rabatowego, pól zgody, przycisku płatności i ekranu potwierdzenia. Dostawca jest właścicielem poufnych pól karty.
Typowy przepływ:
- Twój interfejs użytkownika ładuje bibliotekę płatności dostawcy.
- Dostawca wprowadza chronione pola kart do płatności.
- Klient wprowadza dane karty w te pola.
- Dane trafiają bezpośrednio do dostawcy.
- Dostawca zwraca token lub referencję do metody płatności.
- Twój interfejs użytkownika wysyła to odniesienie do zaplecza.
- Twój system używa tego odniesienia do rozpoczęcia lub potwierdzenia płatności.
Twój kod nigdy nie powinien być w stanie odczytać surowego numeru karty.
Dlaczego pola hostowane są popularne
Pola hostowane pozwalają zespołowi na prowadzenie procesu płatności z marką bez konieczności budowania własnego środowiska danych kart. Sprawdzają się one, gdy spójność procesu płatności ma znaczenie biznesowe, proces zakupu składa się z wielu etapów, potrzebna jest walidacja kontekstowa płatności, przekierowania powodowałyby zauważalne tarcia lub gdy potrzebna jest większa kontrola UX, a jednocześnie dane kart nie są udostępniane zapleczu.
Szczegóły implementacji nadal mają jednak znaczenie. Strona, która zawiera komponenty płatności kontrolowane przez dostawcę, nadal może wpływać na bezpieczeństwo transakcji. Norma PCI SSC rozróżnia w pełni outsourcingowe funkcje przetwarzania danych kart od środowisk e-commerce, które mogą wpływać na integralność strony płatności.
Potwierdź dokładną ścieżkę walidacji ze swoim dostawcą usług płatniczych, bankiem nabywającym, doradcą ds. zgodności lub kwalifikowanym audytorem bezpieczeństwa, jeśli ma to zastosowanie.
3. Zastąp numery kart tokenami
Tokenizacja polega na zamianie podstawowego numeru konta na wartość zastępczą – token – która działa wyłącznie w zatwierdzonym kontekście.
Zamiast przechowywać:
4111 1111 1111 1111
Twoja aplikacja przechowuje coś takiego:
pm_82HX9…
Token jest przydatny dla Twojej aplikacji, ale nie ujawnia oryginalnego numeru karty.
Wytyczne PCI SSC dotyczące tokenizacji jasno wskazują, że tokenizacja może mieć wpływ na zakres PCI DSS, ale rzeczywisty wynik zależy od implementacji, konfiguracji systemu, kontroli bezpieczeństwa i relacji między tokenem a oryginalnym numerem konta.
Do czego służą tokeny
Tokeny są powszechnie używane do płatności dla powracających klientów, odnawiania subskrypcji, realizacji płatności jednym kliknięciem, opóźnionych opłat, zwrotów pieniędzy, depozytów, rozliczeń opartych na użytkowaniu, transakcji na rynkach i procesów wymiany kart.
W bazie danych mogą być przechowywane następujące dane: identyfikator klienta dostawcy, token metody płatności, marka karty, cztery ostatnie cyfry, miesiąc i rok ważności, status płatności, identyfikator transakcji dostawcy oraz odniesienia do zgód lub upoważnień.
Baza danych nigdy nie powinna zawierać pełnego numeru karty, kodu weryfikacyjnego karty, danych z paska magnetycznego, kodu PIN lub bloku kodu PIN ani surowych danych dostawcy zawierających poufne dane uwierzytelniające.
Błędy tokenizacji, których należy unikać
Token nie jest automatycznie bezpieczny tylko dlatego, że ktoś nadał mu nazwę zmiennej `token`. Potwierdź, że:
- Dostawca generuje token.
- Nie można tego odwrócić za pomocą systemów, które kontrolujesz.
- Dostęp do skarbca dostawcy jest ograniczony.
- Tokeny są ograniczone do zamierzonego kontekstu handlowego lub integracyjnego.
- Rejestry nie zawierają szczegółów oryginalnej karty.
- Narzędzia wsparcia wyświetlają tylko zamaskowane informacje.
- Tokeny testowe i produkcyjne pozostają oddzielone.
- Ładunki webhooków są sprawdzane przed zarejestrowaniem czegokolwiek.
4. Pozwól dostawcy na przechowywanie danych karty
Sejf płatności bezpiecznie przechowuje dane uwierzytelniające płatności i przekazuje informacje, z których Twoja aplikacja może korzystać w przyszłych transakcjach.
W przypadku większości produktów to dostawca, a nie sprzedawca, powinien zarządzać sejfem. Budowanie własnego sejfu oznacza konieczność przejęcia odpowiedzialności za szyfrowanie, zarządzanie kluczami, segmentację sieci, kontrolę dostępu, monitorowanie, zarządzanie lukami w zabezpieczeniach, przechowywanie danych, reagowanie na incydenty, bezpieczne usuwanie danych i gromadzenie dowodów audytowych. Dla większości startupów i rozwijających się firm cyfrowych posiadanie takiej infrastruktury wiąże się z niewielkimi korzyściami komercyjnymi.
Sejf zarządzany przez dostawcę zapewnia przejrzysty podział: dostawca przechowuje dane uwierzytelniające karty, a Twój produkt przechowuje dane referencyjne dostawcy. To rozwiązanie sprawdza się szczególnie dobrze w przypadku platform subskrypcyjnych, platform handlowych, produktów do rezerwacji hoteli, aplikacji mobilnych i wszystkiego innego, co wymaga płatności w przyszłości lub poza sesją.
Zanim wybierzesz rozwiązanie w postaci sklepienia, upewnij się, że:
- Czy metody płatności można wykorzystywać wielokrotnie w różnych kanałach?
- Czy tokeny są ograniczone do jednego konta handlowego?
- Co się stanie, jeśli zmienię dostawcę?
- Czy dane uwierzytelniające można migrować?
- Jak postępować z kartami, które straciły ważność lub zostały wymienione?
- Które strony mogą wnosić oskarżenia w przyszłości?
- Jakie dowody zgody klienta należy zachować?
- W jaki sposób dostawca obsługuje prośby o usunięcie?
- Co jest widoczne w eksportowanych raportach i pulpitach nawigacyjnych?
Uzależnienie od dostawcy jest tutaj istotnym problemem architektonicznym. Magazyn dostawcy może ograniczyć zakres zgodności, jednocześnie utrudniając przyszłą migrację, więc traktuj to jako świadomy kompromis i zapisz go.
5. Wyizoluj komponenty płatności od reszty produktu
Nawet jeśli surowe dane dotyczące kart nigdy nie dotrą do Twoich systemów, warto gromadzić informacje o płatnościach w jednym miejscu.
Nie rozpraszaj kodu specyficznego dla bramki płatniczej na front-end, back-end, panel administracyjny, usługę zamówień, usługę powiadomień i warstwę raportowania. Zamiast tego nakreśl wyraźną granicę płatności.
Praktyczny model usług płatniczych
Dedykowana usługa lub moduł płatniczy może odpowiadać za tworzenie sesji realizacji transakcji i zamiarów płatności, wymianę bezpiecznych referencji płatności, mapowanie statusów dostawców na statusy wewnętrzne, weryfikację podpisów webhooków, przetwarzanie idempotentnych zdarzeń webhooków, inicjowanie zwrotów, przechowywanie referencji transakcji dostawców, rejestrowanie zdarzeń audytu i obsługę uzgadniania.
Inne moduły po prostu wywołują polecenia wewnętrzne:
- utwórzPłatność
- potwierdźZamówieniePłatność
- zwrotPłatność
- pobierzStatusPłatności
Nie powinni musieć rozumieć każdego obiektu specyficznego dla bramy.
Nie spowoduje to automatycznego usunięcia komponentów z zakresu PCI, ale poprawi kontrolę, przejrzystość i łatwość konserwacji. Znacznie ułatwia również zmianę dostawcy, dodanie metody płatności lub przeprowadzenie audytora przez proces.
Więcej informacji na temat niezawodnego wykonywania płatności znajdziesz w naszym lista kontrolna wdrożenia bramki płatniczej i nasz artykuł na temat webhooki i idempotentność.
Trzy praktyczne wzorce architektoniczne
Wzorzec A: przekierowana płatność hostowana
Najlepiej sprawdza się w przypadku produktów MVP, SaaS, prostych rozwiązań e-commerce i zespołów, które chcą po prostu wysyłać produkty i usługi.
Przepływ: Klient → Twoja aplikacja → płatność hostowana u dostawcy → dostawca płatności → webhook → Twoje zaplecze.
Twoje systemy przechowują identyfikator sesji płatności, identyfikator zamówienia, status płatności, kwotę i walutę oraz identyfikator transakcji dostawcy.
Główna zaleta: wprowadzanie karty odbywa się poza aplikacją. Główna wada: mniejsza kontrola nad wyglądem i nawigacją kasy.
Wzorzec B: osadzone pola hostowane z tokenizacją
Najlepiej nadaje się do realizacji zakupów w Internecie, zakupów dostosowanych do urządzeń mobilnych i produktów wymagających kontroli UX.
Przepływ: Klient → Twoja strona płatności → pola hostowane przez dostawcę → token dostawcy → Twoje zaplecze → dostawca płatności.
Twoje systemy przechowują token metody płatności, numer referencyjny klienta, zamaskowane metadane karty, status transakcji i powiązanie zamówienia.
Główna zaleta: natywnie wyglądająca strona płatności bez konieczności przetwarzania danych karty przez zaplecze. Główny kompromis: Twoja strona nadal może wpływać na bezpieczeństwo transakcji, więc bezpieczeństwo front-endu i dowody wdrożenia nadal mają znaczenie.
Wzorzec C: warstwa koordynacji płatności
Najlepiej sprawdza się w przypadku rynków, produktów dostępnych w wielu krajach, platform o dużej objętości i firm korzystających z usług więcej niż jednego dostawcy.
Przepływ: Klient → hostowany komponent płatności → usługa abstrakcji płatności → wybrany dostawca → webhooki → warstwa uzgadniania.
Twoje systemy przechowują wewnętrzny identyfikator płatności, token specyficzny dla dostawcy, decyzję o routingu, znormalizowany status płatności oraz odniesienia do rozliczeń i uzgodnień.
Główna korzyść: niezależność dostawcy i scentralizowana logika płatności. Główny kompromis: większa złożoność architektoniczna i operacyjna.
Jedno ostrzeżenie: Warstwa abstrakcji nadal powinna unikać surowych danych kart. Jej zadaniem jest koordynacja bezpiecznych referencji, statusów i interfejsów API dostawców, a nie stanie się nowym centrum danych kart.
Gdzie redukcja zakresu zwykle kończy się niepowodzeniem
Rejestrowanie kompletnych żądań
Bezpieczny formularz płatności może zostać anulowany, jeśli treści żądań, zdarzenia przeglądarki lub odpowiedzi dostawcy zostaną automatycznie zapisane w logach. Użyj filtrowania pól, ustrukturyzowanego logowania i jawnych list dozwolonych.
Wysyłanie pól płatności do analityki
Narzędzia do odtwarzania sesji, narzędzia do śledzenia błędów, mapy cieplne, menedżery tagów i skrypty analityczne – wszystkie te elementy wymagają dokładnego sprawdzenia na stronach płatności. Przetestuj maskowanie. Nie zakładaj, że działa.
Umożliwienie pomocy technicznej poproszenia o dane karty
Agenci wsparcia nigdy nie powinni prosić klientów o przesłanie pełnych numerów kart ani kodów bezpieczeństwa na czacie, w wiadomościach e-mail, na zrzutach ekranu ani w załącznikach do zgłoszeń. Zamiast tego należy opracować zatwierdzony proces oparty na identyfikatorach transakcji i zamaskowanych metadanych.
Przechowywanie surowych ładunków webhook na zawsze
Archiwa webhooków ułatwiają debugowanie, ale należy dokładnie wiedzieć, co wysyła każdy dostawca. Przechowuj tylko to, czego potrzebujesz, i stosuj kontrolę dostępu oraz reguły przechowywania.
Mieszanie testów i produkcji
Klucze testowe, klucze produkcyjne, tajne hasła webhooków i konta dostawców powinny być wyraźnie oddzielone, a dostęp do nich powinien następować po uzyskaniu jak najmniejszych uprawnień.
Traktowanie tokenizacji jako pełnego outsourcingu
Token ogranicza bezpośredni dostęp do numeru karty. Nie zwalnia Cię jednak z odpowiedzialności za dostęp, bezpieczeństwo integracji, zarządzanie dostawcami, bezpieczny rozwój ani reagowanie na incydenty.
Zakładając, że dostawca zapewnia zgodność z przepisami
Korzystanie z usług sprawdzonego dostawcy jest pomocne, ale PCI SSC wyraźnie zaznacza, że wybór produktu lub rozwiązania z listy nie oznacza automatycznie, że organizacja spełnia wymogi. Nadal obowiązuje niezależna ocena i należyta staranność.
Lista kontrolna dokumentacji zakresu PCI
Dobra architektura wymaga dokumentacji. Przygotuj co najmniej następujące elementy.
1. Diagram przepływu danych płatniczych. Pokaż przeglądarkę klienta lub aplikację mobilną, interfejs sprzedawcy, hostowane pola lub stronę przekierowania, zaplecze sprzedawcy, dostawcę płatności, webhooki, bazy danych, logi, narzędzia administracyjne, systemy wsparcia i usługi analityczne. Zaznacz miejsca, w których przesyłane są dane kart, tokeny, identyfikatory transakcji i zamaskowane metadane.
2. Inwentaryzacja systemu. Wymień wszystkie komponenty zaangażowane w płatności lub z nimi połączone: aplikacje, usługi w chmurze, bazy danych, kolejki, platformy rejestrujące, narzędzia monitorujące, systemy CI/CD, narzędzia wsparcia i skrypty stron trzecich.
3. Rejestr klasyfikacji danych. Udokumentuj, które pola zawierają dane posiadacza karty, poufne dane uwierzytelniające, tokeny, zamaskowane metadane płatności, dane osobowe lub dane transakcji operacyjnych.
4. Macierz odpowiedzialności. Określ, kto jest odpowiedzialny za gromadzenie danych kart, tokenizację, przechowywanie ich w sejfach, uwierzytelnianie, autoryzację, sprawdzanie pod kątem oszustw, dostarczanie webhooków, przetwarzanie zwrotów, powiadamianie o incydentach i dowody zgodności.
5. Dowody zgodności usługodawcy. Zachowaj nazwę dostawcy i opis usługi, aktualną dokumentację zgodności, warunki umowy i przetwarzania danych, informacje o wspólnej odpowiedzialności, odpowiednią konfigurację usługi oraz daty przeglądu i odnowienia.
6. Rejestry kontroli dostępu. Udokumentuj, kto może uzyskać dostęp do panelu płatności, jakie role mogą dokonywać zwrotów, czy wymuszone jest uwierzytelnianie wieloskładnikowe, w jaki sposób dostęp jest zatwierdzany i usuwany oraz w jaki sposób sprawdzana jest aktywność uprzywilejowana.
7. Zabezpiecz dowody konfiguracji. Rejestruj ustawienia hostowanych komponentów, dozwolone domeny, przekierowania URL-i, punkty końcowe webhooków, weryfikację podpisów webhooków, przechowywanie tajnych informacji, separację środowiskową, filtry rejestrowania i zasady bezpieczeństwa treści, tam gdzie ma to zastosowanie.
8. Testowanie dowodów. Uwzględnij wyniki dotyczące pomyślnych płatności, odrzuceń, wyzwań związanych z uwierzytelnianiem, przekroczeń limitu czasu, zduplikowanych przesłań, wygasłych sesji, ponownych prób wykonania webhooków, zwrotów pieniędzy, sporów, przerwanych przekierowań, analiz i kontroli rejestrowania oraz testów dymnych w środowisku produkcyjnym.
9. Proces reagowania na incydenty. Zdefiniuj, co się stanie, jeśli dane karty pojawią się w dzienniku, strona płatności zostanie zmodyfikowana, klucz płatności wycieknie, konto dostawcy zostanie naruszone, pojawi się podejrzany skrypt lub agent pomocy technicznej otrzyma dane karty.
10. Zapis przeglądu zakresu. Przejrzyj architekturę za każdym razem, gdy dodasz bramkę płatności, zastąpisz hostowaną kasę niestandardowym interfejsem użytkownika, dodasz zapisane karty, wprowadzisz subskrypcje, dodasz wypłaty z rynku, zainstalujesz nowy skrypt kasy, zmienisz analizę lub monitorowanie, przeniesiesz infrastrukturę lub dodasz przepływy płatności mobilnych.
Zakres PCI nie jest zamrożony. Zmiany w produkcie powodują jego przesunięcie.
Jak Appricotsoft podchodzi do redukcji zakresu PCI
W Appricotsoft traktujemy kwestie zgodności architektury z przepisami jako decyzję dotyczącą produktu, a nie zadanie audytowe, które można odłożyć do momentu premiery.
Realizując prace integracyjne z bramkami płatniczymi, zaczynamy od zmapowania planowanej ścieżki płatności i znalezienia najprostszej architektury, która nadal spełnia cel biznesowy. W praktyce oznacza to:
Wyjaśnienie modelu płatności. Sprawdzamy, czy produkt wymaga płatności jednorazowych, subskrypcji, depozytów, zapisanych metod płatności, zwrotów, płatności za pośrednictwem platformy rynkowej czy obsługi wielu dostawców.
Wybór właściwego wzorca integracji. Bierzemy pod uwagę hostowane płatności, hostowane pola, mobilne zestawy SDK, interfejsy API po stronie serwera i orkiestrację w kontekście kontroli UX, szybkości dostarczania, bezpieczeństwa i wpływu na zgodność.
Nie udostępniaj aplikacji surowych danych z karty. Zawsze, gdy jest to praktyczne, opieramy się na komponentach kontrolowanych przez dostawcę, tokenizacji i repozytorium dostawców.
Ustalanie wyraźnych granic. Obowiązki płatnicze są zawarte w przejrzystych interfejsach i nie są rozproszone po całym produkcie.
Budowanie niezawodności operacyjnej. Weryfikacja webhooków, idempotentność, mapowanie statusów, obsługa błędów, monitorowanie i uzgadnianie są częścią integracji, a nie czyszczenia po uruchomieniu.
Tworzenie dokumentacji, z której ludzie faktycznie korzystają. Schemat architektury, dziennik decyzji, obowiązki, ryzyka i lista kontrolna wersji pozostają widoczne przez cały czas dostawy.
Pasuje to do naszego Unison Framework: Klient jest odpowiedzialny za priorytety i decyzje, nasz zespół odpowiada za myślenie o produkcie i dyscyplinę realizacji, a narzędzia AI wspierają wydajność, nie zastępując ludzkiej odpowiedzialności. Cotygodniowe demonstracje i współdzielone artefakty dostaw pozwalają klientom zobaczyć działające przepływy płatności, zrozumieć kompromisy i skorygować założenia, zanim staną się one kosztowne.
Nie chodzi o teatr zgodności. Chodzi o oprogramowanie, które jest łatwiejsze w obsłudze, łatwiejsze do wyjaśnienia i godne zaufania.
Często zadawane pytania
Czy korzystanie z bramki płatniczej zwalnia z obowiązków PCI DSS?
Nie. Może to ograniczyć liczbę systemów przetwarzających dane kart, ale nadal masz obowiązki związane z integracją, zarządzaniem dostawcami, kontrolą dostępu, procesami bezpieczeństwa i stosowną walidacją.
Czy pola hostowane to to samo, co tokenizacja?
Nie. Pola hostowane kontrolują sposób gromadzenia i przesyłania danych kart. Tokenizacja zastępuje numer karty referencją, której można użyć po zebraniu danych. Często są one używane razem.
Czy możemy przechowywać cztery ostatnie cyfry karty?
Zamaskowane metadane kart są zazwyczaj zwracane przez dostawców i wykorzystywane do rozpoznawania i obsługi klienta. Sprawdź, czy Twoje dokładne zasady przechowywania i wyświetlania są zgodne z obowiązującymi wymaganiami i wytycznymi dostawcy.
Czy powinniśmy zbudować własny sejf na karty?
W przypadku większości produktów – nie. Sejf zarządzany przez dostawcę jest zazwyczaj bezpieczniejszy i bardziej praktyczny, a stworzenie własnego wiąże się ze znacznymi obowiązkami w zakresie bezpieczeństwa, obsługi i zgodności.
Czy mobilny zestaw SDK zmniejsza zakres PCI?
Jest to możliwe, gdy wrażliwe dane kart są gromadzone i przesyłane za pośrednictwem komponentów kontrolowanych przez dostawcę. Rzeczywisty wpływ zależy od zestawu SDK, implementacji, systemów towarzyszących i kryteriów walidacji.
Czy dane tokenizowane mogą pojawić się w naszych logach?
Token może być bezpieczny pod względem operacyjnym do logowania w niektórych kontekstach, ale należy ograniczyć do minimum rejestrowanie. Tokeny, identyfikatory klientów, identyfikatory transakcji i metadane mogą być poufne i w połączeniu z dostępem do konta mogą umożliwiać nieautoryzowane działania.
Kto decyduje, który SAQ ma zastosowanie?
Potwierdź swoje obowiązki w zakresie walidacji z bankiem nabywającym, dostawcą usług płatniczych, markami płatniczymi, doradcą ds. zgodności lub kwalifikowanym audytorem bezpieczeństwa, w zależności od przypadku.
Wniosek
Ograniczanie zakresu PCI zaczyna się od jednego pomysłu: zaprojektuj przepływ płatności w taki sposób, aby surowe dane karty nigdy nie trafiały do Twojej aplikacji.
Hostowane strony płatności zapewniają najsilniejszą separację. Hostowane pola dają większą kontrolę, jednocześnie umożliwiając zarządzanie poufnymi danymi przez dostawcę. Tokenizacja pozwala systemowi korzystać z bezpiecznych referencji, a przechowywanie danych przez dostawcę obsługuje przyszłe płatności bez konieczności uruchamiania środowiska przechowywania kart.
Izolacja musi jednak wykraczać poza formularz zamówienia. Rejestrowanie, analityka, przepływy pracy wsparcia, administracja, webhooki, zarządzanie dostępem i dokumentacja – wszystkie te elementy wpływają na bezpieczeństwo produktu końcowego.
Najlepsza architektura płatności zazwyczaj nie jest najbardziej imponująca technicznie. To taka, która pasuje do modelu biznesowego, a jednocześnie kontroluje ryzyko, nakłady na zapewnienie zgodności i złożoność operacyjną.
W Appricotsoft, Pomagamy założycielom i zespołom produktowym wybierać, projektować i tworzyć integracje płatności, które są bezpieczne, zrozumiałe i gotowe do użycia w praktyce.
Planujesz realizację transakcji, proces subskrypcji, platformę handlową lub produkt fintech? Zdefiniujmy odpowiednią architekturę zanim zostanie wdrożony niepotrzebny zakres PCI.
