Con la tokenizzazione, è possibile archiviare in remoto i dati delle carte di pagamento sui server di Axerve e ricevere in sostituzione un Token che può essere archiviato sui server del merchant ed utilizzato per inviare pagamenti futuri, al posto dei dati di carta.
Durante una transazione, grazie al campo requestToken, è possibile ottenere in risposta il Token da utilizzare per le transazioni successive.
Il metodo di servizio web WSs2s corretto per questo scopo è il callRequestTokens2S.
È bene ricordare che un token o un set di token possono essere utilizzati da più merchant, purché appartenenti allo stesso gruppo. I gruppi di merchant possono essere creati solo da Banca Sella, alla quale è necessario fare la richiesta.
Le opzioni disponibili sono:
Aggiungere ad un gruppo un merchant e i token da esso generati
Aggiungere un merchant ad un gruppo senza i token da esso generati.
Rimuovere un merchant e tutti i token da esso generati da un gruppo
Rimuovere un merchant ma non tutti i token da esso generati da un gruppo
Queste sono le informazioni obbligatorie da inviare al gateway:
shopLogin (codice del merchant)
requestToken (MASKEDPAN per un Token standard, qualsiasi altro valore per un Token personalizzato)
cardNumber (numero della carta di credito)
expiryMonth (mese di scadenza della carta)
expiryYear (anno di scadenza della carta)
cvv (Strnga che contiene il Card Verification Value stampato sulla carta, come specificato su Gestire il campo CVV) VERIFICARE link corretto da inserire
withAuth flag che indica se l’operazione deve includere la richiesta autorizzativa della transazione.
Il metodo callRequestTokens2S invia ad Axerve tutti i dati assegnati in precedenza, se il flag withAuth viene impostato su Y viene effettuata anche la richiesta autorizzativa (che se non movimentata non prevede addebito sulla carta) e restituisce il risultato dell’operazione; altrimenti vengono restituiti esclusivamente i dati della carta.
Dopo che la richiesta callRequestTokens2S è stata effettuata, è possibile conoscere il risultato dell’operazione usando i valori nell’XML di risposta:
Innanzitutto è possibile usare il metodo TransactionResult che restituisce la stringa OK se è stato effettuato il controllo, o la stringa KO in caso contrario. Nei campi TransactionErrorCode e TransactionErrorDescription ci sono le informazioni dettagliate in caso di errore.
Il campo AuthorizationResult che restituisce la stringa OK se la transazione viene autorizzata o la stringa KO in caso contrario.
Se AuthorizationResult restituisce la stringa KO, è possibile conoscere le cause del diniego usando il metodo AuthorizationErrorCode:
Se AuthorizationErrorCode restituisce un valore <> 0, la transazione è stata negata a causa di problemi tecnici; il valore restituito può variare a seconda della specifica ragione. Il metodo AuthorizationErrorDescription restituisce una descrizione della ragione del diniego (nella lingua settata nel backoffice).
Se AuthorizationErrorCode restituisce il valore 0, la transazione non è fallita a causa di problemi tecnici. La descrizione dell’errore viene mostrata nel set della lingua del back office usando il metodo AuthorizationErrorDescription.
Se AuthorizationResult restituisce il valore OK , la transazione è stata autorizzata
Verifica la descrizione di altri campi nella sezione sezione API.