Skip to main content
On this page

Tokenization by payment processors replaces sensitive payment card data with unique tokens generated by the processor.

The main characteristics of tokenization are:

  • Transparency: Processor tokenization integrates transparently into the transaction flow.
  • Flexibility: Use multiple processors for tokenization and make purchases without CVV.
  • CVV update: Update the CVV for cards already stored in the DEUNA card vault when required by the processor.

Tokenization by processor#

The processor uses the tokens to perform transactions securely, without the need to handle confidential card information in the transactional process.

To tokenize your customers' cards:

  • Request PSP tokenization functionality from the merchant to DEUNA.
  • Implement processor methods that support card tokenization.
  • In some cases, you must have a prior agreement with the processor for tokenization.

Card verification metadata#

Tokenization and verification are related but separate. A stored card receives verification metadata only after DEUNA confirms it through a zero-amount authorization or through a payment transaction that reaches an accepted processing state. Until then, card retrieval responses omit the optional verification metadata.

See List and retrieve stored cards for the published card-retrieval operations. Verification metadata is documented in the section below.

CVV verification by connection#

Some processors require that the user's tokenized cards re-enter the CVV.

CVV verification can be turned on or off independently for each payment-processor connection. The connection's exclude_cvv setting participates in the decision, but it does not determine the checkout behavior by itself.

An eligible payment can proceed without CVV only when the connection allows CVV exclusion and at least one applicable token is available for the selected payment instrument:

  • a network token has been issued for the payment instrument; or
  • a PSP token is available for the payment instrument and that PSP is a candidate for the transaction.

The payment route can explicitly require CVV. A route-level requirement takes precedence, so DEUNA requests CVV even when an eligible connection has exclude_cvv: true.

If a payment-processor response contains exclude_cvv: true, the connection supports processing an eligible flow without asking the customer for the CVV. This is a connection capability, not a request setting that disables CVV globally and not a guarantee that every route will omit it.

ScenarioCheckout behavior
The route requires CVVRequest CVV, including when exclude_cvv is true.
exclude_cvv is true and the payment instrument has a network tokenCVV can be omitted when the route does not require it.
exclude_cvv is true and the payment instrument has a PSP token for a candidate PSPCVV can be omitted when the route does not require it.
No applicable network token or candidate-PSP token is availableRequest CVV.
The card is being used for the first time or has not been savedRequest CVV unless an applicable token condition above is satisfied and the route allows CVV exclusion.

Example

JavaScript
{
  "enabled": true,
  "method_type": "credit_card",
  "processor_name": "kuski",
  "exclude_cvv": true, 
}