Impostazioni di Checkout

Apra Checkout nella Tapaya Platform. La pagina mostra le Organization defaults (impostazioni predefinite dell'organizzazione) ed elenca i Checkout merchants (esercenti Checkout) della Sua organizzazione. Selezioni un esercente per aprire la pagina delle sue impostazioni. Configuri qui un esercente prima di integrare Hosted Checkout o Embedded Checkout.

Cosa richiede ciascuna integrazione

Esamini dall'alto verso il basso le impostazioni usate dalla Sua integrazione:

La modalità piattaforma usa la Secret key dell'organizzazione dalla pagina API Keys invece di una chiave checkout dell'esercente.

Onboarding di un esercente per Checkout

Completi l'onboarding dell'esercente selezionando i pagamenti online, oppure i pagamenti online e in presenza. L'onboarding online raccoglie il sito web del negozio e i dati dell'attività online. Un esercente che usa solo Checkout non ha bisogno di terminali.

Gli esercenti che richiedono i pagamenti online compaiono automaticamente in Checkout merchants, compresi quelli in attesa di approvazione. La creazione di un record dell'esercente o di una chiave checkout non concede l'approvazione per i pagamenti online. La sola approvazione per i pagamenti in presenza non abilita Checkout.

La tabella mostra lo stato di preparazione dell'esercente:

Copi il Merchant token per la modalità piattaforma, oppure selezioni Settings per configurare l'esercente. Solo gli amministratori dell'organizzazione possono modificare le impostazioni di Checkout.

Creare chiavi checkout dell'esercente

In Settings di un esercente, Merchant checkout keys elenca le chiavi per il backend di quell'esercente. Inserisca un nome per la chiave e selezioni Create merchant key. Le chiavi iniziano con tapaya_test_ in sandbox e con tapaya_live_ in produzione.

Copi subito il segreto. La Platform lo mostra una sola volta e ne salva solo un hash. Una chiave funziona solo per il proprio esercente. Revochi una chiave per bloccare le richieste che la usano; le altre chiavi dell'esercente e le chiavi della Sua organizzazione restano valide. Si veda Autenticazione di Checkout.

Configurare le destinazioni di ritorno

Hosted Checkout riporta il cliente al Suo negozio dopo il pagamento o quando il cliente abbandona la pagina. I pagamenti incorporati non usano URL di reindirizzamento.

Le destinazioni di ritorno appartengono alla credenziale che crea la sessione:

Le due configurazioni non vengono mai combinate e nessuna delle due fa da ripiego per l'altra. Una sessione in modalità piattaforma può tornare solo ai siti web consentiti dell'organizzazione, e una sessione creata con una chiave dell'esercente solo a quelli dell'esercente. Se una sessione omette successUrl o cancelUrl e la sua credenziale non ha un valore predefinito, la creazione viene rifiutata.

Nella sezione della Sua credenziale, aggiunga il Suo negozio a Allowed websites, poi imposti Default success URL e Default cancel URL. Un negozio potrebbe usare:

• Sito web consentito: https://shop.example.
• URL di successo: https://shop.example/checkout/return.
• URL di annullamento: https://shop.example/checkout/cancel.

Un sito web consentito è un'origine: schema, host e porta facoltativa, senza percorso, query o frammento. La corrispondenza usa l'origine esatta, porta compresa. I caratteri jolly e i suffissi del nome host non producono corrispondenze. Usi HTTPS per i negozi pubblicati online; HTTP è accettato per gli host locali.

Una sessione può sostituire i valori predefiniti con successUrl o cancelUrl quando la crea. Le sostituzioni devono comunque corrispondere a un sito web consentito della stessa credenziale. Una piattaforma che serve esercenti su percorsi o sottodomini diversi di solito passa entrambi gli URL in ogni sessione.

Lo stato Ready descrive l'approvazione dell'esercente e la configurazione del gateway. Non conferma la configurazione degli URL di ritorno. I pagamenti incorporati non hanno bisogno di URL di ritorno. Le sessioni ospitate hanno bisogno di valori predefiniti o di URL esplicitamente consentiti per la credenziale che usano.

Una visita a uno degli URL di ritorno non prova l'esito del pagamento. Recuperi la sessione dal Suo server prima di contrassegnare un ordine come pagato.

Impostare il nome visibile ai clienti

Customer-facing name viene mostrato al checkout e nei wallet di pagamento. Lo lasci vuoto per usare la ragione sociale dell'esercente. Non modifica il nome riportato nell'estratto conto bancario.

Wallet e aspetto

Ogni esercente seleziona Use organization wallets and appearance oppure imposta i propri valori. Questa opzione non influisce sulle destinazioni di ritorno, che seguono la credenziale come descritto sopra. Il nome dell'esercente e le chiavi checkout restano sempre specifici dell'esercente.

Le Organization defaults per wallet e aspetto si applicano a ogni esercente che le usa, e le modifiche raggiungono subito quegli esercenti:

• Apple Pay e Google Pay. Le carte sono sempre abilitate.
• Hide powered by Tapaya.
• Checkout color, un colore esadecimale a sei cifre come #1380A5.
• Checkout logo, un'immagine PNG o WebP fino a 5 MB. I caricamenti e le rimozioni del logo vengono salvati immediatamente.

Se non sono state salvate impostazioni predefinite, i wallet sono attivi e colore e logo provengono dal branding della Sua organizzazione.

Un pulsante del wallet dipende anche dal dispositivo e dal browser del cliente. Abilitare un wallet non garantisce che compaia ovunque. Google Pay live richiede un Google Pay merchant ID configurato.

Hosted Checkout usa tutte queste impostazioni. Embedded Checkout usa le impostazioni dei wallet e il colore di checkout effettivo come colore di evidenziazione del focus dei campi della carta (colorFocus). Le variabili che la Sua pagina passa in appearance.variables lo sostituiscono. Abiliti i pulsanti dei wallet incorporati nella Sua pagina come descritto in Embedded Checkout.

Usi Checkout preview per controllare il branding e i metodi di pagamento nei layout desktop e mobile.

Registrare i domini del negozio per Apple Pay

Per Apple Pay in Embedded Checkout, registri ogni nome host del negozio in cui compare il wallet. Hosted Checkout funziona sul dominio di Tapaya. Gli Allowed websites per i reindirizzamenti di Hosted Checkout non registrano un dominio per Apple Pay.

1. Apra Settings dell'esercente, poi Apple Pay e Shop domains.
2. Selezioni Add domain e scarichi il file di verifica.
3. Pubblichi il file senza modifiche e senza estensione all'indirizzo https://shop.example/.well-known/apple-developer-merchantid-domain-association. Usi un certificato HTTPS valido e serva il file direttamente, senza reindirizzamenti.
4. Inserisca il nome host, ad esempio shop.example, e selezioni Verify and add. Registri separatamente www.shop.example se i clienti usano anche quello.
5. Attenda che il dominio mostri Active, poi abiliti Apple Pay. Usi Check now per diagnosticare un dominio che non funziona.

Mantenga il file di verifica disponibile anche dopo la registrazione. Ogni esercente ha bisogno della propria registrazione del dominio, anche quando wallet e aspetto provengono dalle impostazioni predefinite dell'organizzazione. Un esercente deve avere un gateway di pagamento configurato prima che un dominio possa essere registrato.

Manca qualcosa in questa pagina?Richieda una funzionalità. Alleghiamo questa pagina, così il team vede il contesto.