Card tokenization and CVV verification

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 response contract, verification sources, and example payload.

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. When verification is on, payments routed through that connection collect and validate the CVV according to the active card flow. When verification is off, eligible payments routed through that connection can proceed without a CVV.

In a payment strategy with multiple eligible connections, each connection keeps its own CVV requirement. Routing rules or another connection can therefore still require CVV even when one connection is configured not to.

If a payment-processor response contains exclude_cvv: true, the selected connection does not require the customer to enter the CVV for that eligible flow. This response reflects the connection-level behavior; it is not a request setting that disables CVV globally.

For payment methods that already have a tokenized card in the DEUNA network, the CVV should always be requested when processing a transaction for cards used for the first time by a user or that have not been saved.

Example

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