HTML 5.2 Le specifiche API di richiesta di pagamento

SEO / SEM /SEA

26 Ottobre 2019

Graphics, Communication, Marketing

26 Ottobre 2019

HTML 5.2 Le specifiche API di richiesta di pagamento

Raccomandazione del Candidato W3C 21 settembre 2017

Astratto

Questa specifica standardizza un’API per consentire ai commercianti (ad esempio siti Web che vendono beni fisici o digitali) di utilizzare uno o più metodi d pagamento con un’integrazione minima. I programmi utente (ad esempio i browser) facilitano il flusso di pagamento tra commerciante e utente.

Stato di questo documento

Questa sezione descrive lo stato di questo documento al momento della sua pubblicazione. Altri documenti possono sostituire questo documento. Un elenco delle attuali pubblicazioni del W3C e l’ultima revisione di questo rapporto tecnico sono disponibili nell’indice dei rapporti tecnici del W3C su https://www.w3.org/TR/.

Il gruppo di lavoro mantiene un elenco di tutte le segnalazioni di bug che il gruppo non ha ancora affrontato . Sono fortemente incoraggiate le richieste di pull con il testo delle specifiche proposte per le questioni in sospeso.

La scadenza per i commenti per la Candidate Recommendation è il 31 ottobre 2017. Nota : invio di commenti su questo documento

Se desideri fare commenti su questo documento, sollevali come problemi di GitHub . Invia solo commenti via e-mail se non sei in grado di sollevare problemi su GitHub (vedi link sotto). Tutti i commenti sono ben accetti

Il gruppo di lavoro dimostrerà l’esperienza di implementazione producendo un rapporto di attuazione . Il report mostrerà due o più implementazioni indipendenti che superano ogni test obbligatorio nella suite di test (cioè, ogni test corrisponde a un requisito MUST della specifica).

Non c’è stato alcun cambiamento nelle dipendenze da altri gruppi di lavoro durante lo sviluppo di questa specifica.

Questo documento è stato pubblicato dal gruppo di lavoro Web Payments come una raccomandazione per i candidati. Questo documento è destinato a diventare una raccomandazione del W3C . Il W3C pubblica una Raccomandazione per Candidati per indicare che il documento è ritenuto stabile e incoraggiare l’implementazione da parte della comunità degli sviluppatori. Si prevede che questa Raccomandazione per il Candidato passi alla Raccomandazione proposta non prima del 31 ottobre 2017.

Si prega di consultare il rapporto di implementazione del gruppo di lavoro.

La pubblicazione come Raccomandazione del Candidato non implica l’approvazione da parte del W3C Membership. Questa è una bozza di documento e può essere aggiornata, sostituita o resa obsoleta da altri documenti in qualsiasi momento. Non è appropriato citare questo documento come diverso dal work in progress.

Questo documento è stato prodotto da un gruppo che opera nell’ambito della politica sui brevetti W3C del 5 febbraio 2004 . W3C mantiene un elenco pubblico di tutte le informazioni sui brevetti fatte in relazione ai deliverable del gruppo; quella pagina include anche le istruzioni per divulgare un brevetto. Un individuo che abbia una conoscenza effettiva di un brevetto che l’individuo crede contenga una o più rivendicazioni essenziali deve divulgare le informazioni in conformità con la sezione 6 della Politica sui brevetti del W3C .

Questo documento è disciplinato dal Documento di processo W3C del 1 ° marzo 2017 .

Funzionalità a rischio

Poiché questa specifica entra nella fase di Candidate Recommendation del processo di standardizzazione del W3C , il gruppo di lavoro ha identificato le seguenti caratteristiche come ” a rischio ” di essere rimosso dalle specifiche. Il gruppo di lavoro cerca suggerimenti da implementatori, sviluppatori e pubblico in generale sull’opportunità o meno di mantenere queste caratteristiche nelle specifiche. Se non vengono ricevuti casi di utilizzo convincenti, o se vi è un interesse limitato da parte degli implementatori, queste funzionalità saranno rimosse dalle specifiche prima di procedere lungo la traccia della Raccomandazione W3C .

currencySystem (consultare il numero 617 ).

1. Introduzione

Questa sezione non è normativa.

Questa specifica descrive un’API che consente agli agenti utente (ad esempio, i browser) di agire come intermediario tra tre parti in una transazione:

il beneficiario: il commerciante che gestisce un negozio online o un’altra parte che richiede di essere pagato.
il pagatore: la parte che effettua un acquisto in quel negozio online e che autentica e autorizza il pagamento come richiesto.
il fornitore del metodo di pagamento : la parte che fornisce i mezzi (ad esempio, la carta di credito) che il pagatore utilizza per pagare e che è accettata dal beneficiario.

I dettagli su come soddisfare una richiesta di pagamento per un determinato metodo di pagamento vengono gestiti dagli addetti al pagamento . In questa specifica, questi dettagli sono lasciati al ruolo dell’utente , ma le specifiche future possono espandersi sul modello di elaborazione in modo più dettagliato.

Questa API consente inoltre ai siti Web di usufruire di schemi di pagamento più sicuri (ad esempio, tokenizzazione e autenticazione a livello di sistema) che non sono possibili con le librerie JavaScript standard. Questo ha il potenziale per ridurre la responsabilità per il commerciante e aiuta a proteggere le informazioni sensibili degli utenti.

1.1 Obiettivi

Consenti all’utente di agire come intermediario tra commercianti, utenti e fornitori di metodi di pagamento .
Consenti ai programmi utente di semplificare l’esperienza di pagamento dell’utente tenendo conto delle preferenze dell’utente, delle informazioni commerciali, delle considerazioni sulla sicurezza e di altri fattori.
Standardizzare (nella misura in cui ha senso) il flusso di comunicazione tra un commerciante, un agente utente e un fornitore di metodi di pagamento .
Abilitare i fornitori di metodi di pagamento per portare transazioni di pagamento più sicure sul Web.

1.1.1 Fuori dallo scopo

Crea un nuovo metodo di pagamento
Integrare direttamente con i processori di pagamento

2. Esempi di utilizzo

Questa sezione non è normativa.

Per utilizzare l’API, lo sviluppatore deve fornire e tenere traccia di una serie di informazioni chiave. Questi bit di informazioni vengono passati al costruttore di PaymentRequest come argomenti e successivamente utilizzati per aggiornare la richiesta di pagamento visualizzata all’utente. Vale a dire, questi bit di informazione sono:

Il metodo Data : una sequenza di PaymentMethodData che rappresenta i metodi di pagamento supportati dal sito (ad esempio, “supportiamo pagamenti basati su carte, ma solo carte di credito Visa e MasterCard.”).
I dettagli : i dettagli della transazione, come dizionario PaymentDetailsInit . Ciò include il costo totale e facoltativamente un elenco di beni o servizi acquistati, beni materiali e opzioni di spedizione. Inoltre, può facoltativamente includere “modificatori” su come vengono effettuati i pagamenti. Ad esempio, “se paghi con una carta di credito di tipo X, incorre in una tassa di elaborazione di $ 3,00”.
Le opzioni : Facoltativamente, un elenco di cose come PaymentOptions cui il sito ha bisogno per consegnare il bene o il servizio (ad esempio, per beni fisici, il commerciante di solito avrà bisogno di un indirizzo fisico da spedire. Per i beni digitali, una email di solito è sufficiente) .

Una volta che PaymentRequest è stato PaymentRequest , viene presentato all’utente finale tramite il metodo show() . Lo show() restituisce una promessa che, una volta che l’utente conferma la richiesta di pagamento, restituisce una risposta di pagamento.

2.1 L’argomento `methodData`

La sequenza methodData contiene i dizionari PaymentMethodData contenenti gli identificativi del metodo di pagamento per i metodi di pagamento accettati dal sito Web e i dati specifici associati al metodo di pagamento . Esempio 1 : l’argomento `methodData`

  const methodData = [
   {
     supportedMethods : "basic-card" ,
     dati : {
       supportedNetworks : [ "visa" , "mastercard" ],
       supportedTypes : [ "debit" , "credit" ],
     },
   },
   {
     supportedMethods : "https://example.com/bobpay" ,
     dati : {
       merchantIdentifier : "XXXX" ,
       bobPaySpecificField : true ,
     },
   },
 ];

2.2 L’argomento dei `details`

I dettagli contengono informazioni sulla transazione che l’utente è invitato a completare, ad esempio gli elementi pubblicitari in un ordine. Esempio 2 : l’argomento `details`

  const details = {
   id : "super-store-order-123-12312" ,
   displayItems : [
     {
       etichetta : "Totale parziale" ,
       importo : { valuta : "USD" , valore : "55,00" },
     },
     {
       etichetta : "Imposta sulle vendite" ,
       importo : { valuta : "USD" , valore : "5.00" },
     },
   ],
   totale : {
     etichetta : "Totale dovuto" ,
     // Il totale è di $ 65,00 USD qui perché è necessario
     // aggiungi spedizione (sotto).  La spedizione selezionata
     // costa $ 5,00 USD.
     importo: { valuta : "USD" , valore : "65,00" },
   },
 };

2.2.1 Opzioni di spedizione

Qui vediamo un esempio di come aggiungere due opzioni di spedizione ai dettagli . Esempio 3 : aggiunta delle opzioni di spedizione

  const shippingOptions = [
   {
     id : "standard" ,
     etichetta : "? Spedizione a terra (2 giorni)" ,
     importo : { valuta : "USD" , valore : "5.00" },
     selezionato : vero ,
   },
   {
     id : "drone" ,
     etichetta : "? Drone Express (2 ore)" ,
     importo : { valuta : "USD" , valore : "25,00" }
   },
 ];
 Oggetto .assign (dettagli, {shippingOptions});

2.2.2 Modifiche condizionali alla richiesta di pagamento

Qui vediamo come aggiungere una tassa di elaborazione per l’utilizzo di una carta di credito. Si noti che richiede il ricalcolo del totale. Esempio 4 : modifica della richiesta di pagamento in base al tipo di carta

  // La carta di credito comporta una commissione di $ 3,00.
 const creditCardFee = {
   etichetta : "tassa di elaborazione della carta di credito" ,
   importo : { valuta : "USD" , valore : "3,00" },
 };

 // I modificatori si applicano quando l'utente sceglie di pagare con
 // una carta di credito.
 const modifiers = [
   {
     additionalDisplayItems : [creditCardFee],
     supportedMethods : "basic-card" ,
     totale : {
       etichetta : "Totale dovuto" ,
       importo : { valuta : "USD" , valore : "68.00" },
     },
     dati : {
       supportedTypes : "credit" ,
     },
   },
 ];
 Oggetto .assign (dettagli, {modificatori});

2.3 L’argomento delle `options`

Il dizionario delle opzioni contiene informazioni che lo sviluppatore ha bisogno dall’utente per eseguire il pagamento (ad esempio, il nome del pagatore e l’indirizzo di spedizione). Esempio 5 : l’argomento `options`

  const options = {
   requestPayerEmail : false ,
   requestPayerName : true ,
   requestPayerPhone : false ,
   requestShipping : vero ,
 }

2.4 Costruire un `PaymentRequest`

Avendo raccolto tutti i bit di informazione prerequisiti, ora possiamo costruire un PaymentRequest e richiedere che il browser lo presenti all’utente: Esempio 6 : Costruzione di un `PaymentRequest`

  funzione async doPaymentRequest (   ) {
   prova {
     const request = new PaymentRequest (methodData, dettagli, opzioni);
     // Vedi sotto per un esempio dettagliato di gestione di questi eventi
     request.onshippingaddresschange = ev => ev.updateWith (dettagli);
     request.onshippingoptionchange = ev => ev.updateWith (dettagli);
     const response = attende request.show ();
     attendere validateResponse (response);
   } catch (err) {
     // AbortError, SecurityError
     console .error (err);
   }
 }
 funzione async validateResponse ( response ) {
   prova {
     se (attendi checkAllValuesAreGood (risposta)) {
       attendere response.complete ( "successo" );
     } else {
       attendere response.complete ( "fail" );
     }
   } catch (err) {
     // Qualcosa è andato storto...
     attendere response.complete ( "fail" );
   }
 }
 doPaymentRequest ();

