Aggiornamenti alle API Web Payments

Tieniti al corrente sulle novità di Web Payments.

Danyao Wang
Danyao Wang
Rouslan Solomakhin
Rouslan Solomakhin

I pagamenti web sono disponibili pubblicamente nei browser dal 2016. La funzionalità di base, l'API Payment Request, è ora disponibile su più browser: Chrome, Safari, Edge e presto Firefox. Se non hai mai utilizzato i pagamenti web, consulta la "Panoramica dei pagamenti web" per iniziare.

Dal lancio dell'API Payment Request e dell'API Payment Handler, sono state apportate diverse modifiche alle rispettive specifiche. Queste modifiche non interromperanno il codice in funzione, ma ti consigliamo di prestarvi attenzione. Questo post riassume questi aggiornamenti e continuerà ad accumulare le modifiche all'API.

Nuovo metodo: hasEnrolledInstrument()

Nella versione precedente dell'API Payment Request, veniva utilizzato canMakePayment() per verificare la presenza dello strumento di pagamento dell'utente. In un recente aggiornamento della specifica, canMakePayment() è stato sostituito con hasEnrolledInstrument() senza modificarne la funzionalità.

Il metodo hasEnrolledInstrument() ha il consenso di tutti i principali browser. Chrome lo ha implementato nella versione 74 e sia Webkit che Gecko presentano bug di monitoraggio, ma non hanno ancora implementato il metodo a partire da giugno 2019.

Per utilizzare il nuovo metodo hasEnrolledInstrument(), sostituisci il codice simile al seguente:

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

Con il seguente codice:

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

canMakePayment() non controlla più la presenza dello strumento

Poiché hasEnrolledInstrument() ora gestisce il controllo dell'instrumento di pagamento dell'utente, canMakePayment() è stato aggiornato per verificare solo la disponibilità dell'app di pagamento.

Questa modifica a canMakePayment() è legata all'implementazione di hasEnrolledInstrument(). Da giugno 2019, è implementato in Chrome 74, ma non in altri browser. Prima di tentare di utilizzarlo, assicurati che il metodo hasEnrolledInstrument() sia disponibile nel browser dell'utente.

// 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.");
}

languageCode rimosso dal metodo di pagamento basic-card

PaymentAddress.languageCode è stato rimosso dagli indirizzi di spedizione e di fatturazione per basic-card. Gli indirizzi di fatturazione di altri metodi di pagamento (come Google Pay) non sono interessati.

Questa modifica è stata implementata in Chrome 74, Firefox e Safari.

PaymentRequest.show() ora accetta un detailsPromise facoltativo

PaymentRequest.show() consente a un commerciante di presentare una UI di richiesta di pagamento prima di rendere noto il totale finale. Il commerciante ha dieci secondi di tempo per risolvere il problema detailsPromise prima di un timeout. Questa funzionalità è destinata a un rapido roundtrip lato server.

Questa funzionalità è stata fornita in Chrome 75 e 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()

La funzionalità API Payment Gestori PaymentRequestEvent.changePaymentMethod() consente ai gestori dei pagamenti (ad es. Google Pay) per attivare il gestore di eventi onpaymentmethodchange. changePaymentMethod() restituisce una promessa che risolve in una risposta del commerciante con informazioni aggiornate sui prezzi (ad es. ricalcolo delle imposte).

Sia l'evento PaymentRequestEvent.changePaymentMethod() sia l'evento paymentmethodchange sono disponibili in Chrome 76 e Webkit ha implementato l'evento paymentmethodchange nella sua anteprima della tecnologia.

// 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);
    });
  }));
});

Esempio di commerciante:

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

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

Miglioramento dello sviluppo locale

Chrome 76 aggiunge due piccoli miglioramenti per la produttività degli sviluppatori. Se il tuo ambiente di sviluppo locale utilizza un certificato autofirmato, ora puoi utilizzare il flag della riga di comando --ignore-certificate-errors per consentire a Chrome di consentire le API Web Payments nel tuo ambiente di sviluppo. Se sviluppi utilizzando un server web locale che non supporta HTTPS, puoi anche utilizzare il flag --unsafely-treat-insecure-origin-as-secure=<origin> per fare in modo che Chrome tratti l'origine HTTP come HTTPS.