Aankondiging van onze nieuwe Developer Hub
Aankondiging van onze nieuwe Developer Hub
Aankondiging van onze nieuwe Developer Hub
Aankondiging van onze nieuwe Developer Hub
/
Trends in de sector
7 juni 2023
Sep 14, 2026

Dynamic CVV: How It Works and What Merchants Should Know

Wit, rond logo met in het midden in elkaar grijpende vormen, omgeven door overlappende, baanachtige elliptische lijnen en verspreide blauwe ruitvormen.

Chargebacks?
Dat is niet langer jouw probleem.

Haal 4x meer chargebacks terug en voorkom tot 90% van de inkomende betalingen, dankzij AI en een wereldwijd netwerk van 20.000 handelaren.

Meer dan 600 beoordelingen
Geen creditcard nodig.

TL;DR:

  • Dynamic CVV changes or expires according to the issuer’s implementation.
  • Merchants use supported payment fields rather than generating issuer codes.
  • A passed check does not prove fulfillment or guarantee a dispute outcome.
  • Keep verification codes out of retained records and follow recurring-payment requirements.
De Elevenlabs Text-to-Speech AudioNative-speler wordt geladen...

Dynamic CVV is a card verification code that changes or expires under the card issuer’s implementation, rather than remaining a reusable printed value. It can limit reuse of a captured code, but it does not eliminate unauthorized payments or provide blanket protection against chargebacks.

For merchants, the key distinction is responsibility: the issuer and its technology partners provide and validate the card’s dynamic code. A typical online store does not generate new CVVs for customers or display issuer secrets through a checkout plugin. Your job is to handle the payment fields and verification results correctly.

Understand the Issuer-Side Workflow

Thales describes an example implementation in its Dynamic CVV2 documentation. The customer retrieves a code through the issuer application, and the implementation applies use and expiry conditions. Those details are specific to that system; do not assume every dynamic-code product uses the same timing or refresh rule.

The customer enters the current code where required in the supported payment flow. The merchant’s processor routes the payment information for authorization. A merchant should use its provider’s supported integration instead of building a separate system to invent or validate an issuer’s code.

ComponentTypical ResponsibilityMerchant Implication
Code GenerationIssuer and supporting card technology.Do not generate a substitute code in the storefront.
Customer AccessIssuer’s approved card or application experience.Direct customers to their issuer for access questions.
Payment CollectionMerchant’s supported processor integration.Handle the required field without exposing it in logs or support tools.
Verification ResultIssuer response passed through the payment workflow.Interpret the returned result alongside other relevant facts.
Dispute ResponseMerchant and processor case workflow.Use appropriate records; a passed check is not a universal defense.

Separate Dynamic CVV From Other Payment Controls

Dynamic CVV concerns the verification value supplied with a payment. Account login authentication establishes access to an account. EMV 3-D Secure supports payment authentication. Tokenization substitutes payment credentials within a supported system. These controls can work together, but they are not different names for the same feature.

EMVCo’s 3-D Secure overview explains its authentication role. Do not describe a dynamic CVV as automatically creating multi-factor authentication or a liability shift. Confirm the actual transaction results and applicable network rules with the processor.

Our fraud prevention and customer experience guide helps evaluate these controls without adding unnecessary steps to checkout.

Know What a Successful Check Can Establish

A successful verification result indicates that the submitted value met the relevant check. It does not independently establish delivery, product quality, cancellation history, or the absence of account compromise. Those are separate facts that may matter in a later dispute.

A code with limited validity can still be misused while valid or obtained through a compromised customer environment. Treat dynamic CVV as one control within a broader payment and account process, not a reason to ignore other evidence.

Use the clean fraud guide to understand why apparently consistent information can still require review. For account access concerns, the account takeover workflow addresses a different part of the customer journey.

Handle Failed Checks Without Creating More Problems

If a customer reports a code error, use the processor’s actual response to determine the approved next step. Do not repeatedly submit the same payment without checking its state. A timeout and an explicit verification failure are different events.

Tell the customer to use the current code from their issuer’s approved experience where appropriate. Support should not ask the customer to paste the code into chat or email, and should not promise that a new code will guarantee authorization.

For an illustrative case, a customer begins checkout, waits, and then submits a code that no longer meets the issuer’s validity conditions. A helpful flow explains the failed attempt, preserves the cart where supported, and allows an appropriate retry after the customer checks the issuer experience. It does not save the old code for later use.

Keep Verification Codes Out of Retained Records

The PCI Security Standards Council’s verification-code guidance prohibits retaining these codes after authorization, including for recurring or card-on-file use. A changing or expiring value is not a reason to store it in order notes, screenshots, or evidence packages.

Review application logs, analytics events, support forms, and recorded sessions so the checkout field is not accidentally captured. Keep appropriate processor references and check results instead of the secret value. Give support a clear escalation route if a customer submits sensitive data unexpectedly.

For recurring payments, follow the processor’s supported stored-credential workflow. Do not invent a requirement to obtain and retain a fresh CVV for every subsequent charge. The rules for an initial customer-present interaction and later billing may differ.

Evaluate the Merchant Experience and Later Disputes

  • Check whether the payment field and validation messages work on supported devices.
  • Track failed verification, technical failures, and successful retry separately.
  • Review repeated attempts without assuming every failure means fraud.
  • Monitor support contacts caused by unclear code instructions.
  • Preserve transaction references and appropriate results for later investigation.

If a dispute arrives, answer its actual allegation. A verification result may be relevant to an unauthorized-payment complaint, but it does not address non-receipt by itself. Use the evidence standardization guide and the case lifecycle to organize the response.

Connect the payment record with customer communication and fulfillment, then decide whether the evidence supports contesting. The merchant response template can help explain those facts without overstating the value of one check.

Veelgestelde vragen

Can a Merchant Generate Dynamic CVVs for Customer Cards?

A typical merchant does not generate the issuer’s card verification codes. Use the supported payment integration and direct cardholders to their issuer’s approved experience for code access.

Does Dynamic CVV Prevent Every Chargeback?

No. Dynamic CVV concerns payment verification. Chargebacks can involve delivery, cancellation, product issues, or unauthorized activity not resolved by that check alone.

Can Dynamic CVVs Be Saved for Recurring Payments?

Do not retain card verification codes after authorization. Use the processor’s supported recurring-payment and stored-credential workflow rather than saving a code for future charges.

Explore Chargeflow’s automated chargeback recovery to organize evidence and manage supported responses.

DEEL DIT ARTIKEL
Wit, rond logo met in het midden in elkaar grijpende vormen, omgeven door overlappende, baanachtige elliptische lijnen en verspreide blauwe ruitvormen.

Chargebacks?
Dat is niet langer jouw probleem.

Haal 4x meer chargebacks terug en voorkom tot 90% van de inkomende betalingen, dankzij AI en een wereldwijd netwerk van 20.000 handelaren.

Meer dan 600 beoordelingen
Geen creditcard nodig.
abonneren

De nieuwste artikelen over ' chargebacks', fraude en e-commerce, rechtstreeks in je inbox. Elke week.

Meld je nu aan en mis nooit meer de nieuwste trends!
Door je e-mailadres op te geven, ga je akkoord met onze Gebruiksvoorwaarden en onze privacyverklaring
Schema met gestreepte en gebogen lijnen die gesegmenteerde bogen vormen, gemarkeerd door drie blauwe ruitvormige markeringen aan de linkerkant.Een abstract ontwerp met een cirkelvormig raster en blauwe ruitvormige markeringen op een halfzwarte, halfwitte achtergrond.