2.5 Gestione degli eventi e aggiornamento della richiesta di pagamento

Prima che l’utente accetti di effettuare il pagamento, al sito viene data l’opportunità di aggiornare la richiesta di pagamento in risposta all’input dell’utente. Ciò può includere, ad esempio, la fornitura di ulteriori opzioni di spedizione (o la modifica dei costi), la rimozione di articoli che non possono essere spediti a un determinato indirizzo, ecc. Esempio 7 : registrazione dei gestori di eventi

  const request = new PaymentRequest (methodData, dettagli, opzioni);
 // Aggiornamento asincrono per i dettagli
 request.onshippingaddresschange = ev => {
   ev.updateWith (checkShipping (richiesta));
 };
 // sincronizza l'aggiornamento al totale
 request.onshippingoptionchange = ev => {
   const shippingOption = shippingOptions.find (
     opzione => option.id === request.id
   );
   const newTotal = {
     valuta : "USD" ,
     etichetta : "Totale dovuto" ,
     valore : calculateNewTotal (shippingOption),
   };
   ev.updateWith ({... dettagli, total : newTotal});
 };
 funzione asincrona checkShipping ( richiesta ) {
   prova {
     const json = request.shippingAddress.toJSON ();

     attendere ensureCanShipTo (json);
     const {shippingOptions, total} = attende calculateShipping (json);

     return {... dettagli, shippingOptions, total};
   } catch (err) {
     return {... dettagli, errore : `Scusa!  non possiamo spedire al tuo indirizzo. }};
   }
 }

2.6 POSTARE la risposta di pagamento su un server

È previsto che i dati in PaymentResponse vengano inviati a un server per l’elaborazione. Per rendere questo più semplice possibile, PaymentResponse fornisce un metodo toJSON() che serializza l’oggetto direttamente in JSON. Ciò rende banale il POST del JSON risultante su un server che utilizza l’ API Fetch : Esempio 8 : POSTing con `fetch ()`

  funzione async doPaymentRequest (   ) {
   const payRequest = new PaymentRequest (methodData, dettagli, opzioni);
   const payResponse = attende payRequest.show ();
   let result = "" ;
   prova {
     const httpResponse = attendi il recupero ( "/ process-payment" , {
       metodo : "POST" ,
       intestazioni : { "Content-Type" : "application / json" },
       corpo : payResponse.toJSON (),
     });
     risultato = httpResponse.ok?  "successo" : "fallire" ;
   } catch (err) {
     console .error (err);
     result = "fail" ;
   }
   attendere payResponse.complete (risultato);
 }
 doPaymentRequest ();

3. Interfaccia `PaymentRequest`

[ Costruttore ( sequenza < PaymentMethodData > methodData , PaymentDetailsInit details , PaymentOptions option option ) , SecureContext , Esposto = Finestra ] interfaccia PaymentRequest : EventTarget { Prometti < PaymentResponse > show (); Prometti <void> abort (); Prometti < boolean > canMakePayment (); attributo readonly id DOMString ; attributo PaymentAddress ? shippingAddress ; attributo readonly DOMString ? shippingOption ; attributo PaymentShippingType ? shippingType ; attributo EventHandler onshippingaddresschange ; attributo EventHandler onshippingoptionchange ; };

Nota

Uno sviluppatore crea un PaymentRequest per effettuare una richiesta di pagamento. Questo è in genere associato all’utente che avvia un processo di pagamento (ad esempio, attivando un pulsante “Acquista”, “Acquista” o “Acquista” su un sito web, selezionando un “Accensione” in un gioco interattivo o pagando a un chiosco in una struttura di parcheggio). PaymentRequest consente agli sviluppatori di scambiare informazioni con l’ agente utente mentre l’utente sta fornendo input (fino al punto di approvazione dell’utente o di rifiuto della richiesta di pagamento).

Gli attributi shippingAddress , shippingOption e shippingType vengono popolati durante l’elaborazione se il membro requestShipping è impostato.

Poiché la visualizzazione simultanea di più interfacce utente PaymentRequest potrebbe confondere l’utente, questa specifica limita lo user agent a visualizzarne uno alla volta tramite il metodo show() . Questo è garantito da una richiesta di pagamento che sta mostrando booleano.

3.1 Costruttore

PaymentRequest viene costruito utilizzando l’elenco di data metodo fornito, inclusi tutti i data specifici del metodo di pagamento , i dettagli del pagamento e le opzioni di pagamento.

Il PaymentRequest( methodData , details , options ) DEVE agire come segue:

Se il documento responsabile dell’oggetto delle impostazioni correnti non è autorizzato a utilizzare la funzione indicata dal nome dell’attributo allowpaymentrequest , quindi lanciare una DOMException ” SecurityError “.
Lascia che serializedMethodData sia una lista vuota.
Stabilire l’id della richiesta:
1. Se i dettagli . manca l’ id , aggiungi un membro id ai dettagli e imposta il suo valore alla stringa che identifica in modo univoco questa richiesta di pagamento. È RACCOMANDATO che la stringa sia un UUID [ RFC4122 ].
Elaborare metodi di pagamento:
1. Se la lunghezza della sequenza methodData è zero, quindi lancia un TypeError , eventualmente informando lo sviluppatore che è richiesto almeno un metodo di pagamento .
2. Per ogni metodo di pagamento del metodo Dati :
  1. Eseguire i passaggi per convalidare un identificatore del metodo di pagamento con paymentMethod . supportedMethods . Se restituisce false, quindi genera un’eccezione RangeError e termina questo algoritmo. Facoltativamente, informa lo sviluppatore che l’identificativo del metodo di pagamento non è valido.
  2. Se manca il membro di data di paymentMethod , lasciare serializedData essere nullo. Altrimenti, lascia che serializedData sia il risultato del serialMethod di serializzazione JSON . data in una stringa. Restituisci eventuali eccezioni.
  3. Aggiungi la tupla ( paymentMethod . SupportedMethods , serializedData ) a serializedMethodData .
Elabora il totale:
1. Controlla e canonicalizza i dettagli totali . total . amount Restituisci eventuali eccezioni.
Se è presente il membro dei dettagli displayItems , quindi per ogni voce nei dettagli . displayItems :
1. Controlla e canonizza l’importo . amount Restituisci eventuali eccezioni.
Consentire selectedShippingOption essere nullo.
Se il membro di opzioni requestShipping è presente e impostato su true, elabora le opzioni di spedizione:
1. Consenti alle opzioni di essere una sequence vuota < PaymentShippingOption >.
2. Se il membro dei dettagli shippingOptions è presente, allora:
  1. Lascia che gli ID visti siano una lista vuota.
  2. Imposta le opzioni per i dettagli . shippingOptions .
  3. Per ogni opzione in opzioni :
    1. Controlla e canonizza l’importo . amount Restituisci eventuali eccezioni.
    2. Se seenIDs contiene un’opzione . id , quindi lancia un TypeError . Facoltativamente, informa lo sviluppatore che gli ID delle opzioni di spedizione devono essere univoci.
    3. Altrimenti, aggiungi l’ opzione . id to seenIDs .
  4. Per ogni opzione in opzioni :
    1. Se l’ opzione . selected è vero, quindi imposta l’ opzione SelectedShippingOption su . id .
3. Imposta i dettagli . shippingOptions alle opzioni .
Lascia che serializedModifierData sia una lista vuota.
Elaborazione dei modificatori dei dettagli di pagamento:
1. Lascia che i modificatori siano una sequence vuota < PaymentDetailsModifier >.
2. Se il membro dei dettagli dei modifiers è presente, allora:
  1. Imposta i modificatori sui dettagli . modifiers
  2. Per ogni modificatore di modificatori :
    1. Se il membro total del modificatore è presente, allora:
      1. Controlla e canonicalizza il modificatore totale . total . amount Restituisci eventuali eccezioni.
    2. Se è presente il membro del modificatore additionalDisplayItems , quindi per ogni elemento del modificatore . additionalDisplayItems :
      1. Controlla e canonizza l’importo . amount Restituisci eventuali eccezioni.
    3. Se manca il membro di data del modificatore , lasciare serializedData essere nullo. Altrimenti, lascia che serializedData sia il risultato del modificatore serializzatore JSON . data in una stringa. Restituisci eventuali eccezioni.
    4. Aggiungi serializedData a serializedModifierData .
    5. Rimuovi il membro data del modificatore , se presente.
3. Imposta i dettagli . modifiers ai modificatori .
Lascia che la richiesta sia una nuova PaymentRequest .
Imposta richiesta [[opzioni]] per opzioni .
Imposta richiesta [[stato]] su ” creato “.
Imposta richiesta [[aggiornamento]] su falso.
Imposta richiesta [[dettagli]] per i dettagli .
Imposta richiesta [[serializedModifierData]] su serializedModifierData .
Imposta richiesta [[serializedMethodData]] per serializedMethodData .
Imposta il valore dell’attributo shippingOption della richiesta su SelectedShippingOption .
Imposta il valore dell’attributo shippingAddress su richiesta su null.
Se le opzioni . requestShipping è impostato su true, quindi imposta il valore dell’attributo shippingType su richiesta alle opzioni . shippingType . Altrimenti, impostalo su null.
Richiesta di ritorno

3.2 attributo `id`

Quando ottiene, l’attributo id restituisce i [[dettagli]] di PaymentRequest . id .

3.3 metodo `show()`

Il metodo show() viene chiamato quando uno sviluppatore vuole iniziare l’interazione dell’utente per la richiesta di pagamento. Il metodo show() restituisce una promessa che verrà risolta quando l’ utente accetta la richiesta di pagamento . Un certo tipo di interfaccia utente verrà presentata all’utente per facilitare la richiesta di pagamento dopo il ritorno del metodo show() .

Non è possibile mostrare più PaymentRequest contemporaneamente nello stesso agente utente . Se un PaymentRequest è già visualizzato, chiamando show() -da qualsiasi sito Web- restituirà una promessa respinta con una AbortError ” DOMException “.

Il metodo show() DEVE agire come segue:

Lascia che la richiesta sia l’oggetto PaymentRequest su cui viene chiamato il metodo.
Lascia che il documento sia il documento associato dell’oggetto globale pertinente della richiesta .
Se il documento non è completamente attivo , restituire una promessa respinta con una AbortError ” DOMException “.
Facoltativamente, se l’ agente utente desidera disabilitare la chiamata a show() per proteggere l’utente, restituisce una promessa respinta con una DOMException ” SecurityError “. Ad esempio, il programma utente potrebbe richiedere che la chiamata venga attivata dall’attivazione dell’utente o limitare la velocità con cui una pagina può chiamare show() , come descritto nella sezione delle considerazioni sulla privacy . Nota Durante la fase di Candidate Recommendation, ci si aspetta che le implementazioni sperimentino in quest’area. Gli sviluppatori che utilizzano questa API devono indagare e anticipare tali esperimenti e capire in quali circostanze potrebbe verificarsi una DOMException ” SecurityError “. Se emerge un comportamento interoperabile tra i programmi utente, allora quel comportamento sarà standardizzato qui prima di progredire nella specifica lungo la traccia di raccomandazione del W3C .
Se richiesta [[stato]] non è ” creato “, quindi restituisce una promessa respinta con una InvalidStateError ” DOMException “.
Se la richiesta di pagamento dell’agent user sta mostrando boolean è vera, quindi restituisci una promessa respinta con una AbortError ” DOMException “.
Imposta richiesta [[stato]] su ” interattivo “.
Lascia che acceptPromise sia una nuova promessa .
Imposta richiesta [[acceptPromise]] per accettarePromuovere .
opzionalmente:
1. Rifiuta acceptPromise con una AbortError ” DOMException “.
2. Imposta richiesta [[stato]] a ” chiuso “.
3. Restituire acceptPromise .
Nota Ciò consente all’agente dell’utente di agire come se l’utente avesse immediatamente interrotto la richiesta di pagamento , a sua discrezione. Ad esempio, nelle modalità di “navigazione privata” o simili, i programmi utente potrebbero trarre vantaggio da questo passaggio.
Imposta la richiesta di pagamento dell’agente utente sta mostrando booleano su true.
Return acceptPromise ed esegue i restanti passi in parallelo .
Lascia che i gestori siano un insieme non ordinato vuoto.
Per ogni metodo di pagamento tupla in richiesta . [[serializedMethodData]] :
1. Lascia che l’ identificatore sia il primo elemento nella tupla paymentMethod .
2. Consenti ai dati di essere il risultato dell’analisi JSON del secondo elemento nella tupla paymentMethod .
3. Se richiesto dalla specifica che definisce l’ identificatore , convertire i dati in un valore IDL. Altrimenti, converti in oggetto .
4. Se la conversione genera un errore, rifiuta acceptPromise con quell’errore e termina questo algoritmo.
5. Se l’agente utente ha un gestore di pagamenti registrato che supporta l’ identificatore , controllare se il gestore di pagamento è autorizzato e in grado di gestire la richiesta di pagamento con i dati . Se l’assegno ritorna in senso affermativo, aggiungi l’addetto al pagamento ai gestori .
Se i gestori sono vuoti, quindi respingere acceptPromise con una eccezione DOMException ” NotSupportedError ” e impostare la richiesta di pagamento dell’agent user sta mostrando booleano su false.
Altrimenti, presenta un’interfaccia utente per consentire all’utente di interagire con i gestori . L’agente utente DOVREBBE dare priorità alla preferenza dell’utente nella presentazione dei metodi di pagamento. Per il gestore di pagamenti selezionato dall’utente finale, l’ interprete DEVE passare il secondo elemento convertito nella tupla paymentMethod . Facoltativamente, l’agente utente DOVREBBE inviare i dati appropriati dalla richiesta al gestore di pagamento selezionato dall’utente al fine di guidare l’utente attraverso il processo di pagamento. Questo include i vari attributi e gli slot interni di richiesta (alcuni potrebbero essere esclusi per motivi di privacy, se del caso). Il acceptPromise verrà successivamente risolto o rifiutato dall’utente che accetta l’algoritmo di richiesta di pagamento o l’ utente interrompe l’algoritmo di richiesta di pagamento , che viene attivato tramite l’interazione con l’interfaccia utente. Se il documento smette di essere completamente attivo mentre viene mostrata l’interfaccia utente, oppure non è più quando viene raggiunto questo passaggio, l’interfaccia utente DOVREBBE essere nascosta, e acceptPromise DOVREBBE essere respinta con una AbortError ” DOMException “.

3.4 metodo `abort()`

Il metodo abort() viene chiamato se uno sviluppatore desidera dire all’agente utente di interrompere la richiesta di pagamento e di distruggere qualsiasi interfaccia utente che potrebbe essere mostrata. L’ abort() può essere chiamato solo dopo che è stato chiamato il metodo show() (vedi stati ) e prima che [[acceptPromise]] di questa istanza sia stato risolto. Ad esempio, gli sviluppatori potrebbero scegliere di farlo se i prodotti che stanno vendendo sono disponibili solo per un periodo di tempo limitato. Se l’utente non accetta la richiesta di pagamento entro il periodo di tempo consentito, la richiesta verrà annullata.

Un agente utente potrebbe non essere sempre in grado di abortire una richiesta. Ad esempio, se l’ agente utente ha delegato la responsabilità della richiesta a un’altra app. In questa situazione, abort() rifiuterà la promessa restituita.

Vedi anche l’algoritmo quando l’ utente interrompe la richiesta di pagamento .

Il metodo abort() DEVE agire come segue:

Lascia che la richiesta sia l’oggetto PaymentRequest su cui viene chiamato il metodo.
Se il valore della richiesta . [[stato]] non è ” interattivo “, quindi lancia una ” InvalidStateError ” DOMException .
Lascia che la promessa sia una nuova promessa .
Restituire la promessa ed eseguire i passaggi rimanenti in parallelo .
Prova ad interrompere l’interazione dell’utente corrente e chiudi l’interfaccia utente rimanente.
Accodare un’attività sull’origine dell’attività di interazione dell’utente per eseguire le seguenti operazioni:
1. Se non è possibile interrompere l’interazione dell’utente corrente, rifiutare la promessa con InvalidStateError ” DOMException ” e interrompere questi passaggi.
2. Imposta il valore della richiesta dello slot interno. [[stato]] a ” chiuso “.
3. Rifiuta la richiesta di promessa. [[acceptPromise]] con una AbortError ” DOMException “.
4. Risolvi la promessa con indefinito.

3.5 metodo `canMakePayment()`

Il metodo canMakePayment() può essere utilizzato dallo sviluppatore per determinare se l’oggetto PaymentRequest può essere utilizzato per effettuare un pagamento, prima di chiamare show() . Restituisce una Promessa che verrà soddisfatta con true se l’ agente utente supporta uno dei metodi di pagamento desiderati forniti al costruttore PaymentRequest e false se nessuno è supportato. Se il metodo viene chiamato troppo spesso, l’ NotAllowedError potrebbe invece restituire una promessa respinta con una NotAllowedError ” DOMException “, a sua discrezione.

Il metodo canMakePayment() DEVE agire come segue:

Lascia che la richiesta sia l’oggetto PaymentRequest su cui è stato chiamato il metodo.
Se richiesta [[stato]] non è ” creato “, quindi restituisce una promessa respinta con una InvalidStateError ” DOMException “.
Facoltativamente, a discrezione dell’agente utente , restituisce una promessa respinta con una NotAllowedError ” DOMException “. Nota Ciò consente agli agenti utente di applicare l’euristica per rilevare e prevenire l’abuso del metodo canMakePayment() per scopi di fingerprinting, come la creazione di oggetti PaymentRequest con una varietà di metodi di pagamento supportati e la chiamata di canMakePayment() su di essi uno dopo l’altro. Ad esempio, un agente utente può limitare il numero di chiamate riuscite che è possibile effettuare in base al contesto di esplorazione di primo livello o al periodo di tempo in cui sono state effettuate tali chiamate.
Lascia che la promessa sia una nuova promessa .
Restituire la promessa ed eseguire i passaggi rimanenti in parallelo .
Per ogni metodo Dati in richiesta . [[serializedMethodData]] :
1. Se methodData . supportedMethods è un identificatore del metodo di pagamento supportato (incluse le sue funzionalità specifiche del metodo di pagamento ), risolve la promessa con true e annulla questo algoritmo.
Risolvi la promessa con il falso.

3.6 attributo `shippingAddress`

L’attributo shippingAddress PaymentRequest viene popolato quando l’utente fornisce un indirizzo di spedizione. È nullo di default. Quando un utente fornisce un indirizzo di spedizione, l’ indirizzo di spedizione ha cambiato le corse dell’algoritmo .

3.7 attributo `shippingType`

L’attributo shippingType PaymentRequest è il tipo di spedizione utilizzato per soddisfare la transazione. Il suo valore è un valore enum di PaymentShippingType , o null se nessuno è fornito dallo sviluppatore durante la construction (vedi membro shippingType PaymentOptions ).

3.8 attributo `onshippingaddresschange`

Un attributo onshippingaddresschange PaymentRequest è un EventHandler per un PaymentRequestUpdateEvent denominato shippingaddresschange .

3.9 attributo `shippingOption`

L’attributo shippingOption PaymentRequest viene popolato quando l’utente sceglie un’opzione di spedizione. È nullo di default. Quando un utente sceglie un’opzione di spedizione, l’ opzione di spedizione ha modificato le esecuzioni dell’algoritmo .

3.10 attributo `onshippingoptionchange`

Un attributo onshippingoptionchange PaymentRequest è un EventHandler per un PaymentRequestUpdateEvent denominato shippingoptionchange .

3.11 slot interni

Le istanze di PaymentRequest vengono create con gli slot interni nella seguente tabella:

Scanalatura interna	Descrizione ( non normativa )
[[serializedMethodData]]	Il `methodData` fornito al costruttore, ma rappresentato come tuple contenente metodi supportati e una stringa o null per i dati (anziché il modulo dell’oggetto originale).
[[serializedModifierData]]	Un elenco contenente il modulo stringa serializzato di ciascun membro `data` per ciascun elemento corrispondente nella sequenza [[dettagli]] . modificatore , o null se nessun membro del genere era presente.
[[dettagli]]	L’attuale `PaymentDetailsBase` per la richiesta di pagamento inizialmente fornita al costruttore e quindi aggiornata con le chiamate a updateWith () . Si noti che tutti `data` membri di `data` delle istanze `PaymentDetailsModifier` contenuti nel membro dei `modifiers` verranno rimossi, poiché vengono invece archiviati in forma serializzata nello slot interno [[serializedModifierData]] .
[[opzioni]]	Le `PaymentOptions` fornite al costruttore.
[[stato]]	Lo stato attuale della richiesta di pagamento, che passa da: ” creato ” La richiesta di pagamento è costruita e non è stata presentata all’utente. ” interattivo ” La richiesta di pagamento viene presentata all’utente. ” chiuso ” La richiesta di pagamento completata. Le transizioni di stato sono illustrate nella figura seguente: Figura 1 Il costruttore imposta lo stato iniziale su ” creato “. Il metodo `show()` cambia lo stato in ” interattivo “. Da lì, il metodo `abort()` o qualsiasi altro errore possono inviare lo stato a ” chiuso “; allo stesso modo, l’ utente accetta l’algoritmo di richiesta di pagamento e l’ utente interrompe l’algoritmo di richiesta di pagamento che cambierà lo stato in ” chiuso “.
[[in aggiornamento]]	true c’è una chiamata updateWith () in sospeso per aggiornare la richiesta di pagamento e false altrimenti.
[[acceptPromise]]	La promessa in sospeso creata durante lo spettacolo che verrà risolta se l’utente accetta la richiesta di pagamento.

4. Dizionario `PaymentMethodData`

dizionario PaymentMethodData { richiesto DOMString supportedMethods ; data oggetto ; };

Un dizionario PaymentMethodData viene utilizzato per indicare un insieme di metodi di pagamento supportati e qualsiasi dato specifico del metodo di pagamento associato per tali metodi. membro supportedMethods Un identificatore del metodo di pagamento per un metodo di pagamento accettato dal sito web del commerciante. membro dei data Un oggetto che fornisce informazioni opzionali che potrebbero essere necessarie con i metodi di pagamento supportati. Se fornito, sarà serializzato JSON . Nota

Il valore di supportedMethods stato modificato da matrice a stringa, ma il nome è stato lasciato al plurale per mantenere la compatibilità con i contenuti esistenti sul Web.

5. Dizionario `PaymentCurrencyAmount`

dizionario PaymentCurrencyAmount { richiesto currency DOMString ; richiesto value DOMString ; // Nota: currencySystem è "a rischio" di essere rimosso! DOMString currencySystem = "urn: iso: std: iso: 4217" ; };

Un dizionario PaymentCurrencyAmount viene utilizzato per fornire importi monetari. Funzionalità a rischio

Questa funzione è stata contrassegnata come ” a rischio “. Se desideri che questa funzionalità rimanga nelle specifiche, descrivi la tua pratica nel numero 490 . membro di currencySystem Un URL che indica il sistema currency appartiene l’identificatore di currency . Per impostazione predefinita, il valore è ” urn:iso:std:iso:4217 ” che indica che la currency è definita da [ ISO4217 ] (ad esempio, USD per dollari USA). membro della currency Una stringa contenente un identificatore di valuta. Il valore della currency può essere qualsiasi stringa valida all’interno del sistema di valuta indicato da currencySystem .

Quando si utilizza [ ISO4217 ], tutti i codici alfabetici a 3 lettere ben formattati sono consentiti (ovvero, i codici numerici non sono supportati). La loro forma canonica è maiuscola. Tuttavia, l’insieme di combinazioni di codice valuta per cui sono disponibili simboli di valuta localizzati dipende dall’implementazione. Dove un simbolo di valuta localizzato non è disponibile, un agente utente DOVREBBE usare U + 00A4 (¤) per la formattazione. membro di value Un valore monetario decimale valido contenente un importo monetario.

L’esempio seguente mostra come rappresentare US $ 55,00. Esempio 9

  {
   "valuta" : "USD" ,
   "valore" : "55,00"
 }

5.1 Controllori di validità

Una stringa JavaScript è un valore monetario decimale valido se è costituito dai seguenti punti di codice nell’ordine specificato: [ INFRA ]

Opzionalmente, un singolo U + 002D (-), per indicare che l’importo è negativo.
Uno o più punti di codice nell’intervallo da U + 0030 (0) a U + 0039 (9).
Facoltativamente, un singolo U + 002E (.) Seguito da uno o più punti di codice nell’intervallo da U + 0030 (0) a U + 0039 (9).

Nota

La seguente espressione regolare è un’implementazione della definizione di cui sopra.

  ^ -?? [0-9] + (. \ [0-9] +) $

Per verificare e autorizzare l’ importo dato un importo PaymentCurrencyAmount , eseguire i seguenti passaggi:

Se importo . currencySystem non è ” urn:iso:std:iso:4217 “, terminare questo algoritmo.
Sia isValidCurrency il risultato della chiamata all’operazione astratta IsWellFormedCurrencyCode con l’ importo . currency come argomento.
Se isValidCurrency è false, quindi genera un’eccezione RangeError e termina questo algoritmo, eventualmente informando lo sviluppatore che la valuta non è valida.
Se importo . value non è un valore monetario decimale valido , genera un TypeError , eventualmente informando lo sviluppatore che la valuta non è valida.
Imposta la quantità . currency al risultato dell’importo ASCII in maiuscolo . currency .

Per verificare e canonizzare il totale dato un totale di PaymentCurrencyAmount , eseguire i seguenti passaggi:

Se totale . currencySystem non è ” urn:iso:std:iso:4217 “, terminare questo algoritmo.
Controlla e canonicalizza l’importo dell’importo . Restituisci eventuali eccezioni.
Se il primo punto di codice del valore è U + 002D (-), quindi lancia un TypeError informa facoltativamente lo sviluppatore che un totale non può essere un numero negativo.

6. dettagli di pagamento dizionari

6.1 `PaymentDetailsBase` dizionario

dizionario PaymentDetailsBase{ sequenza di < PaymentItem> displayItems ; sequenza < PaymentShippingOption> shippingOptions ; sequenza < PaymentDetailsModifier> modifiers ; };

displayItems membro Una sequenza di PaymentItemdizionari contiene voci per la richiesta di pagamento che l’ agente utente MAGGIO visualizzare. Ad esempio, potrebbe includere i dettagli di prodotti o rottura di imposte e spese di spedizione. E ‘facoltativo per fornire queste informazioni. Nota È responsabilità dello sviluppatore a verificare che l’ totalimporto è la somma di questi elementi. shippingOptions membro Una sequenza contenente le diverse opzioni di spedizione per l’utente di scegliere.

If an item in the sequence has the selected member set to true, then this is the shipping option that will be used by default and shippingOption will be set to the id of this option without running the shipping option changed algorithm . Authors SHOULD NOT set selected to true on more than one item. If more than one item in the sequence has selected set to true, then the user agent selects the last one in the sequence.

The shippingOptions member is only used if the PaymentRequest was constructed with PaymentOptions requestShipping set to true. Nota If the sequence has an item with the selected member set to true, then authors are responsible for ensuring that the total member includes the cost of the shipping option. This is because no shippingoptionchange event will be fired for this option unless the user selects an alternative option first. modifiers member A sequence of PaymentDetailsModifier dictionaries that contains modifiers for particular payment method identifiers. For example, it allows you to adjust the total amount based on payment method.

6.2 `PaymentDetailsInit` dictionary

dictionary PaymentDetailsInit : PaymentDetailsBase { DOMString id ; required PaymentItem total ; };

Nota The PaymentDetailsInit dictionary is used in the construction of the payment request.

In addition to the members inherited from the PaymentDetailsBase dictionary, the following members are part of the PaymentDetailsInit dictionary:id member A free-form identifier for this payment request. Nota If an id member is not present, then the user agent will generate a unique identifier for the payment request during construction . total member A PaymentItem containing a non-negative total amount for the payment request. Nota Algorithms in this specification that accept a PaymentDetailsInit dictionary will throw if the total . amount . value is a negative number.

6.3 `PaymentDetailsUpdate` dictionary

dictionary PaymentDetailsUpdate : PaymentDetailsBase { DOMString error ; PaymentItem total ; };

Il PaymentDetailsUpdatedizionario viene utilizzato per aggiornare la richiesta di pagamento tramite updateWith () .

Oltre ai membri ereditati dal PaymentDetailsBasedizionario, i seguenti membri fanno parte del PaymentDetailsUpdatedizionario:error membro Una stringa leggibile. Quando la richiesta di pagamento viene aggiornato tramite updateWith () , la PaymentDetailsUpdatepuò contenere un messaggio nel errormembro che verrà visualizzato all’utente, se la PaymentDetailsUpdateindica che non ci sono validi shippingOptions(e PaymentRequestè stato costruito con l’ requestShippingopzione impostata su true). Questo può essere usato per spiegare il motivo per cui le merci non possono essere spediti all’indirizzo di spedizione scelta, o qualsiasi altro motivo per cui non sono disponibili opzioni di spedizione. total membro A PaymentItemcontiene il non negativo amount. Nota

Algoritmi in questa specifica che accettano un PaymentDetailsUpdatedizionario getterà se il total. amount. valueè un numero negativo.

7. `PaymentDetailsModifier` dizionario

dizionario PaymentDetailsModifier{ richiesto DOMString supportedMethods ; ; sequenza < > ; oggetto ;PaymentItem total PaymentItem additionalDisplayItems data };

Il PaymentDetailsModifierdizionario fornisce dettagli che modificano il PaymentDetailsBasebasano su un identificatore di metodo di pagamento . Esso contiene i seguenti membri:supportedMethods membro Un identificatore di metodo di pagamento . I membri della PaymentDetailsModifiersola applicano se l’utente seleziona questo metodo di pagamento . total membro Un PaymentItemvalore che sostituisce il totalmembro del PaymentDetailsInitdizionario per le modalità di pagamento identificativi del supportedMethodsmembro. additionalDisplayItems membro Una sequenza di PaymentItemdizionari fornisce elementi di visualizzazione aggiuntive che vengono aggiunti al displayItemsmembro in PaymentDetailsBaseInglese per le identificatori metodo di pagamento del supportedMethodsmembro. Il membro è comunemente utilizzato per aggiungere un elemento linea di sconto o maggiorazione che indica il motivo per il diverso totalimporto per il selezionato metodo di pagamento che l’agente utente MAGGIO visualizzare. Nota

È responsabilità dello sviluppatore a verificare che l’ totalimporto è la somma della displayItemse additionalDisplayItems.data membro Un oggetto che fornisce informazioni facoltative che potrebbe essere necessario per i metodi di pagamento supportati. Se in dotazione, sarà JSON-serializzato .

8. `PaymentShippingType` enum

enum PaymentShippingType{ "spedizione" , "consegna" , "pick-up" };

” shipping” Questa è l’impostazione predefinita e si riferisce all’indirizzo vengono raccolti come destinazione per la spedizione. ” delivery” Ciò si riferisce all’indirizzo in raccolta come utilizzato per la consegna. Questo è comunemente più veloce di spedizione. Ad esempio, potrebbe essere utilizzato per la consegna di cibo. ” pickup” Ciò si riferisce all’indirizzo vengono raccolti come parte di un pickup servizio. Per esempio, questo potrebbe essere l’indirizzo per il ritiro di lavanderia.

9. `PaymentOptions` dizionario

dizionario PaymentOptions{ boolean requestPayerName = falso ; boolean requestPayerEmail = falso ; boolean requestPayerPhone = falso ; boolean requestShipping = falso ; = "Spedizione" ;PaymentShippingType shippingType };

Nota

Il PaymentOptionsdizionario viene passato al PaymentRequestcostruttore e fornisce informazioni sulle opzioni desiderate per la richiesta di pagamento.requestPayerName membro Un valore booleano che indica se l’ user agent DOVREBBE raccogliere e restituire il nome del pagatore come parte della richiesta di pagamento. Ad esempio, questo sarebbe impostata su true per consentire un mercante di fare una prenotazione a nome del pagatore. requestPayerEmail membro Un valore booleano che indica se l’ user agent DOVREBBE raccogliere e restituire l’indirizzo e-mail del pagatore come parte della richiesta di pagamento. Ad esempio, questo sarebbe impostata su true per consentire un mercante di e-mail una ricevuta. requestPayerPhone membro Un valore booleano che indica se l’ user agent DOVREBBE raccogliere e restituire il numero di telefono del pagatore come parte della richiesta di pagamento. Ad esempio, questo sarebbe impostata su true per consentire un mercante di telefonare ad un cliente con una richiesta di fatturazione. requestShipping membro Un valore booleano che indica se l’ user agent DOVREBBE raccogliere e restituire un indirizzo di spedizione come parte della richiesta di pagamento. Ad esempio, questo sarebbe impostata su true quando beni fisici devono essere spediti dal commerciante per l’utente. Questo sarebbe impostata su false per un solo online operazione di acquisto elettronico. shippingType membro Uno ShippingType valore enum. Alcune operazioni richiedono un indirizzo per la consegna, ma il termine “spedizione” non è appropriato. Ad esempio, “pizza a domicilio” e non “il trasporto della pizza” e “pick-up di lavanderia” non “il trasporto di lavanderia”. Se requestShippingè impostato su true, allora il shippingTypemembro può influenzare il modo in cui l’ agente utente presenta l’interfaccia utente per la raccolta l’indirizzo di spedizione.Il shippingTypemembro riguarda solo l’interfaccia utente per la richiesta di pagamento.

10. `PaymentItem` dizionario

dizionario PaymentItem{ richiesto DOMString label ; richiesta ; PaymentCurrencyAmount amount boolean pending = falso ; };

Una sequenza di uno o più PaymentItemdizionari è incluso nel PaymentDetailsBasedizionario per indicare ciò che la richiesta di pagamento è per e il valore richiesto.label membro Una descrizione leggibile della voce. L’ agente utente può visualizzare questo all’utente. amount membro A PaymentCurrencyAmountche contiene l’importo monetario per la voce. pending membro Un booleano. Se impostato su true significa che l’ amountutente non è definitiva. Questo è comunemente usato per mostrare elementi come quantità di spedizione o fiscali che dipendono selezione di indirizzo di spedizione o opzione di spedizione. I programmi utente POSSONO indicare i campi in sospeso nel l’interfaccia utente per la richiesta di pagamento.

11. `PaymentAddress` interfaccia

[ SecureContext ,
  Esposto = Finestra ]
Interfaccia PaymentAddress{ [ default ] oggetto toJSON (); sola lettura attributo DOMString country ; attributo readonly FrozenArray < DOMString > addressLine ; sola lettura attributo DOMString region ; sola lettura attributo DOMString city ; sola lettura attributo DOMString dependentLocality ; sola lettura attributo DOMString postalCode ; sola lettura attributo DOMString sortingCode ; sola lettura attributo DOMString languageCode ; sola lettura attributo DOMString organization ; sola lettura attributo DOMString recipient ; sola lettura attributo DOMString phone ; };

11.1 `toJSON()` metodo

Quando viene chiamato, corre [ WEBIDL ] ‘s operazione predefinita toJSON .

11.2 `country` attributo

Quando si ottiene, restituisce il valore dei PaymentAddress‘s [[paese]] slot interno.

11.3 `addressLine` attributo

Quando si ottiene, restituisce il valore dei PaymentAddress‘s [[linea indirizzo]] di slot interno.

11.4 `region` attributo

Quando si ottiene, restituisce il valore del PaymentAddress‘s [[regione]] slot interno.

11.5 `city` attributo

Quando si ottiene, restituisce il valore dei PaymentAddress‘s [[città]] slot interno.

11.6 `dependentLocality` attributo

Quando si ottiene, restituisce il valore dei PaymentAddress‘s [[dependentLocality]] di slot interno.

11.7 `postalCode` attributo

Quando si ottiene, restituisce il valore dei PaymentAddress‘s [[postalCode]] di slot interno.

11.8 `sortingCode` attributo

Quando si ottiene, restituisce il valore dei PaymentAddress‘s [[sortingCode]] di slot interno.

11.9 `languageCode` attributo

Quando si ottiene, restituisce il valore dei PaymentAddress‘s [[languageCode]] di slot interno.

11.10 `organization` attributo

Quando si ottiene, restituisce il valore dei PaymentAddress‘s [[organizzazione]] slot interno.

11.11 `recipient` attributo

Quando si ottiene, restituisce il valore dei PaymentAddress‘s [[destinatario]] slot interno.

11.12 `phone` attributo

Quando si ottiene, restituisce il valore del PaymentAddress‘s [[telefono]] slot interno.

11.13 slot interni

slot interno	Descrizione ( non-normativo )
[[nazione]]	Un [ ISO3166 ] codice alfa-2. La forma canonica è maiuscolo. Ad esempio, “JP”.
[[Linea indirizzo]]	La parte più specifica dell’indirizzo. Si può comprendere, ad esempio, un nome della via, numero civico, numero di appartamento, un percorso di consegna rurali, istruzioni descrittive, o un numero di casella postale.
[[regione]]	La suddivisione amministrativa livello superiore del paese. Ad esempio, questo può essere uno stato, una provincia, un’oblast, o di una prefettura.
[[città]]	La porzione di città / paese dell’indirizzo.
[[DependentLocality]]	La frazione dipendenti o sublocality all’interno di una città. Ad esempio, utilizzato per i quartieri, borghi, quartieri, o del Regno Unito località dipendenti.
[[codice postale]]	Il codice postale o CAP, noti anche come codice PIN in India.
[[SortingCode]]	Il codice di ordinamento come usato, per esempio, la Francia.
[[LanguageCode]]	Il [ BCP47 tag] lingua per l’indirizzo, in forma canonica . E ‘utilizzato per determinare i separatori di campo e l’ordine dei campi durante la formattazione l’indirizzo per la visualizzazione.
[[organizzazione]]	L’organizzazione, azienda, società o istituzione a questo indirizzo.
[[destinatario]]	Il nome della persona ricevente o di contatto. Questo utente può, in determinate circostanze, contenere informazioni più righe. Ad esempio, potrebbe contenere “la cura di” informazioni.
[[Telefono]]	Il numero di telefono della persona ricevente o di contatto.

12. `PaymentShippingOption` dizionario

dizionario PaymentShippingOption{ richiesto DOMString id ; richiesto DOMString label ; richiesta ; PaymentCurrencyAmount amount boolean selected = falso ; };

Il PaymentShippingOptiondizionario ha membri che descrivono un opzione di spedizione. Gli sviluppatori possono fornire all’utente una o più opzioni di spedizione chiamando l’updateWith () il metodo in risposta a un evento di modifica.id membro Un identificatore di stringa utilizzata per riferimento a questo PaymentShippingOption. Esso deve essere unico per un dato PaymentRequest. label membro Una descrizione stringa leggibile della voce. L’ agente utente DOVREBBE utilizzare questa stringa per visualizzare l’opzione di spedizione per l’utente. amount membro A PaymentCurrencyAmountche contiene l’importo monetario per la voce. selected membro Un booleano. Quando true, indica che questo è il predefinito selezionato PaymentShippingOptionin sequenza. I programmi utente DOVREBBE visualizzare questa opzione di default nell’interfaccia utente.

13. `PaymentComplete` enum

enum PaymentComplete{ "fallire" , "successo" , "sconosciuto" };

” fail” Indica che l’elaborazione del pagamento non è riuscito. L’ agente utente MAGGIO visualizzare interfaccia utente che indica il fallimento. ” success” Indica che il pagamento è stato elaborato correttamente. L’ agente utente MAGGIO visualizzare interfaccia utente che indica il successo. ” unknown” Lo sviluppatore non ha indicato il successo o il fallimento e l’ user agent NON DEVONO visualizzare UI che indica il successo o il fallimento.

14. `PaymentResponse` interfaccia

[ SecureContext ,
  Esposto = Finestra ]
Interfaccia PaymentResponse{ [ default ] oggetto toJSON (); sola lettura attributo DOMString requestId ; sola lettura attributo DOMString methodName ; attributo readonly oggetto details ; attributo di sola lettura PaymentAddress? shippingAddress; in sola lettura attributo DOMString ? shippingOption; in sola lettura attributo DOMString ? payerName; in sola lettura attributo DOMString ? payerEmail; in sola lettura attributo DOMString ? payerPhone; Promessa <vuoto> completa ( opzionale risultato = "sconosciuto"PaymentComplete ); };

Nota

Una PaymentResponseviene restituito quando un utente ha selezionato un metodo di pagamento e approvato una richiesta di pagamento.

14.1 `toJSON()` metodo

Quando viene chiamato, corre [ WEBIDL ] ‘s operazione predefinita toJSON .

14.2 `methodName` attributo

Il metodo di identificazione di pagamento per il metodo di pagamento che l’utente ha selezionato per compiere l’operazione.

14.3 `details` attributo

Un oggetto o dizionario generato da un metodo di pagamento che un commerciante può utilizzare per elaborare o convalidare una transazione (a seconda del metodo di pagamento ). Nota Ogni metodo di pagamento identificatore standard , come ad esempio carta di base ( “basic-card”), definisce il proprio unico dizionario IDL per l’uso con l’ detailsattributo. La forma di questi dati (cioè, i suoi membri e loro tipi e formati corrispondenti) varia a seconda del metodo di pagamento standardizzato identificatore viene selezionato dall’utente finale.Analogamente, un metodo di pagamento identificatore basato su URL definisce la forma details. Tuttavia, come identificatori metodo di pagamento basati su URL non sono standardizzati dal W3C , gli sviluppatori hanno bisogno di consultare chi controlla l’URL per la forma prevista del detailsdell’oggetto.

14.4 `shippingAddress` attributo

Se il requestShippingcomponente sia stato impostato su true nel PaymentOptionspassato al PaymentRequestcostruttore, allora shippingAddresssarà l’indirizzo completo e definitivo di spedizione scelto dall’utente.

14.5 `shippingOption` attributo

Se il requestShippingcomponente sia stato impostato su true nel PaymentOptionspassato al PaymentRequestcostruttore, allora shippingOptionsarà idl’attributo della opzione di spedizione selezionata.

14.6 `payerName` attributo

Se il requestPayerNamecomponente sia stato impostato su true nel PaymentOptionspassato al PaymentRequestcostruttore, allora payerNamesarà il nome fornito dall’utente.

14,7 `payerEmail` attributo

Se il requestPayerEmailcomponente sia stato impostato su true nel PaymentOptionspassato al PaymentRequestcostruttore, allora payerEmailsarà l’indirizzo di posta elettronica scelto dall’utente.

14.8 `payerPhone` attributo

Se il requestPayerPhonecomponente sia stato impostato su true nel PaymentOptionspassato al PaymentRequestcostruttore, allora payerPhonesarà il numero di telefono scelto dall’utente.

14.9 `requestId` attributo

La corrispondente richiesta di pagamento idche ha generato questa risposta pagamento.

14.10 `complete()` metodo

Nota

Il complete()metodo viene chiamato dopo che l’utente ha accettato la richiesta di pagamento e la [[acceptPromise]] è stato risolto. Chiamando il complete()metodo indica l’ user agent che l’interazione pagamento è finita (e DEVONO causare alcuna interfaccia utente rimanente da chiudere).

Dopo la richiesta di pagamento è stata accettata e il PaymentResponserestituita al chiamante, ma prima che il chiamante chiama complete()l’interfaccia utente di richiesta di pagamento rimane in uno stato di attesa. A questo punto l’interfaccia utente non dovrebbe offrire un comando di annullamento in quanto l’accettazione della richiesta di pagamento è stato restituito. Tuttavia, se qualcosa va storto e lo sviluppatore non chiama mai complete()quindi l’interfaccia utente è bloccato.

Per questo motivo, le implementazioni MAGGIO imporre un timeout per gli sviluppatori per chiamare complete(). Se il timeout scade quindi l’attuazione si comporterà come se complete()è stato chiamato senza argomenti.

Il completo (risultato) il metodo deve agire come segue:

Lasciate che la promessa sia una nuova promessa .
Se il valore della slot interno [[completeCalled]] è vero, respingere promessa con una ” InvalidStateError” DOMException.
Altrimenti, impostare il valore della slot interno [[completeCalled]] true.
Rientro promessa ed eseguire i passaggi rimanenti in parallelo .
Chiudere qualsiasi interfaccia utente rimanente. L’ agente utente MAGGIO utilizzare il valore risultato di influenzare l’esperienza dell’utente.
Risolvere promessa con indefinito.

14.11 Slot interni

Istanze di PaymentResponsevengono creati con le scanalature interne nella tabella seguente:

slot interno	Descrizione ( non-normativo )
[[CompleteCalled]]	true se l’ intero metodo è stato chiamato e false altrimenti.

15. `PaymentRequest` e `iframe`elementi

Questa sezione non è normativo.

Per indicare che il cross-origine iframeè autorizzato a richiamare il pagamento richiesta API, l’ allowpaymentrequestattributo può essere specificato sulla iframeelemento.

16. Eventi

16.1 Sommario

Questa sezione non è normativo.

Nome dell’evento	Interfaccia	Inviato quando …
`shippingaddresschange`	`PaymentRequestUpdateEvent`	L’utente fornisce un nuovo indirizzo di spedizione.
`shippingoptionchange`	`PaymentRequestUpdateEvent`	L’utente sceglie una nuova opzione di spedizione.

16.2 `PaymentRequestUpdateEvent` interfaccia

[ Constructor ( DOMString  tipo , opzionale eventInitDictPaymentRequestUpdateEventInit ) , SecureContext , Esposto = Finestra ] Interfaccia PaymentRequestUpdateEvent: Event{ vuoto updateWith ( Promessa < PaymentDetailsUpdate> detailsPromise ); };

La PaymentRequestUpdateEventconsente agli sviluppatori di aggiornare i dettagli della richiesta di pagamento in risposta ad un’interazione con l’utente.

Il PaymentRequestUpdateEventcostruttore deve impostare la slot interno [[waitForUpdate]] false.

16.2.1 `updateWith()` metodo

Nota Se uno sviluppatore vuole aggiornare la richiesta di pagamento, quindi hanno bisogno di chiamare updateWith()e di fornire un PaymentDetailsUpdatedizionario, o una promessa per uno, che contiene i valori modificati che l’ user agent presenta per l’utente.Per impedire l’interfaccia utente da bloccare (e riflettere le modifiche apportate dal utente finale tramite l’interfaccia utente), sviluppatori devono chiamare immediatamente updateWith(). Esempio : come utilizzare `updateWith ()` correttamente.

 // ❌ Bad - questo non funzionerà! 
request.onshippingaddresschange = async ev => {
   // attendere va a segno di spunta accanto, e updateWith () non era 
  // chiamato prima che, così [[updatedUI]] viene impostata su true. 
  const Dettagli = attendono getNewDetails (oldDetails);
  // ? Troppo tardi, tiri "InvalidStateError".
  ev.updateWith (dettagli);
 };

// ✅ Buono - UI aspetterà. 
request.onshippingaddresschange = ev => {
   // Calling updateWith () con la promessa è ok ? 
  const promiseForNewDetails = getNewDetails (oldDetails);
  ev.updateWith (promiseForNewDetails);
 };

Inoltre, [[waitForUpdate]] impedisce riutilizzo di PaymentRequestUpdateEvent. Esempio : non può che chiamare `updateWith ()` una volta

 // ❌ Bad - chiamando updateWith () non funziona! 
request.addEventListener ( "shippingaddresschange" , ev => {
  ev.updateWith (dettagli); // Questo va bene. 
  // ? [[waitForUpdate]] è vero, getta un "InvalidStateError".
  ev.updateWith (otherDetails);
 });

// ❌ Bad - questo non funzionerà neanche! 
request.addEventListener ( "shippingaddresschange" , async ev => {
   const p = Promessa .resolve ({...} i dettagli);
  ev.updateWith (p);
  attendere p;
  // ? l'aggiornamento è completato, così [[updatedUI]] viene impostato 
  // true; questo getta "InvalidStateError"
  ev.updateWith ({...} newDetails);
 });

L’updateWith (detailsPromise) il metodo deve agire come segue:

Lasciate evento sia questo PaymentRequestUpdateEventesempio.
Se evento s’ isTrustedattributo è falso, allora poi lanciare un ‘ InvalidStateError‘ DOMException.
Se evento . [[waitForUpdate]] è vero, allora gettare un ” InvalidStateError” DOMException.
Lasciate richiesta sia il valore della manifestazione s’ targetattributo.
Se richiesta . [[Stato]] non è ” interattivo “, quindi gettare un ” InvalidStateError” DOMException.
Se richiesta . [[aggiornamento]] è vero, allora gettare un ” InvalidStateError” DOMException.
Impostare evento s’ arresto di propagazione bandiera e arresto immediato bandiera propagazione .
Set evento . [[waitForUpdate]] a true.
Set richiesta . [[aggiornamento]] a true.
L’ agente utente DOVREBBE disabilitare l’interfaccia utente che consente all’utente di accettare la richiesta di pagamento. Questo per garantire che il pagamento non è accettata fino a quando gli sviluppatori hanno fatto modifiche richieste dal cambiamento. Gli sviluppatori devono risolvere la detailsPromise per indicare che la richiesta di pagamento è di nuovo valido.
Ritorno dal metodo ed eseguire i passaggi rimanenti in parallelo .I passaggi rimanenti sono subordinata alla detailsPromise assestamento. Se detailsPromise mai si deposita poi la richiesta di pagamento è bloccato. Gli utenti DOVREBBE sempre essere in grado di annullare una richiesta di pagamento. Implementazioni MAGGIO scegliere di implementare un timeout per in attesa di aggiornamenti se detailsPromise non risolve in un ragionevole lasso di tempo. Se l’applicazione sceglie di implementare un timeout, devono eseguire le procedure descritte di seguito nel percorso “sul rifiuto”. Tale timeout è un errore fatale per la richiesta di pagamento.
Al rifiuto di detailsPromise :
1. Interrompere l’aggiornamento con una ” AbortError” DOMException.
Al compimento del detailsPromise con il valore di valore :
1. Lasciate che i dettagli siano il risultato della conversione di valore a un PaymentDetailsUpdatedizionario. Se questo genera un’eccezione, interrompere l’aggiornamento con l’eccezione generata.
2. Lascia serializedModifierData sia una lista vuota.
3. Lasciate selectedShippingOption essere nullo.
4. Lasciate shippingOptions essere un vuoto sequence< PaymentShippingOption>.
5. Convalidare e canonicalize i dettagli:
  1. Se il totalmembro del dettaglio è presente, allora:
    1. Controllare e canonicalize totali dettagli . total. amount. Se viene generata un’eccezione, quindi interrompere l’aggiornamento con questa eccezione.
  2. Se l’ displayItemselemento di dati è presente, allora per ogni elemento in dettagli . displayItems:
    1. Controllare e quantità canonicalize voce . amount. Se viene generata un’eccezione, quindi interrompere l’aggiornamento con questa eccezione.
  3. Se il shippingOptionsmembro del dettaglio è presente, e richiesta . [[opzioni]] . requestShippingè vero, allora:
    1. Impostare shippingOptions per i dettagli . shippingOptions.
    2. Lasciate seenIDs essere una lista vuota.
    3. Per ogni opzione in shippingOptions :
      1. Controllare e quantità canonicalize opzione . amount. Se viene generata un’eccezione, quindi interrompere l’aggiornamento con questa eccezione.
      2. Se seenIDs contiene l’opzione . id, Quindi interrompere l’aggiornamento con un TypeError.
      3. In caso contrario, aggiungere l’opzione . ida seenIDs .
    4. Per ogni opzione in shippingOptions :
      1. Se l’opzione . selectedè vero, allora impostare selectedShippingOption di opzione . id.
  4. Se il modifiersmembro del dettaglio è presente, allora:
    1. Lasciate che i modificatori la successione dettagli . modifiers.
    2. Lascia serializedModifierData sia una lista vuota.
    3. Per ogni modificatore in modificatori :PaymentDetailsModifier
      1. Eseguire la procedura per convalidare un identificatore metodo di pagamento con il modificatore . supportedMethods. Se restituisce false, quindi interrompere l’aggiornamento con RangeErrorun’eccezione. Opzionale, di informare lo sviluppatore che l’identificatore metodo di pagamento non è valido.
      2. Se l’ totalelemento di modificatore è presente, allora:
        
        Controllare e canonicalize totale modificatore . total. amount. Se viene generata un’eccezione, quindi interrompere l’aggiornamento con questa eccezione.
      3. Se l’ additionalDisplayItemselemento di modificatore è presente, allora per ogni elemento in modificatore . :PaymentItem additionalDisplayItems
        
        Controllare e quantità canonicalize voce . amount. Se viene generata un’eccezione, quindi interrompere l’aggiornamento con questa eccezione.
      4. Se l’ dataelemento di modificatore è mancante, lasciate serializedData essere nullo. In caso contrario, lasciare che serializedData essere il risultato di JSON-serializzazione modificatore . datain una stringa. Se JSON-serializzazione genera un’eccezione, quindi interrompere l’aggiornamento con questa eccezione.
      5. Aggiungere serializedData a serializedModifierData .
      6. Rimuovere il datamembro di modificatore , se presente.
6. Aggiornare il PaymentRequestutilizzando i nuovi dettagli:
  1. Se il totalmembro del dettaglio è presente, allora:
    1. Set richiesta . [[dettagli]] . totalper i dettagli . total.
  2. Se il displayItemsmembro del dettaglio è presente, allora:
    1. Set richiesta . [[dettagli]] . displayItemsper i dettagli . displayItems.
  3. Se il shippingOptionsmembro del dettaglio è presente, e richiesta . [[opzioni]] . requestShippingè vero, allora:
    1. Set richiesta . [[dettagli]] . shippingOptionsa shippingOptions .
    2. Impostare il valore della richiesta di s’ shippingOptionattributo selectedShippingOption .
  4. Se il modifiersmembro del dettaglio è presente, allora:
    1. Set richiesta . [[dettagli]] . modifiersper i dettagli . modifiers.
    2. Set richiesta . [[serializedModifierData]] a serializedModifierData .
  5. Se richiesta . [[opzioni]] . requestShippingè vero, e richiesta . [[dettagli]] . shippingOptionsè vuota, quindi lo sviluppatore ha significato che non ci sono opzioni di spedizione valide per l’indirizzo di spedizione attualmente scelto (data dalla richiesta s’ shippingAddress). In questo caso, l’agente utente DOVREBBE visualizzare un errore che indica questo, e MAGGIO indicare che l’indirizzo di spedizione attualmente scelto non è valido in qualche modo. L’agente utente DOVREBBE utilizzare il errormembro del dettaglio , se è presente, per dare ulteriori informazioni sul motivo per cui non ci sono opzioni di spedizione valide per quell’indirizzo.
In entrambi i casi, eseguire le seguenti operazioni, sia dopo il momento rifiuto o su gradini adempimento hanno concluso:
1. Set richiesta . [[aggiornamento]] false.
2. L’ agente utente DEVE aggiornare l’interfaccia utente basata sui valori mutate richiesta . L’agente utente DEVE riattivare elementi dell’interfaccia utente che potrebbero essere disattivate nei passaggi sopra, se del caso.

Se uno qualsiasi dei passi precedenti dico interrompere l’aggiornamento con un’eccezione un’eccezione , allora:

Interrompere l’interazione utente corrente e chiudere qualsiasi interfaccia utente rimanente.
Set richiesta . [[Stato]] a ” chiuso “.
Rifiuta la promessa richiesta . [[acceptPromise]] con un’eccezione .
Interrompere l’algoritmo.

Nota

Interrompere l’aggiornamento viene eseguito quando si verifica un errore fatale aggiornamento della richiesta di pagamento, come la dotazione detailsPromise rigetto, o il suo valore compimento contenente dati non validi. Questo potrebbe potenzialmente lasciare la richiesta di pagamento in uno stato incoerente in quanto lo sviluppatore non ha gestito con successo l’evento di modifica. Di conseguenza, le PaymentRequestpassa a una ” chiuso stato”. L’errore viene segnalato allo sviluppatore attraverso il rifiuto della [[acceptPromise]] , vale a dire, la promessa restituito da show().

I programmi utente potrebbe mostrare un messaggio di errore per l’utente quando ciò si verifica.

16.2.2 Slot interni

Istanze di PaymentRequestUpdateEventvengono creati con le scanalature interne nella tabella seguente:

slot interno	Descrizione ( non-normativo )
[[WaitForUpdate]]	Un booleano che indica se un `updateWith()`aggiornamento iniziato da è attualmente in corso.

16.2.3 `PaymentRequestUpdateEventInit` dizionario

Dizionario PaymentRequestUpdateEventInit: EventInit{ };

17. Algoritmi

Quando la fessura interna [[stato]] di un PaymentRequestoggetto viene impostato su ” interattivo “, l’ agente utente attiverà i seguenti algoritmi basati su interazione dell’utente.

17.1 Indirizzo di spedizione cambiato algoritmo

L’ indirizzo di spedizione è cambiato algoritmo viene eseguito quando l’utente fornisce un nuovo indirizzo di spedizione. Si deve eseguire le seguenti operazioni:

Lasciate richiesta sia l’ PaymentRequestoggetto che l’utente interagisce con.
Lasciate che il nome sia ” shippingaddresschange“.
Coda di un compito sulla fonte compito interazione dell’utente per eseguire le seguenti operazioni:
1. Lasciate che l’indirizzo sia una nuova istanza di PaymentAddress.
2. Imposta indirizzo . [[linea indirizzo]] al risultato di dividere riga dell’indirizzo fornito dall’utente in una matrice congelata . Se nessuno è stato fornito, insieme al vuoto matrice congelata . Nota Come dividere una linea di indirizzo dipende dal locale e al di là del campo di applicazione del presente disciplinare.
3. Imposta indirizzo . [[paese]] all’utente fornito countrycome maiuscola [ ISO3166 code] alfa-2, o per la stringa vuota se è stata fornita nessuna.
4. Impostare l’ indirizzo . [[telefono]] al numero di telefono fornito dall’utente per questo indirizzo di spedizione, opzionalmente formattato per aderire a [ E.164 ], o alla stringa vuota se è stato fornito nessuno. Nota : Privacy del numero di telefono Per mantenere la privacy dell’utente, gli esecutori devono essere consapevoli che il numero di telefono associato un indirizzo di spedizione potrebbe essere diverso o lo stesso da quella della finale di. Come tale, gli esecutori hanno bisogno di prendersi cura di non fornire il numero di telefono dell’utente finale al commerciante senza il consenso dell’utente finale.
5. Imposta indirizzo . [[languageCode]] a un tag di lingua Canonicalized , o alla stringa vuota se è stato fornito nessuno. Problema 608 : Attuazione della PaymentAddress.languageCode Implementatori stanno attualmente cercando di capire come derivare il languageCode‘valore di s in modo interoperabile. Durante la fase di CR di standardizzazione, gli esecutori saranno riferire sulla realizzazione di esperienze, possibilmente utilizzando Unicode CLDR per derivare la languageCode. Si prega di vedere i commenti di questo numero GitHub per follow-up, o partecipare alla discussione.
6. Imposta indirizzo . [[città]] alla città fornita dall’utente, o la stringa vuota se non è stata fornita.
7. Imposta indirizzo . [[dependentLocality]] alla località dipendente fornita dall’utente, o per la stringa vuota se è stata fornita nessuna.
8. Imposta indirizzo . [[organizzazione]] per l’organizzazione del destinatario fornita dall’utente, o alla stringa vuota se è stato fornito nessuno.
9. Imposta indirizzo . [[postalCode]] per il codice postale fornito dall’utente, o alla stringa vuota se è stato fornito nessuno.
10. Imposta indirizzo . [[destinatario]] al destinatario fornito dall’utente del rapporto, ovvero di una stringa vuota se non è stata fornita.
11. Imposta indirizzo . [[regione]] alla regione fornita dall’utente, o per la stringa vuota se è stata fornita nessuna.
12. Imposta indirizzo . [[sortingCode]] al codice di smistamento fornita dall’utente, o per la stringa vuota se è stata fornita nessuna.
13. Impostare l’ shippingAddressattributo di richiesta per affrontare .
14. Eseguire l’ algoritmo di aggiornamento PaymentRequest con richiesta e il nome .

17.2 opzione di spedizione cambiato algoritmo

L’ opzione di spedizione cambiato algoritmo viene eseguito quando l’utente sceglie una nuova opzione di spedizione. Si deve eseguire le seguenti operazioni:

Lasciate richiesta sia l’ PaymentRequestoggetto che l’utente interagisce con.
Lasciate che il nome sia ” shippingoptionchange“.
Coda di un compito sulla fonte compito interazione dell’utente per eseguire le seguenti operazioni:
1. Impostare l’ shippingOptionattributo di richiesta alla idstringa PaymentShippingOptionfornita dall’utente.
2. Eseguire l’ algoritmo di aggiornamento PaymentRequest con richiesta e il nome .

17,3 algoritmo PaymentRequest aggiornato

L’ algoritmo di aggiornamento PaymentRequest è gestito da altri algoritmi di cui sopra per generare un evento per indicare che un utente ha fatto una modifica a una PaymentRequestchiamata di richiesta con un nome evento di nome :

Se la richiesta di . [[aggiornamento]] è vero, quindi terminare questo algoritmo e non intraprendere ulteriori azioni. Solo un aggiornamento può avvenire in un momento. L’ agente utente DOVREBBE garantire che ciò non si verifica mai.
Se la richiesta di . [[stato]] non è impostato su ” interattivo “, quindi terminare questo algoritmo e prendere alcuna ulteriore azione. L’ agente utente interfaccia utente DOVREBBE garantire che ciò non si verifica mai.
Lasciate evento essere il risultato di creare un evento utilizzando PaymentRequestUpdateEvent.
Inizializzare evento s’ typeattributo nome .
Spedizione evento su richiesta .
Se evento . [[waitForUpdate]] è vero, disattivare qualsiasi parte dell’interfaccia utente che potrebbero causare un altro evento di aggiornamento da cuocere.

17,4 Utente accetta l’algoritmo di richiesta di pagamento

L’ utente accetta l’algoritmo di richiesta di pagamento viene eseguito quando l’utente accetta la richiesta di pagamento e conferma che vogliono pagare. Si deve accodare un compito sulla fonte compito interazione dell’utente per eseguire le seguenti operazioni:

Lasciate richiesta sia l’ PaymentRequestoggetto che l’utente interagisce con.
Se la richiesta di . [[aggiornamento]] è vero, quindi terminare questo algoritmo e non intraprendere ulteriori azioni. L’ agente utente interfaccia utente DOVREBBE garantire che ciò non si verifica mai.
Se richiesta . [[stato]] non è ” interattivo “, quindi terminare questo algoritmo e prendere alcuna ulteriore azione. L’ agente utente interfaccia utente DOVREBBE garantire che ciò non si verifica mai.
Se il requestShippingvalore della richiesta . [[opzioni]] è vero, allora se l’ shippingAddressattributo di richiesta è nullo o se l’ shippingOptionattributo di richiesta è nullo, allora terminare questo algoritmo e prendere alcuna ulteriore azione. L’ agente utente DOVREBBE garantire che ciò non si verifica mai.
Lasciate che la risposta sia una nuova PaymentResponse.
Impostare il requestIdvalore dell’attributo di risposta al valore della richiesta . [[dettagli]] . id.
Impostare il methodNamevalore dell’attributo di risposta al metodo di identificatore di pagamento per il metodo di pagamento che l’utente ha selezionato per accettare il pagamento.
Impostare il detailsvalore dell’attributo di risposta ad un oggetto contenente il metodo di pagamento oggetto specifico che verrà utilizzato dal commerciante per elaborare o convalidare la transazione. Sarà definito il formato di questa risposta per ciascun metodo di pagamento .
Se il requestShippingvalore della richiesta . [[opzioni]] è vero, quindi impostare l’ shippingAddressattributo della risposta al valore del shippingAddressattributo della richiesta . Altrimenti, impostarlo a null.
Se il requestShippingvalore della richiesta . [[opzioni]] è vero, quindi impostare l’ shippingOptionattributo della risposta al valore del shippingOptionattributo della richiesta . Altrimenti, impostarlo a null.
Se il requestPayerNamevalore della richiesta . [[opzioni]] è vero, quindi impostare l’ payerNameattributo della risposta al nome del pagatore fornito dall’utente, o null se non è stata fornita. Altrimenti, impostarlo a null.
Se il requestPayerEmailvalore della richiesta . [[opzioni]] è vero, quindi impostare l’ payerEmailattributo della risposta all’indirizzo e-mail del pagatore fornito dall’utente, o null se non è stata fornita. Altrimenti, impostarlo a null.
Se il requestPayerPhonevalore della richiesta . [[opzioni]] è vero, quindi impostare l’ payerPhoneattributo del risposta al numero di telefono del pagatore fornito dall’utente, o null se non è stata fornita. Quando si imposta il payerPhonevalore, l’agente utente DEVE formattare il numero di telefono di aderire a [ E.164 ]. Altrimenti, impostarlo a null.
Set risposta . [[completeCalled]] false.
Set richiesta . [[Stato]] a ” chiuso “.
Impostare l’ user agent ‘s richiesta di pagamento sta mostrando booleano false.
Risolvere la promessa in attesa di richiesta . [[acceptPromise]] con la risposta .

17.5 utente interrompe l’algoritmo di richiesta di pagamento

L’ utente interrompe l’algoritmo di richiesta di pagamento viene eseguito quando l’utente interrompe la richiesta di pagamento tramite l’interfaccia utente attualmente interattivo. Si deve accodare un compito sulla fonte compito interazione dell’utente per eseguire le seguenti operazioni:

Lasciate richiesta sia l’ PaymentRequestoggetto che l’utente interagisce con.
Se la richiesta di . [[aggiornamento]] è vero, quindi terminare questo algoritmo e non intraprendere ulteriori azioni. L’ agente utente interfaccia utente DOVREBBE garantire che ciò non si verifica mai.
Se richiesta . [[stato]] non è ” interattivo “, quindi terminare questo algoritmo e prendere alcuna ulteriore azione. L’ agente utente interfaccia utente DOVREBBE garantire che ciò non si verifica mai.
Set richiesta . [[Stato]] a ” chiuso “.
Impostare l’ user agent ‘s richiesta di pagamento sta mostrando booleano false.
Rifiuta la promessa richiesta . [[acceptPromise]] con una ” AbortError” DOMException.

18. Considerazioni di sicurezza

Questa sezione non è normativo.

18.1 La crittografia dei campi di dati

Questa sezione non è normativo.

L’ PaymentRequestAPI non supporta direttamente la crittografia dei campi di dati. I singoli metodi di pagamento possono scegliere di includere il supporto per i dati crittografati, ma non è obbligatorio che tutti i metodi di pagamento supportano questa.

18.2 Il pagamento Handler Corrispondenza

Per motivi di sicurezza, un agente utente può limitare corrispondente (in show()e canMakePayment()) per i gestori di pagamento dalla stessa origine come un URL metodo di identificatore di pagamento . I programmi utente possono inoltre utilizzare le informazioni fornite da un metodo di pagamento proprietario per abbinare i gestori di pagamento di altra origine.

19. Privacy Considerazioni

19.1 Esporre le informazioni dell’utente

L’ agente utente non deve condividere le informazioni sull’utente con uno sviluppatore (ad esempio, l’indirizzo di spedizione) senza l’autorizzazione dell’utente.

19.2 Esporre metodi di pagamento disponibili

Gli sviluppatori potrebbero tentare di chiamare la richiesta di pagamento API ripetutamente con unico metodo un pagamento identificativo per cercare di determinare quali sono i metodi di pagamento di un agente utente ha installato. Ci sono scenari legittimi per chiamare più volte (ad esempio, per controllare il flusso di pagamento selezione del metodo). Il fatto che un successo di abbinamento ad un metodo di pagamento provoca un’interfaccia utente da visualizzare mitiga il rischio divulgazione. Implementazioni MAGGIO richiedono un’azione utente per avviare una richiesta di pagamento oppure POSSONO votare limitare le chiamate alle API per evitare troppe chiamate ripetute.

20. dipendenze

Questa specifica si basa su diverse altre specifiche sottostanti. Identificatori Metodo di pagamento Il termine identificativo metodo di pagamento è definito da [ pagamento-metodo-id ]. Si tratta di un identificatore univoco per un metodo di pagamento . HTML Il seguente sono definiti da [ HTML ]: EventHandler, Coda compito , l’interazione dell’utente fonte compito , alto livello contesto navigazione , impostazioni correnti oggetto , permesso di utilizzare , innescato da attivazione utente , in parallelo , l’ iframeelemento, e allowpaymentrequestl’attributo. ECMAScript I termini promessa , slot interno , RangeError, TypeError, e JSON.stringifysono definiti da [ EcmaScript ].Il termine JSON-serializzare applicate ad un oggetto significa per eseguire l’algoritmo specificato dal valore originario della JSON.stringifyfunzione sull’oggetto fornito, passando l’oggetto fornito come unico argomento, e restituisce la stringa risultante. Questo può generare un’eccezione. Scrittura promessa-mediante specifiche I termini su realizzazione e al momento di rifiuto sono definiti da [ PROMESSE-GUIDE ]. DOM L’ Eventinterfaccia, il EventInitdizionario, e le condizioni di generare un evento , la bandiera spedizione , fermare la propagazione di bandiera , isTrustedattributo e arresto immediato bandiera propagazione sono definiti da [ DOM ]. IDL Web Quando questa specifica dice di gettare un errore, l’ agente utente deve generare un errore come descritto in [ WEBIDL ]. Quando ciò si verifica in un sub-algoritmo, questo si traduce in cessazione di esecuzione del sub-algoritmo e tutti gli algoritmi antenati fino a quando uno viene raggiunto che descrive in modo esplicito le procedure per la cattura di eccezioni.

L’algoritmo per la conversione di un valore ECMAScript a un dizionario è definito da [ WEBIDL ].

DOMExceptione le seguenti DOMExceptiontipologie di [ WEBIDL ] sono utilizzati: ” AbortError“, ” InvalidStateError“, ” NotAllowedError“, ” NotSupportedError” e ” SecurityError“.

21. conformità

Così come sezioni contrassegnate come non-normative, tutte authoring linee guida, diagrammi, esempi e note in questa specifica sono non normativa. Tutto il resto in questa specifica è normativo.

Le parole chiave POSSONO , DEVE , NON DEVE , CONSIGLIATO , DOVREBBE , e NON DOVREBBE devono essere interpretati come descritto in [ RFC2119 ].

C’è solo una categoria di prodotto che può pretendere la conformità a questa specifica: un user agent . Nota

Anche se questa specifica è principalmente rivolto ai browser web, è possibile che altri software potrebbe anche implementare questa specifica in modo conforme.

Agenti utente MAGGIO implementare algoritmi fornite in questa descrizione in qualsiasi modo desiderato, purché il risultato finale è indistinguibile dal risultato che si otterrebbe dagli algoritmi della specifica.

Agenti utente MAGGIO imporre limiti nell’implementazione specifica su ingressi altrimenti non vincolati, ad esempio, per impedire gli attacchi di servizio, per evitare corto di memoria, o per aggirare limitazioni specifiche della piattaforma. Quando un ingresso supera il limite attuazione specifiche, l’agente utente deve lanciare, o, nel contesto di una promessa, rigettare con una TypeErroropzionalmente informando l’autore di come un particolare ingresso supera un limite specifico dell’implementazione.

A. Indice IDL

[ Constructor ( sequenza di < PaymentMethodData> methodData , dettagli , opzionali opzioni )PaymentDetailsInit PaymentOptions , SecureContext , Esposto = Finestra ] Interfaccia PaymentRequest: EventTarget { Promessa < PaymentResponse> spettacolo (); Promessa <vuoto> abort (); Promessa < booleano > canMakePayment (); sola lettura attributo DOMString id ; attributo di sola lettura PaymentAddress? shippingAddress; in sola lettura attributo DOMString ? shippingOption; attributo di sola lettura PaymentShippingType? shippingType; attributo EventHandler onshippingaddresschange ; attributo EventHandler onshippingoptionchange ; }; dizionario PaymentMethodData{ richiesto DOMString supportedMethods ; oggetto data ; }; dizionario PaymentCurrencyAmount{ richiesto DOMString currency ; richiesto DOMString value ; // Nota: currencySystem è "a rischio" di essere rimosso! DOMString currencySystem = "urn: iso: std: ISO: 4217" ; }; dizionario PaymentDetailsBase{ sequenza di < PaymentItem> displayItems ; sequenza < PaymentShippingOption> shippingOptions ; sequenza < PaymentDetailsModifier> modifiers ; }; Dizionario PaymentDetailsInit: PaymentDetailsBase{ DOMString id ; richiesta ;PaymentItem total }; Dizionario PaymentDetailsUpdate: PaymentDetailsBase{ DOMString error ; ;PaymentItem total }; dizionario PaymentDetailsModifier{ richiesto DOMString supportedMethods ; ; sequenza < > ; oggetto ;PaymentItem total PaymentItem additionalDisplayItems data }; enum PaymentShippingType{ "spedizione" , "consegna" , "pick-up" }; dizionario PaymentOptions{ boolean requestPayerName = falso ; boolean requestPayerEmail = falso ; boolean requestPayerPhone = falso ; boolean requestShipping = falso ; = "Spedizione" ;PaymentShippingType shippingType }; dizionario PaymentItem{ richiesto DOMString label ; richiesta ; PaymentCurrencyAmount amount boolean pending = falso ; }; [ SecureContext , Esposto = Finestra ] Interfaccia PaymentAddress{ [ default ] oggetto toJSON (); sola lettura attributo DOMString country ; attributo readonly FrozenArray < DOMString > addressLine ; sola lettura attributo DOMString region ; sola lettura attributo DOMString city ; sola lettura attributo DOMString dependentLocality ; sola lettura attributo DOMString postalCode ; sola lettura attributo DOMString sortingCode ; sola lettura attributo DOMString languageCode ; sola lettura attributo DOMString organization ; sola lettura attributo DOMString recipient ; sola lettura attributo DOMString phone ; }; dizionario PaymentShippingOption{ richiesto DOMString id ; richiesto DOMString label ; richiesta ; PaymentCurrencyAmount amount boolean selected = falso ; }; enum PaymentComplete{ "fallire" , "successo" , "sconosciuto" }; [ SecureContext , Esposto = Finestra ] Interfaccia PaymentResponse{ [ default ] oggetto toJSON (); sola lettura attributo DOMString requestId ; sola lettura attributo DOMString methodName ; attributo readonly oggetto details ; attributo di sola lettura PaymentAddress? shippingAddress; in sola lettura attributo DOMString ? shippingOption; in sola lettura attributo DOMString ? payerName; in sola lettura attributo DOMString ? payerEmail; in sola lettura attributo DOMString ? payerPhone; Promessa <vuoto> completa ( opzionale risultato = "sconosciuto"PaymentComplete ); }; [ Constructor ( DOMString tipo , opzionale eventInitDictPaymentRequestUpdateEventInit ) , SecureContext , Esposto = Finestra ] Interfaccia PaymentRequestUpdateEvent: Event{ vuoto updateWith ( Promessa < PaymentDetailsUpdate> detailsPromise ); }; Dizionario PaymentRequestUpdateEventInit: EventInit{ };

B. Riconoscimenti

Questa specifica è stata derivata da un rapporto pubblicato in precedenza dalla piattaforma Incubator Group Web Community .

C. Riferimenti

C.1 Riferimenti normativi

[BCP47] Parole chiave per identificare le lingue . A. Phillips; M. Davis. IETF.Settembre 2009. IETF Best Current Practice. [DOM] DOM standard . Anne van Kesteren. WHATWG. Standard di vita. Il piano di numerazione delle telecomunicazioni pubblica internazionale . ITU-T. Novembre 2010. Raccomandazione. [ECMAScript] ECMAScript Specification Language . Ecma International. [HTML] HTML standard . Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Standard di vita. [INFRA] Infra standard . Anne van Kesteren; Domenic Denicola. WHATWG. Standard di vita. [ISO3166] ISO 3166: Codici per la rappresentazione dei nomi dei paesi e delle loro suddivisioni. .International Organization for Standardization (ISO). 2013. ISO 3166-1: 2013. [ISO4217] Codici di valuta – ISO 4217 . ISO.2015 standard internazionale. [PROMESSE-GUIDA] Scrittura promessa-mediante specifiche . Domenic Denicola. W3C. 16 febbraio 2016. Alla ricerca del TAG W3C. [RFC2119] Le parole chiave per l’uso in RFC per Indicare Livelli requisito . S. Bradner. IETF.Marzo 1997. migliori prassi attuale. [RFC4122] Un identificatore univoco universale (UUID) URN Namespace . P. Leach; M. Mealling; R. Salz. IETF.Luglio 2005. Proposto standard. [WEBIDL] Web IDL . Cameron McCormack; Boris Zbarsky; Tobie Langel. W3C. 15 dicembre 2016. Progetto del W3C Editor. [ECMA-402] ECMAScript Internazionalizzazione API Specification . Ecma International. Identificatori metodo di pagamento . Adrian Bateman; Zach Koch; Roy McElmurry; Marcos Caceres. W3C. 14 settembre 2017. W3C Candidate Recommendation.

C.2 riferimenti informativi

[Prendere] Fetch standard . Anne van Kesteren. WHATWG. Standard di vita. URL: https://fetch.spec.whatwg.org/ [Pagamento-metodo-base-card] Carta di pagamento di base . Adrian Bateman; Zach Koch; Roy McElmurry; Marcos Caceres. W3C. 27 luglio 2017. Progetto di lavoro del W3C. [Rfc6454] Il Web origine concetto . A. Barth. IETF.Dicembre 2011. Proposto standard.

HTML 5.2 Le specifiche API di richiesta di pagamento

Raccomandazione del Candidato W3C 21 settembre 2017

Astratto

Stato di questo documento

Funzionalità a rischio

1. Introduzione

1.1 Obiettivi

1.1.1 Fuori dallo scopo

2. Esempi di utilizzo

2.1 L’argomento methodData

2.2 L’argomento dei details

2.2.1 Opzioni di spedizione

2.2.2 Modifiche condizionali alla richiesta di pagamento

2.3 L’argomento delle options

2.4 Costruire un PaymentRequest

2.5 Gestione degli eventi e aggiornamento della richiesta di pagamento

2.6 POSTARE la risposta di pagamento su un server

3. Interfaccia PaymentRequest

3.1 Costruttore

3.2 attributo id

3.3 metodo show()

3.4 metodo abort()

3.5 metodo canMakePayment()

3.6 attributo shippingAddress

3.7 attributo shippingType

3.8 attributo onshippingaddresschange

3.9 attributo shippingOption

3.10 attributo onshippingoptionchange

3.11 slot interni

4. Dizionario PaymentMethodData

5. Dizionario PaymentCurrencyAmount

5.1 Controllori di validità

6. dettagli di pagamento dizionari

6.1 PaymentDetailsBase dizionario

6.2 PaymentDetailsInit dictionary

6.3 PaymentDetailsUpdate dictionary

7. PaymentDetailsModifier dizionario

8. PaymentShippingType enum

9. PaymentOptions dizionario

10. PaymentItem dizionario

11. PaymentAddress interfaccia

11.1 toJSON() metodo

11.2 country attributo

11.3 addressLine attributo

11.4 region attributo

11.5 city attributo

11.6 dependentLocality attributo

11.7 postalCode attributo

11.8 sortingCode attributo

11.9 languageCode attributo

11.10 organization attributo

11.11 recipient attributo

11.12 phone attributo

11.13 slot interni

12. PaymentShippingOption dizionario

13. PaymentComplete enum

14. PaymentResponse interfaccia

14.1 toJSON() metodo

14.2 methodName attributo

14.3 details attributo

14.4 shippingAddress attributo

14.5 shippingOption attributo

14.6 payerName attributo

14,7 payerEmail attributo

14.8 payerPhone attributo

14.9 requestId attributo

14.10 complete() metodo

14.11 Slot interni

15. PaymentRequest e iframeelementi

16. Eventi

16.1 Sommario

16.2 PaymentRequestUpdateEvent interfaccia

16.2.1 updateWith() metodo

16.2.2 Slot interni

16.2.3 PaymentRequestUpdateEventInit dizionario

17. Algoritmi

17.1 Indirizzo di spedizione cambiato algoritmo

17.2 opzione di spedizione cambiato algoritmo

17,3 algoritmo PaymentRequest aggiornato

17,4 Utente accetta l’algoritmo di richiesta di pagamento

2.1 L’argomento `methodData`

2.2 L’argomento dei `details`

2.3 L’argomento delle `options`

2.4 Costruire un `PaymentRequest`

3. Interfaccia `PaymentRequest`

3.2 attributo `id`

3.3 metodo `show()`

3.4 metodo `abort()`

3.5 metodo `canMakePayment()`

3.6 attributo `shippingAddress`

3.7 attributo `shippingType`

3.8 attributo `onshippingaddresschange`

3.9 attributo `shippingOption`

3.10 attributo `onshippingoptionchange`

4. Dizionario `PaymentMethodData`

5. Dizionario `PaymentCurrencyAmount`

6.1 `PaymentDetailsBase` dizionario

6.2 `PaymentDetailsInit` dictionary

6.3 `PaymentDetailsUpdate` dictionary

7. `PaymentDetailsModifier` dizionario

8. `PaymentShippingType` enum

9. `PaymentOptions` dizionario

10. `PaymentItem` dizionario

11. `PaymentAddress` interfaccia

11.1 `toJSON()` metodo

11.2 `country` attributo

11.3 `addressLine` attributo

11.4 `region` attributo

11.5 `city` attributo

11.6 `dependentLocality` attributo

11.7 `postalCode` attributo

11.8 `sortingCode` attributo

11.9 `languageCode` attributo

11.10 `organization` attributo

11.11 `recipient` attributo

11.12 `phone` attributo

12. `PaymentShippingOption` dizionario

13. `PaymentComplete` enum

14. `PaymentResponse` interfaccia

14.1 `toJSON()` metodo

14.2 `methodName` attributo

14.3 `details` attributo

14.4 `shippingAddress` attributo

14.5 `shippingOption` attributo

14.6 `payerName` attributo

14,7 `payerEmail` attributo

14.8 `payerPhone` attributo

14.9 `requestId` attributo

14.10 `complete()` metodo

15. `PaymentRequest` e `iframe`elementi

16.2 `PaymentRequestUpdateEvent` interfaccia

16.2.1 `updateWith()` metodo

16.2.3 `PaymentRequestUpdateEventInit` dizionario