Nessun risultato trovato

Pagamenti OneClick

L'integrazione di questa soluzione consente al cliente finale di salvare i dati della propria carta, ed utilizzarli successivamente per effettuare gli acquisti più velocemente.

I pagamenti OneClick sono identificati anche con il termine "CIT" (Customer Initiated Transaction).

La gestione di questa soluzione si divide in 2 fasi:

  • Primo pagamento
  • Pagamenti successivi

Entrambe le fasi sono soggette ad autenticazione 3D Secure.

Di seguito viene presentato come effettuare primi pagamenti di tokenizzazione e pagamenti successivi nelle modalità di integrazione:

  • Hosted Payment Page
  • Pay-by-Link

Primo pagamento

Va generata una prima transazione, assegnando un contratto univoco per cliente, un identificativo che consente a XPay di salvare l'abbinamento tra il cliente e la carta di pagamento utilizzata.

Hosted Payment Page

Il flusso di pagamento non varia rispetto alla soluzione Hosted Payment Page, è necessario infatti richiamare la medesima API:

Valorizzando l'oggetto "recurrence" con i parametri:

action CONTRACT_CREATION
contractId Stringa univoca
contractType CIT

Pay-by-Link

Il flusso di pagamento non varia rispetto alla soluzione Pay-by-Link, è necessario infatti richiamare la medesima API:

Valorizzando l'oggetto "recurrence" con i parametri:

action CONTRACT_CREATION
contractId Stringa univoca
contractType CIT

XPay Build

Il flusso di pagamento non varia rispetto alla soluzione XPay Build, è necessario infatti richiamare la medesima API:

Valorizzando l'oggetto "recurrence" con i parametri:

action CONTRACT_CREATION
contractId Stringa univoca
contractType CIT

Gestione dei pagamenti successivi

Nel pagamento successivo è necessario inviare a XPay di pagamento una chiamata con il contratto registrato in fase di primo pagamento. Questo permetterà al cliente di non dover inserire i dati carta su pagina di cassa, ma di procedere con l'autenticazione 3D Secure.

Hosted Payment Page

Per procedere al pagamento successivo richiamare l'API:

Valorizzando l'oggetto "recurrence" con i parametri:

action SUBSEQUENT_PAYMENT
contractId Stringa univoca utilizzata in fase di primo pagamento
contractType CIT

Pay-by-Link

Per procedere al pagamento successivo richiamare l'API:

Valorizzando l'oggetto "recurrence" con i parametri:

action SUBSEQUENT_PAYMENT
contractId Stringa univoca utilizzata in fase di primo pagamento
contractType CIT

XPay Build

Per procedere al pagamento successivo richiamare l'API:

Valorizzando l'oggetto "recurrence" con i parametri:

action SUBSEQUENT_PAYMENT
contractId Stringa univoca utilizzata in fase di primo pagamento
contractType CIT

In risposta alla chiamata dell'API sopra riportata, viene restituito il seguente oggetto con il campo "state" valorizzato con "GDI_VERIFICATION":

È necessario creare un nuovo layout di pagina HTML, con un singolo frame interno, per consentire al server 3D Secure di raccogliere dati sensibili del browser necessari per valutare il rischio della transazione. Il contenuto dell'iframe dovrà essere l'url indicato nel parametro "src":

Al termine della fase GDI, si potrà entrare in una delle seguenti due casistiche:

  • Autenticazione 3D Secure: il pagamento richiede l'autenticazione forte (SCA - Strong Customer Authentication) da parte del titolare carta. Verrà restituito l'evento onBuildFlowStateChange contenente l'indirizzo di autenticazione 3D Secure, verso il quale il cliente dovrà essere reindirizzato:
    • evtData.data.state: valorizzato con "REDIRECTED_TO_EXTERNAL_DOMAIN".
    • evtData.data.url: indirizzo di autenticazione 3D Secure, verso il quale il cliente dovrà essere reindirizzato.

    Il reindirizzamento verso la pagina esterna consentirà al cliente di completare l'eventuale autenticazione richiesta dalla banca e, al contempo, permetterà al gateway XPay di concludere il pagamento.

    Per la gestione dell'esito, verranno utilizzati gli URL configurati nei parametri inviati nella chiamata iniziale API POST /orders/build:

    • resultUrl
    • notificationUrl
    • cancelUrl
  • 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. Per i dettagli sul contenuto dell'oggetto, fare riferimento allo schema della risposta (Response) dell'API GET /operations/{operationId}.
    • "state": valorizzato con "PAYMENT_COMPLETE". Attenzione: lo stato indica solamente che il processo di pagamento è terminato, non che la transazione sia andata a buon fine. Per risalire al reale esito del pagamento, verificare il parametro "operationResult" presente nell'oggetto "operation" sopra indicato.

NOTE:

  • Vengono messe a disposizione le seguenti API per poter intervenire sui contratti esistenti:

  • Il gateway non consente l’esecuzione del pagamento quando il parametro “actionType” è valorizzato a “PAY” e l’importo è pari a zero. Per effettuare una verifica carta con importo pari a zero (“amount”: “0”) e contestuale tokenizzazione, è necessario impostare il parametro “actionType” con “VERIFY”.
  • All'interno dell'oggetto "recurrence", il valore "action":"CARD_SUBSTITUTION" consente di sostituire la carta associata a un contratto (contractId) esistente. Il flusso di pagamento con la sostituzione carta è identico a quello della tokenizzazione iniziale.
    Nota importante: questa funzionalità è disponibile esclusivamente per le carte di pagamento. Per i metodi di pagamento alternativi (APM), non è possibile effettuare la sostituzione: sarà pertanto necessario procedere con una nuova tokenizzazione generando un differente "contractId".