W SSL stosowany jest algorytm RSA. Każdy serwer akceptujący "bezpieczne" połączenia WWW (adresy tego typu stron można poznać po tym, iż zaczynają się od przedrostka "https://" zamiast "http://") posiada swój klucz publiczny, który wysyła przeglądarce nawiązującej z nim połączenie. Przeglądarka generuje losowy klucz sesji dla szyfru RC2 lub RC4, i wysyła go do serwera zaszyfrowany otrzymanym kluczem publicznym. Od tego momentu cała dalsza wymiana informacji między serwerem i przeglądarką jest szyfrowana (przeglądarka Netscape sygnalizuje taką sytuację wyświetleniem niebieskiego obramowania powyżej oglądanej strony oraz rysunku klucza u dołu ekranu).
Zdecydowana większość sieciowych sklepów, w których używa się numeru karty kredytowej, korzysta aktualnie z SSL. Z reguły przeglądanie zawartości witryny i wybór towarów do zakupu odbywa się zwykłym (nieszyfrowanym) protokołem HTTP; dopiero końcowy formularz zamówienia, w którym trzeba wpisać dane karty kredytowej, przekazywany jest w sposób "bezpieczny". Warto zauważyć, że "bezpieczeństwo" to może być dosyć iluzoryczne w przypadku korzystania z powszechnie dostępnych w Internecie tzw. eksportowych wersji przeglądarek WWW, które używają 40-bitowego klucza sesji, nie dającego - jak o tym wspominałam w poprzednim artykule - praktycznie żadnej ochrony przed kimś chcącym ten szyfr złamać. Prawdziwe bezpieczeństwo zapewniają dopiero wersje przeglądarek przeznaczone na wewnętrzny rynek amerykański, używające klucza 128-bitowego; ich eksport z USA jest jednak nielegalny, stąd też nie są one publicznie udostępniane w Internecie. Lepsze jednak nawet słabe szyfrowanie niż jego zupełny brak; pod warunkiem oczywiście, że mamy świadomość jego słabości.
System SSL rozwiązuje także niejako "przy okazji" problem weryfikacji sprzedawcy. Serwer stosujący protokół SSL nie tylko bowiem musi posiadać swój klucz publiczny, ale na dodatek klucz ten musi być certyfikowany przez jeden ze znanych przeglądarce tzw. urzędów certyfikacyjnych (certification authorities, CA). Takie urzędy certyfikacyjne prowadzi kilka firm upoważnionych przez RSA Data Security Inc. - właściciela algorytmu. Firma chcąca wykorzystywać na swoim serwerze SSL zgłasza się do CA, który po dokładnym sprawdzeniu jej "tożsamości" generuje (rzecz jasna odpłatnie) specjalny certyfikat, podpisany swoim własnym kluczem prywatnym. Certyfikat ten firma musi zainstalować w serwerze, aby uaktywnić możliwość korzystania z SSL. Ponieważ przeglądarka posiada wbudowaną listę CA wraz z ich kluczami publicznymi (listę tę można zobaczyć np. używając w przeglądarce Netscape opcji About/Security/Site certificates), może zweryfikować poprawność certyfikatu, a tym samym fakt, że firma jest w istocie tym, za kogo się podaje (oczywiście zakładając, że mamy zaufanie do CA i jego klucza publicznego...). W przypadku, gdy serwer nie posiada certyfikatu lub certyfikat wystawiony jest przez nieznany programowi CA (np. dla serwera Apache możliwe jest samodzielne wygenerowanie sobie certyfikatu), przeglądarka ostrzeże nas o tym fakcie i zapyta, czy mimo to chcemy kontynuować połączenie (tak jest w przypadku Netscape'a; Internet Explorer odmawia w ogóle połączenia z takimi serwerami).
SSL teoretycznie umożliwia także wykupienie sobie - na analogicznych zasadach - prywatnego certyfikatu przez klienta i stosowanie go dla potwierdzenia swojej tożsamości, z oczywistych względów trudno jednak wyobrazić sobie nakłonienie użytkowników przeglądarek WWW do masowego wykupywania sobie certyfikatów; istniejące urzędy certyfikacyjne nie są zresztą przygotowane do wydawania ich na taką skalę. Ten sposób weryfikacji klientów nie jest więc stosowany; nadal zatem istnieje możliwość posłużenia się zdobytym w jakiś sposób numerem cudzej karty. Nie jest to naturalnie sytuacja pożądana, toteż prowadzone są intensywne prace nad rozwiązaniem tego problemu. W ich wyniku powstało kilka alternatywnych rozwiązań, omawianych poniżej.
Podobnie jak SSL, system SET również opierać się będzie na certyfikatach - w przeciwieństwie jednak do SSL, gdzie certyfikat jest "ogólnym" potwierdzeniem tożsamości serwera bądź użytkownika, certyfikaty stosowane w SET przeznaczone będą tylko i wyłącznie do celów transakcji kartami kredytowymi. Certyfikaty wystawiane będą w sposób automatyczny przez specjalne serwery, zarządzane przez firmy zajmujące się rozliczaniem kart kredytowych. Po połączeniu się z takim serwerem (oczywiście połączenie będzie szyfrowane, np. przez SSL) musimy podać dane naszej karty kredytowej oraz nasze dane osobowe, pozwalające na zweryfikowanie tożsamości (np. numer prawa jazdy, adres zamieszkania itp.). Po sprawdzeniu tych danych w naszym banku (czynność ta odbywa się poza Internetem, poprzez istniejące prywatne sieci międzybankowe służące do autoryzacji kart kredytowych) serwer przesyła do naszego komputera gotowy certyfikat, który zostaje zapamiętany na naszym dysku. Analogicznej procedury - dla uzyskania swojego certyfikatu - musi dopełnić również sprzedawca, który chce przyjmować płatności kartami w systemie SET. Po dopełnieniu tych wstępnych czynności, podczas każdej transakcji oprogramowanie sprzedawcy i klienta sprawdza nawzajem swoje certyfikaty, eliminując tym samym z obu stron przypadki oszustwa.
Jednak system SET - jako się rzekło - nie jest jeszcze ogólnie dostępny. Praktyczną popularność zyskują sobie za to dwa inne rozwiązania płatności przez Internet z wykorzystaniem kart kredytowych: CyberCash i First Virtual.