Aktualizacje interfejsów API płatności internetowych

Bądź na bieżąco z nowościami dotyczącymi płatności internetowych.

Danyao Wang
Danyao Wang
Rouslan Solomakhin
Rouslan Solomakhin

Płatności internetowe są dostępne publicznie w przeglądarkach od 2016 r. Główna funkcja – interfejs API żądania płatności – jest teraz dostępna w kilku przeglądarkach: Chrome, Safari, Edge i wkrótce w Firefox. Jeśli dopiero zaczynasz korzystać z płatności w internecie, zapoznaj się z „Przeglądem płatności w internecie”.

Od czasu wprowadzenia interfejsu Payment Request API i interfejsu Payment Handler API wprowadzono wiele zmian w odpowiednich specyfikacjach. Te zmiany nie spowodują przerwania działania kodu, ale zalecamy zwrócenie na nie uwagi. Ten post podsumowuje te aktualizacje i będzie zawierać kolejne zmiany w interfejsie API.

Nowa metoda: hasEnrolledInstrument()

W poprzedniej wersji interfejsu API Request do płatności używano parametru canMakePayment() do sprawdzania obecności instrumentu płatniczego użytkownika. W ostatniej aktualizacji specyfikacji funkcja canMakePayment() została zastąpiona funkcją hasEnrolledInstrument(), bez zmiany jej funkcjonalności.

Metoda hasEnrolledInstrument() jest uznana przez wszystkie główne przeglądarki. Chrome wdrożył tę metodę w wersji 74. Zarówno Webkit, jak i Gecko mają mechanizm śledzenia błędów, ale do czerwca 2019 r. nie wdrożyły jeszcze tej metody.

Aby użyć nowej metody hasEnrolledInstrument(), zastąp kod, który wygląda tak:

// Checking for instrument presence.
request.canMakePayment().then(handleInstrumentPresence).catch(handleError);

Za pomocą kodu, który wygląda tak:

// Checking for instrument presence.
if (request.hasEnrolledInstrument) {
  // hasEnrolledInstrument() is available.
  request.hasEnrolledInstrument().then(handleInstrumentPresence).catch(handleError);
} else {
  request.canMakePayment().then(handleInstrumentPresence).catch(handleError);
}

canMakePayment() nie sprawdza już obecności instrumentu

Funkcja hasEnrolledInstrument() sprawdza teraz instrument płatności użytkownika, dlatego canMakePayment() została zaktualizowana tak, aby sprawdzać tylko dostępność aplikacji do płatności.

Ta zmiana w canMakePayment() jest powiązana z wdrożeniem hasEnrolledInstrument(). Od czerwca 2019 r. jest ona zaimplementowana w Chrome 74, ale nie w innych przeglądarkach. Zanim spróbujesz użyć metody hasEnrolledInstrument(), sprawdź, czy jest ona dostępna w przeglądarce użytkownika.

// Checking for payment app availability without checking for instrument presence.
if (request.hasEnrolledInstrument) {
  // `canMakePayment()` behavior change corresponds to
  // `hasEnrolledInstrument()` availability.
  request.canMakePayment().then(handlePaymentAppAvailable).catch(handleError);
} else {
  console.log("Cannot check for payment app availability without checking for instrument presence.");
}

Usunięto languageCode z basic-card formy płatności

Adres PaymentAddress.languageCode został usunięty z adresów dostawy i adresów rozliczeniowych konta basic-card. Nie ma to wpływu na adresy rozliczeniowe w przypadku innych form płatności (np. Google Pay).

Ta zmiana została wprowadzona w Chrome 74, Firefoksie i Safari.

PaymentRequest.show() przyjmuje teraz opcjonalny parametr detailsPromise

PaymentRequest.show() pozwala sprzedawcy wyświetlać interfejs żądania płatności, zanim łączna kwota będzie znana. Sprzedawca ma 10 sekund na rozwiązanie problemu z detailsPromise, zanim nastąpi limit czasu. Ta funkcja jest przeznaczona do szybkiego przesyłania danych po stronie serwera.

Ta funkcja jest już dostępna w Chrome 75 i Safari.

// Not implemented in Chrome 74 and older.
// There's no way to feature-detect this, so check a few
// older versions of Chrome that you're seeing hit your servers.
if (/Chrome\/((6[0-9])|(7[0-4]))/g.exec(navigator.userAgent) !== null) {
  return;
}

// Supported in Chrome 75+.
request.show(new Promise(function(resolveDetailsPromise, rejectDetailsPromise) {
  // Find out the exact total amount and call
  // `resolveDetailsPromise(details)`.
  // Use a 3 second timeout as an example.
  window.setTimeout(function() {
    resolveDetailsPromise(details);
  }, 3000); // 3 seconds.
}))
.then(handleResponse)
.catch(handleError);

PaymentRequestEvent.changePaymentMethod()

Funkcja interfejsu Payment Handler API PaymentRequestEvent.changePaymentMethod() pozwala modułom obsługi płatności (np. Google Pay) do wywołania modułu obsługi zdarzeńonpaymentmethodchange. changePaymentMethod() zwraca obietnicę, która przekształca się w odpowiedź sprzedawcy ze zaktualizowanymi informacjami o cenie (np. z przeliczonym podatkiem).

Zdarzenia PaymentRequestEvent.changePaymentMethod()paymentmethodchange są dostępne w Chrome 76, a Webkit wdrożył zdarzenie paymentmethodchange w ramach Technology Preview.

// In service worker context, `self` is the global object.
self.addEventListener('paymentrequest', (evt) => {
  evt.respondWith(new Promise((confirmPaymentFunction, rejectPaymentFunction) => {
    if (evt.changePaymentMethod === undefined) {
      // Not implemented in this version of Chrome.
      return;
    }
    // Notify merchant that the user selected a different payment method.
    evt.changePaymentMethod('https://paymentapp.com', {country: 'US'})
    .then((responseFromMerchant) => {
      if (responseFromMerchant === null) {
        // Merchant ignored the 'paymentmethodchange' event.
        return;
      }
      handleResponseFromMerchant(responseFromMerchant);
    })
    .catch((error) => {
      handleError(error);
    });
  }));
});

Przykład sprzedawcy:

if (request.onpaymentmethodchange === undefined) {
  // Feature not available in this browser.
  return;
}

request.addEventListener('paymentmethodchange', (evt) => {
  evt.updateWith(updateDetailsBasedOnPaymentMethod(evt, paymentDetails));
});

Ulepszenia lokalnego środowiska programistycznego

Chrome 76 zawiera 2 małe ulepszenia, które zwiększają produktywność deweloperów. Jeśli Twoje lokalne środowisko programistyczne używa podpisanego samodzielnie certyfikatu, możesz teraz użyć parametru wiersza poleceń --ignore-certificate-errors, aby umożliwić Chrome korzystanie z interfejsów Web Payments API w środowisku programistycznym. Jeśli tworzysz treści z wykorzystaniem lokalnego serwera WWW, który nie obsługuje HTTPS, możesz też użyć flagi --unsafely-treat-insecure-origin-as-secure=<origin>, aby przeglądarka Chrome traktowała źródło HTTP jako HTTPS.