Ricevi aggiornamenti sulle novità di Web Payments.
I pagamenti web sono disponibili pubblicamente nei browser dal 2016. La funzionalità principale, l'API Payment Request, è ora disponibile su diversi browser: Chrome, Safari, Edge e presto Firefox. Se non hai mai utilizzato i pagamenti web, consulta la "Panoramica sui pagamenti web" per iniziare.
Dal lancio dell'API Payment Request e dall'API dei gestori dei pagamenti, sono state apportate diverse modifiche alle rispettive specifiche. Queste modifiche non comprometteranno il tuo funzionamento, ma ti consigliamo di fare attenzione. Questo post riassume questi aggiornamenti e continuerà ad accumulare le modifiche all'API.
Nuovo metodo: hasEnrolledInstrument()
Nella versione precedente dell'API Payment Request, è stato 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 l'ha implementata nella versione 74 e sia Webkit
che Gecko hanno bug di monitoraggio,
ma non hanno ancora implementato il metodo a giugno 2019.
Per utilizzare il nuovo metodo hasEnrolledInstrument()
, sostituisci il codice simile a questo:
// Checking for instrument presence.
request.canMakePayment().then(handleInstrumentPresence).catch(handleError);
Con un codice simile al seguente:
// 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 degli strumenti
Poiché ora hasEnrolledInstrument()
gestisce la verifica dello strumento di pagamento dell'utente, canMakePayment()
è stato aggiornato in modo da controllare solo la disponibilità dell'app di pagamento.
Questa modifica a canMakePayment()
è vincolata all'implementazione di hasEnrolledInstrument()
. A partire da giugno 2019, è implementata in Chrome 74, ma non in altri browser. Assicurati di verificare se il metodo hasEnrolledInstrument()
è disponibile nel browser dell'utente prima di tentare di utilizzarlo.
// 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
L'account PaymentAddress.languageCode
è stato rimosso dagli indirizzi di spedizione e
dagli indirizzi 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 richiede un detailsPromise
facoltativo
PaymentRequest.show()
consente a un commerciante di presentare un'interfaccia utente per la richiesta di pagamento prima che venga noto
il totale finale. Il commerciante ha 10 secondi per risolvere il problema detailsPromise
prima di un
timeout. Questa funzionalità è pensata per un rapido round trip 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 Handler
PaymentRequestEvent.changePaymentMethod()
consente i gestori dei pagamenti (ad es. Google Pay) per attivare il gestore di eventi onpaymentmethodchange
. changePaymentMethod()
restituisce una promessa che si risolve in una
risposta
del commerciante
con informazioni sui prezzi aggiornate (ad esempio, ricalcolo delle imposte).
Sia l'evento PaymentRequestEvent.changePaymentMethod()
che l'evento paymentmethodchange
sono disponibili in Chrome 76 e Webkit ha implementato
l'evento paymentmethodchange
nella sua Anteprima
tecnologica.
// 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 alla 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 fare in modo che Chrome consenta le API Web Payments nel tuo ambiente di sviluppo. Se sviluppi utilizzando un server web locale che non supporta HTTPS, puoi anche usare il flag --unsafely-treat-insecure-origin-as-secure=<origin>
per fare in modo che Chrome consideri l'origine HTTP come HTTPS.