Integration Types
Altre funzionalità
Card Payments
Mobile Wallets
Alternative Payment Methods
Resources
La Tokenization del gateway consente di archiviare i dettagli di pagamento in cambio di un token. Il token sostituisce i dettagli di pagamento nella richiesta di transazione inviata al gateway. Questa funzionalità risulta utile in quanto il gateway gestisce i dettagli di pagamento raccolti dal pagante con una conseguente riduzione degli obblighi di conformità PCI. Inoltre, se il token viene archiviato con i dati del pagante, può essere utilizzato quando il pagante torna per eseguire un altro acquisto.
Un token è un identificativo dei dettagli di pagamento archiviati che viene restituito quando si esegue la tokenizzazione dei dettagli. Può essere utilizzato per tutte le transazioni di pagamento successive per fare riferimento ai dettagli di pagamento precedentemente salvati.
I token sono in formato PAN e supereranno semplici regole di validazione della carta di credito, in modo che possano essere archiviati al posto dei numeri della carta di credito. Tuttavia la loro generazione è stata concepita per ridurre al minimo le probabilità che siano numeri di carta validi.
Il provider di servizi di pagamento può configurare il servizio di Tokenization associato al proprio profilo dell'esercente per i seguenti parametri:
Definisce il modo in cui i dettagli di pagamento vengono verificati prima di essere archiviati. I valori possono essere:
Di base | Verifica che i dettagli di pagamento forniti siano conformi alle regole del gateway per l'elaborazione di un pagamento con questi dettagli di pagamento. |
Acquirer |
Verifica i dettagli di pagamento eseguendo una richiesta DirectAPI Verify per verificare i dettagli di pagamento forniti con l'acquirer.
Quando si archivia un token, è necessario specificare una valuta. Il valore di default per l'origine della transazione è il valore configurato per il collegamento esercente-acquirer. L'impostazione
Enforce CSC per questa origine della transazione verrà ignorato. |
Nessuna | Non viene eseguita alcuna verifica. |
Definisce le modalità di gestione dei token all'interno dell'archivio. I valori possono essere:
Token univoco | Assegna un token univoco ogni volta che si salva un identificativo di conto. Questa relazione tra un identificativo di conto e i token può essere definita come rapporto di tipo uno-a-molti. |
Identificativo conto univoco | Un identificativo di conto può essere associato a un solo token. Se si prova ad associarlo a un altro token, viene generato un errore. Questa relazione tra l'identificativo di conto e il token può essere definita come rapporto di tipo uno-a-uno. |
Definisce la strategia utilizzata per generare un token in questo archivio. I valori possono essere:
Casuale con Luhn | l'ID del token generato è un numero casuale. Inizia con un "9", supera un controllo Luhn (mod 10) e esclude i numeri noti della carta. | ||||||||||||||||||||
Conserva 6.4 | Prova a conservare le prime 6 e le ultime 4 cifre e non è un numero di carta valido. Proprietà del token:
Non è possibile aggiornare il numero della carta per un token del tipo Conserva 6.4 ma è possibile aggiornare la data di scadenza.
|
||||||||||||||||||||
Fornito dall'esercente | Il token è fornito dall'esercente. Qualsiasi token fornito dall'esercente viene convalidato in modo da non essere un numero di carta valido. | ||||||||||||||||||||
Tokenizzazione dell'acquirer | l'ID token viene fornito dal servizio di tokenizzazione dell'acquirer. Questo servizio consente solo di memorizzare l'FPAN in un token. Per consentire la tokenizzazione dell'acquirer devono essere soddisfatti i seguenti prerequisiti:
|
È possibile eseguire le operazioni indicate di seguito utilizzando la soluzione Tokenization del gateway:
Questa operazione consente di creare o aggiornare un token associando al token i dettagli di pagamento. Il token verrà archiviato nell'archivio dei token con la configurazione presente nel profilo dell'esercente.
I dettagli di pagamento saranno verificati utilizzando il metodo di verifica indicato nel campo verificationStrategy
. Se l'esercente non specifica questo campo, verrà utilizzata la strategia predefinita configurata sul proprio profilo dell'esercente.
Se la verifica ha esito positivo, i dettagli di pagamento vengono associati a un token per riferimento futuro e utilizzati in transazioni di pagamento successive. È inoltre possibile scegliere di riprovare un'operazione Tokenize se il primo tentativo non restituisce una risposta.
Il token viene emesso in base al metodo di gestione dei token configurato per l'archivio di token utilizzato dal profilo dell'esercente.
È possibile aggiornare i dettagli, ad esempio la data di scadenza di una carta, in un token archiviato utilizzando l'operazione Tokenize lasciando tuttavia invariati gli altri dettagli. Il token fornito nell'URL della richiesta identifica il token che si desidera aggiornare. Se si fornisce lo stesso token come origine dei dettagli di pagamento, verranno riutilizzati i dettagli archiviati in precedenza e pertanto non sarà necessario acquisire nuovamente i dettagli di pagamento. Specificando la nuova data di scadenza nella sezione Dettagli della carta della richiesta, il valore sostituirà la data di scadenza già archiviata nel token (vedere Regole di precedenza).
La richiesta di esempio che segue mostra come fornire sia i dettagli della carta sia le origini del token nella richiesta Tokenize:
Metodo HTTP | PUT |
URL | https://eu-gateway.mastercard.com/api/rest/version/72/merchant/<merchant>/token/9999999999999999 |
JSON |
{ "sourceOfFunds": { "provided": { "card": { "expiry": { "month": "01", "year": "39" }, "number": "5123456789012346" } }, "type": "CARD" } } |
Il metodo JSON sopra riportato si basa sul presupposto che in precedenza è stato archiviato un token con ID "9999999999999999" che contiene un numero e una data di scadenza della carta.
Il risultato di questa operazione è che il token "9999999999999999" ora ha come data di scadenza il 21/05 e il numero della carta rimane invariato.
Esegue un'operazione Authorize per l'importo specificato utilizzando i dettagli di pagamento identificati dal token fornito.
Esegue un'operazione Pay per l'importo specificato utilizzando i dettagli di pagamento identificati dal token fornito.
Consente di recuperare i dettagli di pagamento associati al token specificato. Gli identificativi del conto e altri dati sensibili vengono restituiti oscurati.
Consente di trovare i record dei token che corrispondono a una query. La query attualmente supporta la ricerca mediante un identificativo di token o un identificativo di conto. Crittografare il numero della carta utilizzando la libreria JWE.js.
Se la query corrisponde a un numero elevato di record di token, è possibile limitare i risultati della ricerca per pagina e recuperare la serie di risultati successiva utilizzando richieste successive.
Il Token Maintenance Service fornito dal gateway garantisce, laddove possibile, che i dettagli di pagamento associati a un token e utilizzati per i pagamenti periodici siano aggiornati e che l'elaborazione delle transazioni dei pagamenti periodici che utilizza questo token abbia buone probabilità di riuscita.
È possibile utilizzare il Token Maintenance Service se sono soddisfatte tutte le condizioni indicate di seguito.
Per utilizzare il Token Maintenance Service, è necessario:
Per le transazioni periodiche in cui viene fornito un token e la transazione viene elaborata correttamente dal gateway mediante un acquirer abilitato per la funzionalità Programma di aggiornamento del conto, il gateway stabilirà la data successiva in cui il token verrà utilizzato per un pagamento periodico (in base all'uso precedente del token nei pagamenti periodici).
Il gateway invierà una richiesta per i dettagli di pagamento associati al token al servizio Programma di aggiornamento del conto in tempo per ricevere ed elaborare una risposta. Quindi aggiornerà il token a seconda della risposta.
Gli aggiornamenti dei token includono:
Un token è contrassegnato come non valido se una risposta di Programma di aggiornamento del conto indica che i dettagli di pagamento associati al token non sono validi.
Le richieste di transazione che utilizzano un token non valido vengono rifiutate dal gateway.
Per un token non valido, la risposta dell'operazione DirectAPI RETRIEVE_CARD restituisce status=INVALID
.
Utilizzare l'operazione Retrieve Token per recuperare i dettagli di pagamento per un token che è stato aggiornato dal Programma di aggiornamento del conto.
usage.lastUpdated
riporta data e ora in cui il token è stato aggiornato da Programma di aggiornamento del conto.usage.lastUpdateBy
è vuoto, a indicare che il token non è stato aggiornato da un esercente bensì da Programma di aggiornamento del conto.Utilizzando l'operazione DirectAPI SEARCH_TOKEN, è possibile cercare tutti i token che sono stati aggiornati a partire da una data e un'ora specifiche. La risposta riporta tutti i token (inclusi i dettagli di pagamento associati al token, nonché le informazioni sull'utilizzo per il token) con data e ora usage.lastUpdated
successive a quelle fornite nella richiesta.
A questo punto è possibile utilizzare i processi esistenti, ad esempio:
Se si è abilitati per il programma di aggiornamento del conto sui propri collegamenti all'acquirer, è possibile richiedere manualmente le informazioni di aggiornamento del conto sui dettagli della carta memorizzati in un token. A tale scopo, fornire quanto segue nella richiesta Tokenize:
verificationStrategy=ACCOUNT_UPDATER
transaction.currency
Tenere presente che è facoltativo fornire il gruppo di parametri sourceOfFunds
.
Il gateway riceverà ed elaborerà una risposta dal servizio Programma di aggiornamento del conto simile a quando si utilizza Token Maintenance Service. Per informazioni su cosa includono gli aggiornamenti dei token, sui token non validi e sul recupero delle informazioni sull'aggiornamento dei token, vedere le sezioni in Token Maintenance Service.
Quando il gateway riceve una risposta del Programma di aggiornamento del conto da un acquirer, che indica che il numero della carta è cambiato, il gateway non può aggiornare i dettagli della carta a causa della generazione di token o della strategia di manutenzione. Il gateway crea invece un nuovo token con il nuovo FPAN (Funding Primary Account Number) e quindi collega il nuovo token al vecchio token utilizzando il campo replacementToken.
Questa sezione spiega diversi scenari in cui l'esercente deve utilizzare il token sostitutivo ed eliminare il vecchio token.
Questa tabella descrive alcuni scenari in cui viene generato un token sostitutivo.
Caso 1 |
|
Caso 2 |
|
PayPal consente di impostare un accordo di fatturazione per un pagante che permette di effettuare successivamente un addebito al pagante senza il consenso del pagante facendo riferimento all'accordo di fatturazione. Il pagante deve dare il consenso all'accordo di fatturazione solo una volta, quando viene siglato. Al momento della definizione dell'accordo di fatturazione un pagamento può essere effettuato o meno.
È possibile tokenizzare l'ID dell'accordo di fatturazione PayPal utilizzando l'operazione Tokenize. Fornire l'ID del token, generato dal gateway o quello fornito personalmente, nell'URL della richiesta Tokenize.
URL | https://eu-gateway.mastercard.com/api/rest/version/72/merchant/<your_gateway_merchant_ID>/token/<token_ID> |
Metodo HTTP | PUT |
{ "sourceOfFunds": { "provided": { "paypal": { "billingAgreement": { "description": "Test Billing Agreement", "name": "Test Name", "cardinality": "MULTIPLE", "id": "1234" } } }, "type": "PAYPAL", "token": "9926675679589987" }, "shipping": { "address": { "city": "city", "country": "country", "postcodeZip": "post_code", "stateProvince": "state", "street": "test street", "street2": "test street2" } } }
È possibile testare la propria integrazione per la tokenizzazione del gateway utilizzando il proprio profilo dell'esercente di prova (il proprio ID esercente con prefisso TEST) in Produzione.
Quando l'esercente è abilitato e configurato per la tokenizzazione dal proprio provider di servizi di pagamento il gateway crea due archivi, di prova e produzione. L'archivio di prova è l'ID dell'archivio di token con prefisso TEST.
Quando si inviano richieste di tokenizzazione al gateway utilizzando il proprio profilo dell'esercente di prova, viene utilizzato l'archivio di token di prova. Per elaborare successivamente un pagamento con un token, è necessario tokenizzare un numero della carta di prova supportato. Per i dettagli relativi alle carte di prova, vedere Test e Go Live.