Przedstawiamy płatności internetowe: łatwiejsze zakupy online dzięki interfejsowi API żądania płatności

Kupowanie rzeczy online może być frustrującym procesem, zwłaszcza na urządzeniach mobilnych. Nawet jeśli strony są dobrze zaprojektowane, wymaganych jest wiele informacji: nasze dane kontaktowe, adresy wysyłkowe i rozliczeniowe, opcja wysyłki i dane karty. Jeśli kiedykolwiek po prostu się poddałeś, jesteś w większości.

Baymard Institute wziął średnią z 37 różnych badań i stwierdził, że 69% koszyków jest porzucanych.

Nic dziwnego, że dane są gorsze na urządzeniach mobilnych, gdzie mniejszy ekran i brak fizycznej klawiatury mogą spowolnić wprowadzanie danych. Współczynnik porzuceń na urządzeniach mobilnych może wynosić nawet 84% lub więcej! Wraz z rozwojem i rozwojem przeglądania mobilnego w ostatnich latach oznacza to, że ogólny problem staje się coraz gorszy. W przypadku witryn e-commerce te porzucone koszyki kosztują ogromne pieniądze. Business Insider oszacował, że towary o wartości 4 biliony dolarów zostaną porzucone w ciągu jednego roku.

Na szczęście sieć walczy z tym problemem. Grupa Robocza W3C „Płatności internetowe” jest zajęta „rewolucją w płatnościach w sieci” , opracowując nowe standardy, aby uczynić płatności online znacznie łatwiejszymi. Oprócz tego, że jest nazwą grupy roboczej, „Płatności internetowe” są zasadniczo terminem ogólnym obejmującym te nowe, nadchodzące standardy.

Interfejs API żądania płatności

Pierwszy z tych standardów, Payment Request API , to duży krok naprzód. Daje nam to możliwość żądania płatności od użytkownika, a przeglądarka udostępnia interfejs użytkownika, który ją akceptuje. Jest już obsługiwany w przeglądarkach Chrome, Edge i Samsung Internet i jest rozwijany w przeglądarkach Firefox i Safari. Wiele znanych firm przyjmuje API, w tym New York Times, Washington Post i Monzo.

Żądanie tych informacji z przeglądarki zapewnia natychmiastową, dużą korzyść, ponieważ prawdopodobnie te dane są już przechowywane . Dopóki wprowadzimy nasze dane w jednej innej witrynie, która korzysta z interfejsu API i pozwolimy naszej przeglądarce je zapamiętać, przeglądarka będzie mogła wstępnie wypełnić formularz, co pozwoli nam na znacznie szybsze sprawdzanie.

To jest lepsze niż standardowe autouzupełnianie; umożliwienie przeglądarce obsługi pól wejściowych oznacza, że ​​może ona być całkowicie dokładna — unikając wszelkich problemów ze wstępnym wypełnianiem niewłaściwych informacji w niewłaściwych polach. Oznacza to również, że mamy zoptymalizowany pod kątem urządzeń mobilnych, jednostronicowy formularz płatności, bez konieczności pisania własnego kodu HTML i CSS.

Korzyści mogą być jeszcze bardziej odczuwalne na urządzeniach mobilnych, ale interfejs API żądania płatności nie ogranicza się do przeglądarek mobilnych. Jest już obsługiwany w komputerowych wersjach Chrome, Edge i Samsung Internet dla DeX. Możemy również spodziewać się, że później pojawi się wsparcie w przeglądarkach Firefox i Safari (w momencie pisania tego tekstu zostało ono niedawno włączone domyślnie w Safari Technology Preview 44).

Nasze pierwsze żądanie płatności

Zacznijmy poznawanie API od podstawowego przykładu. Poprosimy użytkownika o płatność kartą i pozwolimy mu dokonać płatności w następujący sposób:

Na powyższym filmie zauważysz, że użytkownik potwierdza płatność odciskiem palca. Nie jest to część samego standardu Payment Request, ale funkcja bezpieczeństwa, którą zapewnia przeglądarka internetowa Samsung (wraz ze skanowaniem tęczówki) na obsługiwanych urządzeniach.

Jeśli jesteś zainteresowany dalszym potencjałem integracji uwierzytelniania biometrycznego w Internecie, możesz chcieć obserwować nadchodzący standard uwierzytelniania internetowego.

