Porównanie / Checkout

Hosted checkout czy własny checkout

Każdy sprzedawca przyjmujący płatności online musi raz odpowiedzieć na to pytanie: czy strona zbierająca dane karty należy do Ciebie, czy do dostawcy? Odpowiedź przesądza o zakresie PCI, o tym, jak szybko dodasz metodę płatności, i o tym, kogo obudzą w nocy, gdy wejdzie nowy wymóg schematu kartowego. To mniej wybór technologii, a bardziej decyzja, na co zespół ma poświęcić swój rok.

Opcja kontra opcja

Siedem pytań, które rozstrzygają

Dimension
Hosted checkout
Własny checkout
Zakres PCI
Minimalny. Strona zbierająca dane karty należy do dostawcy, więc Twoje serwery widzą token, nigdy numer karty — zwykle to najlżejsza dostępna samoocena.
Twój. Bezpośrednia obsługa danych karty obejmuje Twoje systemy zakresem, a z nim projekt, ocenę i coroczną recertyfikację.
Czas do pierwszej płatności
Dni. Tworzysz zamówienie, przekierowujesz, obsługujesz jeden webhook — większość pracy to ustalenie, co dzieje się po udanej płatności.
Miesiące, a najtrudniejszy jest długi ogon: 3-D Secure, arkusze portfeli, stany błędów, ponowienia i przypadki brzegowe każdej metody.
Dodanie metody płatności
Konfiguracja. Nowe metody pojawiają się wraz z platformą i wystarczy je włączyć; strona dostosowuje się bez wydania po Twojej stronie.
Za każdym razem projekt — integracja, certyfikacja, praca nad UI i stałe zobowiązanie do utrzymania każdej metody.
Kontrola nad doświadczeniem
Wysoka, ale ograniczona: branding, opcje layoutu, własna domena i osadzone pola, gdy płatność ma być wewnątrz Twojej strony — w granicach tego, co udostępnia dostawca.
Pełna. Jeśli Twój checkout ma robić coś naprawdę nietypowego, cudze ograniczenia Cię nie dotyczą.
Praca nad konwersją
Odziedziczona. Kolejność metod, lokalizacja, obsługa portfeli i zachowanie przy ponowieniach poprawiają się wraz z platformą — bez prowadzenia przez Ciebie eksperymentów.
Trzeba na nią zapracować. Możesz przebić generyczną stronę, optymalizując ją pod swój lejek — jeśli masz ruch i ludzi, którzy zrobią to porządnie.
Bycie na bieżąco
Problem dostawcy. Wymogi schematów, zmiany SCA oraz aktualizacje przeglądarek i portfeli trafiają do Ciebie jako aktualizacje platformy.
Stała pozycja na roadmapie, bez końca — ta praca nigdy się nie kończy i rzadko dostaje priorytet, dopóki coś się nie zepsuje.
Realny koszt
Ekonomia per transakcja — widoczna i proporcjonalna do wolumenu.
Pensje inżynierów plus certyfikacja, wydawane przed pierwszą płatnością i co roku potem — zwykle niedoszacowane o rząd wielkości.
01

Kiedy wygrywa hosted checkout

W większości firm, przez większość czasu. Jeśli płatności są sposobem, w jaki dostajesz pieniądze, a nie tym, co sprzedajesz, strona checkoutu nie jest miejscem Twojej przewagi — a koszt jej posiadania płacisz w najmniej widoczny sposób: stała część mocy inżynierskiej idzie na wymogi schematów i integracje metod zamiast na produkt. Hostowana strona likwiduje też problem PCI, czyli największy ukryty koszt robienia tego samemu.

  1. 01Płatności służą do zarabiania, a nie są samym produktem
  2. 02Chcesz, by dane kart były poza zakresem, a nie tylko starannie obsługiwane
  3. 03Nowe metody mają się pojawiać bez wydania po Twojej stronie
  4. 04Twoi inżynierowie są więcej warci przy tym, co kupują klienci
02

Kiedy wygrywa budowa własnego checkoutu

Gdy checkout naprawdę jest produktem. Platformy przetwarzające płatności dla innych, firmy z przepływem, którego żadna hostowana strona nie wyrazi, i zespoły o takim wolumenie, że ułamek punktu procentowego konwersji waży więcej niż pensje zespołu płatności — takie przypadki istnieją i uzasadniają budowę. Podobnie jak wymóg regulacyjny, by powierzchnia obsługi kart znajdowała się w Twoim własnym perymetrze. Poniżej tej skali budowa zwykle oznacza kosztowne odkrywanie na nowo, dlaczego hosted checkouty w ogóle istnieją.

  1. 01Płatności są produktem — przetwarzasz je w imieniu innych
  2. 02Wolumen jest na tyle duży, że krańcowa konwersja przeważa nad kosztem zespołu
  3. 03Regulator lub komitet ryzyka wymaga, by ta powierzchnia była w Twoim perymetrze
  4. 04Twój przepływ jest naprawdę nietypowy i żadna hostowana strona go nie wyrazi
03

Gdzie pasuje Protocore

Protocore Gateway to rozwiązanie hostowane, w którym zwykłe furtki awaryjne są wbudowane, a nie sprzedawane osobno: uruchom stronę na naszej domenie lub swojej, osadź pola płatności we własnym layoucie, gdy wymaga tego przepływ, albo pokaż ten sam checkout natywnie w aplikacji. Karty, portfele, przelew bankowy i USDC trafiają na jedną stronę i rozliczają się do jednej kwoty w euro z jednym identyfikatorem zamówienia. A jeśli uczciwa odpowiedź dla Ciebie to trzecia opcja — chcesz być dostawcą, a nie sprzedawcą — ta sama platforma jest dostępna w wersji whitelabel, co zwykle opłaca się bardziej niż budowa gatewaya od zera.

  1. 01Strona hostowana, własna domena, osadzone pola lub in-app — ta sama integracja
  2. 02Karty, portfele, przelew i USDC na jednej stronie, rozliczane w EUR
  3. 03Jeden identyfikator zamówienia od checkoutu przez potwierdzenie po pozycję w banku
  4. 04Dostępny jako whitelabel, gdy chcesz być dostawcą, a nie sprzedawcą

Nie wiesz, po której jesteś stronie?

Powiedz nam o swoim wolumenie, metodach i o tym, czym zajmują się Twoi inżynierowie. Powiemy wprost, które rozwiązanie pasuje do Twojej sytuacji — także wtedy, gdy będzie to zbudowanie go samemu.