XPay Build
XPay Build è un approccio che permette all'esercente di ospitare il form di pagamento all'interno del proprio ecommerce, evitando allo stesso tempo di dover gestire i dati carta: i campi dove vengono inserite queste informazioni sono contentuti in degli iframe collegati al server XPay, garantendo la sicurezza dei dati carta e al contempo rendendo migliore l'esperienza di acquisto.
Con XPay Build, sono disponibili componenti dell'interfaccia utente HTML già pronti, come campi di input per la raccolta di informazioni dall'utente e bottoni per i metodi di pagamento alternativi abilitati sul terminale dell'esercente, come ApplePay, Paypal, ecc.
Creazione form di pagamento
Il form raccolta dati carta così come i bottoni dei metodi di pagamento alternativi (APM) vengono restituiti dall'API:
La chiamata restituisce un oggetto, contenente gli iframe corrispondenti al metodo di pagamento tramite carta e agli APM attivi sul terminale dell'esercente. Di seguito un'esempio in formato JSON:
Ogni iframe rappresenta un bottone che permette al cliente di scegliere il metodo di pagamento desiderato, questi componenti devono essere quindi mostrati nella pagina di checkout del negozio.
La gestione del pagamento subisce delle variazione tra carte e APM, di seguito le indicazioni.
Pagamento tramite carta
Una volta cliccato sul metodo di pagamento tramite carta, viene restituito, tramite un evento, un oggetto contenente i seguenti dati:
- "event": parametro valorizzato con "BUILD_FLOW_STATE_CHANGE".
- "state": parametro valorizzato con "CARD_DATA_COLLECTION".
- "fieldSet": oggetto contenente gli iframe dei singoli campi necessari per l'inserimento dei dati carta, di seguito il dettaglio.
OGGETTO FIELDSET
NOME | DESCRIZIONE | FORMATO | |||||||||||||||||||||||||||||||||||||
|
Di seguito un esempio dell'oggetto in formato JSON dell'oggetto "fieldSet":
I singoli iframe dovranno essere mostrati al cliente: compilati i campi, viene restituito un evento con un oggetto così composto:
- "event": valorizzato con "BUILD_FLOW_STATE_CHANGE".
- "state": valorizzato con "READY_FOR_PAYMENT"
L'evento conferma la possibilità di procedere con il pagamento richiamando l'API:
La risposta all'API sopra riportata varia in base alle casistiche di seguito riportate:
- Autenticazione 3D Secure: il pagamento richiede l'autenticazione 3D Secure da parte del titolare carta. Vengono restituiti i parametri:
- "url": è necessario reindirizzare il cliente verso l'indirizzo contenuto nel campo, dove il titolare carta ha la possibilità di eseguire l'autenticazione ed autorizzare il pagamento. Al termine dell'autenticazione l'esito del pagamento viene restituito verso i parametri di avvio "resultUrl", "notificationUrl" ed eventualmente "cancelUrl".
- "state": valorizzato con REDIRECTED_TO_EXTERNAL_DOMAIN".
- Esito pagamento: la transazione non richiede autenticazione 3D Secure da parte del titolare carta, il pagamento viene quindi eseguito. Vengono restituiti i parametri:
- "operation": oggetto contenente il dettaglio dell'operazione.
- "state": valorizzato con "PAYMENT_COMPLETE".
Gestione degli errori
Il form di raccolta dati carta può restituire, tramite evento, degli errori come dati non corretti inseriti negli iframe o scadenze della sessione. Di seguito il dettaglio dell'oggetto:
NOME | DESCRIZIONE | FORMATO | ||||||||||||||||||||||
|
Pagamento tramite APM
Una volta cliccato sul metodo di pagamento alternativo, viene restituito, tramite un evento, un oggetto contenente i seguenti dati:
- "state": valorizzato con "REDIRECTED_TO_EXTERNAL_DOMAIN".
- "url": indirizzo necessario per il reindirizzamento verso la pagina di cassa del metodo di pagamento alternativo. Al termine del pagamento l'esito viene restituito verso i parametri di avvio "resultUrl", "notificationUrl" ed eventualmente "cancelUrl".