Najpierw jak zwykle powinniśmy zastosować Progressive Enhancement i sprawdzić, czy ta przeglądarka obsługuje API:

 if (window.PaymentRequest) { // We can continue with the Payment Request API } else { // Here we could fall back to a legacy checkout form }

Teraz możemy ustawić konfigurację dla naszego PaymentRequest — rodzaj płatności, którą akceptujemy oraz szczegóły do ​​wyświetlenia na temat zakupu:

 var methodData = [{ // 'basic-card' means standard card payments - credit and debit cards supportedMethods: 'basic-card' }]; var details = { // If we are buying multiple items, each one can be included displayItems: [ { label: 'Some product that we are buying', amount: {currency: 'USD', value: '699.99'} } ], total: { label: 'Total', amount: {currency: 'USD', value: '699.99'} } }; var paymentRequest = new PaymentRequest(methodData, details);

Gdy chcemy wyświetlić interfejs płatności (np. gdy użytkownik kliknie „Kup teraz”), możemy wywołać show() . Następnie przetwarzamy dane, które podał użytkownik, gdy obietnica zostanie zrealizowana:

 // show() makes it actually display the user interface paymentRequest.show() .then(function(paymentResponse) { // User has confirmed. paymentResponse contains the data entered. // Here we would process it server-side... processPaymentDetails(paymentResponse) .then(function(paymentResponse) { // ...Then when processed successfully, this will make the dialog indicate success & then close: paymentResponse.complete('success'); // We could also update the page here appropriately }); }) .catch(function(error) { // Handle error, eg if user clicks the 'cancel' button. });

Mamy teraz skonfigurowany przepływ interfejsu użytkownika w interfejsie użytkownika. Możemy go również dalej konfigurować, aby dopasować go do naszych wymagań. Na przykład, jeśli chcemy poprosić klienta o dodatkowe szczegóły, możemy przekazać dodatkowe options do konstruktora PaymentRequest. Na przykład, aby poprosić o imię i nazwisko użytkownika, adres e-mail, numer telefonu i adres do wysyłki:

 var options = { requestPayerName: true, requestPayerEmail: true, requestPayerPhone: true, requestShipping: true }; var paymentRequest = new PaymentRequest(methodData, details, options);

Możemy również zdefiniować wiele opcji wysyłki, a nawet kontrolować, które opcje są prezentowane dynamicznie, na podstawie adresu klienta. Przykład tego można znaleźć tutaj na Glitch.

Doświadczenie użytkownika

Zaczynamy widzieć imponujące statystyki dotyczące korzyści, jakie może przynieść firmom wniosek o płatność. Google niedawno poinformowało, że J.Crew, marka modowa, odkryła, że ​​50% jej użytkowników przechodzi teraz przez przepływ żądania płatności, co skraca czas transakcji o 75%!

Od Ciebie zależy, jak zintegrować żądanie płatności z zakupami, ale powszechnym sposobem jest oferowanie czegoś takiego jak opcja „Ekspresowa płatność” lub „Kup teraz”, bez konieczności wcześniejszego logowania się klienta. Jeśli chcesz, możesz zebrać dane kontaktowe użytkownika za pomocą interfejsu użytkownika żądania płatności, a po dokonaniu przez niego zakupu zaoferować możliwość utworzenia konta do wykorzystania w przyszłości.

Jeśli chcesz, możesz najpierw sprawdzić, czy klient ma już skonfigurowaną prawidłową metodę płatności, zanim przedstawisz interfejs żądania płatności. Aby to zrobić, możesz zadzwonić do canMakePayment :

 if (paymentRequest.canMakePayment) { paymentRequest.canMakePayment().then(function(result) { if (result) { // User has an active payment method } else { // No active payment method yet (but they could add one) } }).catch(function(error) { // Unable to determine }); }

Integracja zaplecza

Widzieliśmy, jak skonfigurować interfejs użytkownika do przyjmowania płatności, ale jak faktycznie przetwarzamy płatności na zapleczu?

Większość stron internetowych nie obsługuje płatności samodzielnie (co wymagałoby dużej staranności i zgodności ze standardem PCI DSS), ale korzysta z bramki płatniczej (PG) lub dostawcy usług płatniczych (PSP). Wiele bramek płatności wprowadziło już specjalne wsparcie dla API żądania płatności. Mogą zainicjować Żądanie Płatności za pomocą własnego skryptu, który umieścisz na swojej stronie, pomagając zapewnić, że dane są przesyłane w bezpieczny sposób i że nie musisz się nimi zajmować samodzielnie. Mogą również oferować rozwiązanie iFrame lub przekierowanie. Najlepszym sposobem postępowania jest sprawdzenie w bramce płatności, w jaki sposób zalecają uwzględnienie żądań płatności.

Integracja z aplikacją płatniczą

Do tej pory omówiliśmy płatności kartą. Jednak interfejs API żądania płatności obsługuje również aplikacje do płatności mobilnych, takie jak Samsung Pay, Pay with Google (zawierający Android Pay) i Apple Pay.

Pozwalając naszym klientom płacić jedną z tych aplikacji, mogą korzystać z karty, którą zapisali w aplikacji, bez konieczności ponownego wpisywania danych (nawet za pierwszym razem) w przeglądarce. Korzystanie z tych aplikacji może być również szybsze, ponieważ nie wymagają one od klienta ponownego wpisywania kodu weryfikacyjnego CVC (kodu weryfikacyjnego karty, znanego również jako CVV) z tyłu karty. Wreszcie, mogą przynieść dodatkowe korzyści w zakresie bezpieczeństwa, ponieważ nie przesyłają oryginalnych danych karty, a jedynie tokeny jednorazowego użytku, chroniąc nas w ten sposób przed potencjalnymi atakami przechwycenia i powtórzenia.

Gdy klient wybierze aplikację płatniczą jako wybraną metodę płatności, przeglądarka przełączy się na arkusz płatności dostarczony przez aplikację, aby potwierdzić płatność. Aplikacja innej firmy będzie wówczas ogólnie akceptować skan odcisku palca lub tęczówki oka klienta w celu potwierdzenia płatności, jeśli urządzenie ją obsługuje.

Każda aplikacja płatnicza będzie miała swoje własne instrukcje, ale ogólna idea jest taka sama. Możesz je zidentyfikować jako potencjalne metody płatności za pomocą ich własnych specjalnych adresów URL i przekazać wymaganą konfigurację w polu data . Na przykład, aby obsługiwać Samsung Pay, w tablicy methodData należy umieścić taki kod:

 var methodData = [ { supportedMethods: 'https://spay.samsung.com', data: { // Samsung Pay specific data here } }, … // Other payment methods ];

Ogólnie rzecz biorąc, istnieją dwie metody integracji tych aplikacji z bramą płatności: metoda „Token bramy” i metoda „Token sieci”. Jeśli korzystasz z usługi innej firmy, która ją obsługuje, najprawdopodobniej użyjesz trybu Gateway Token, w którym usługa aplikacji płatniczej wykona połączenie z Twoją bramką płatności w Twoim imieniu. Alternatywnie możesz użyć metody Network Token, w której będziesz obsługiwać wysyłanie tokena do swojej bramki płatności bezpiecznie, używając ich SDK. Twoja bramka płatności i/lub dostawca aplikacji płatniczych powinien być w stanie podać dalsze szczegóły.

Google niedawno ogłosił Google Payment API, który obejmuje Android Pay oraz karty przechowywane na kontach Google klientów.

Apple Pay obecnie korzysta z własnego rozwiązania JavaScript, Apple Pay JS. Jednak programiści w Google stworzyli opakowanie, które umożliwia korzystanie z niego za pośrednictwem standardowego interfejsu Payment Request API.

Co dalej?

Grupa robocza ds. płatności internetowych nie zatrzymuje się w interfejsie API żądania płatności. Trwają również prace nad innymi standardami, w tym API obsługi płatności, które pozwolą aplikacjom internetowym działać jako aplikacja płatnicza innej firmy. Inne tematy, które są omawiane, obejmują możliwą standaryzację wokół tokenizacji i możliwość obsługi wniosków o płatność, takich jak karty podarunkowe. Jeśli chcesz być na bieżąco z rozwojem wydarzeń, oto publiczna lista dyskusyjna. Mam nadzieję, że razem możemy rozwiązać frustrujące doświadczenia związane z kasą z przeszłości i zrealizować wizję rewolucji w płatnościach internetowych!

Dalsze zasoby

• „Wiki płatności internetowych W3C”, GitHub
• „Informacje dla programistów API żądania płatności W3C”, GitHub zobacz także FAQ
• „Płatności internetowe 101: samouczek dotyczący kodowania krótkiego żądania płatności”, Glitch
• „Głębokie zanurzenie w interfejsie API żądania płatności”, Google Developers
• „Przewodnik dewelopera interfejsu API żądania płatności”, Microsoft Edge
• „Jak akceptować płatności Samsung Pay w witrynie za pomocą płatności internetowych”, Winston Chen, Medium