Card Data Rules: What You Must Never Ask For, Show, or Reuse

Card data has three short rules that almost nobody quotes, and all three are one sentence long. You must not ask a cardholder for their PIN. You must not show them their full card number online. And you must not carry authentication data from one transaction into another.

Each is easy to break by accident, and each is easy to fix.

Never ask for a PIN#

Section 1.5.5.4 of the Visa Core Rules (ID# 0008977) is a single line:

A Merchant must not ask a Cardholder to reveal the Cardholder's PIN.

No exceptions, no regional carve-outs. Not over the phone, not on a form, not "just read it out so I can key it in", and not to a staff member leaning over a terminal to help.

The practical version for your counter is simpler than the rule. The PIN is entered by the customer, into the pad, and nobody else ever needs to know it. If a terminal is awkward to reach, turn it toward them rather than offering to type for them.

This matters beyond compliance. A merchant who asks for a PIN has created a dispute they cannot win and a staff member they cannot defend.

Never display the full card number back to the customer#

Section 5.8.4.2 (ID# 0003627) covers online:

An Electronic Commerce Merchant, Agentic Payment Enabler, or Agentic Payment Provider must not display the full Payment Credential to the Cardholder online.

Not even back to the person who owns the card. The usual failure is well-meaning: an order confirmation page, a saved-cards screen, or an account page that echoes what was typed so the customer can check it. Truncate it instead. Last four digits is the convention for a reason.

Note who else this rule now names. It was last updated in October 2025 to add Agentic Payment Enablers and Providers, which is the same expansion we covered in agentic payments and the Visa rules. If software is transacting on a cardholder's behalf, it inherits this prohibition.

Receipts have their own truncation requirements, which are set out in what a transaction receipt has to show.

Never reuse authentication data across transactions#

Section 10.15.3.1 (ID# 0004636) applies in the US Region:

In an Authorization Request, an Electronic Commerce Merchant must not transmit Authentication Data specific to one Transaction with another Transaction

There are two exceptions, and both are narrow:

• Two transactions are related due to a partial advance payment
• All items of an order cannot be shipped at the same time

In plain terms, the authentication result you got for one purchase belongs to that purchase. You cannot hold a successful 3-D Secure result and attach it to a later order because it would improve your liability position. The split shipment case is carved out precisely because it is one order arriving in pieces, not two orders.

This is a stored-credentials trap more than a deliberate one. A system that caches authentication values alongside a saved card will do this on its own unless somebody tells it not to.

What to actually check#

Three questions, one per rule.

Does any script, form or phone process your team uses invite a customer to say their PIN out loud? Does any page in your checkout, account area or order confirmation render more than the last four digits? And does your stored-credential flow reuse an authentication value from an earlier order on a new one?

If you handle card verification values as well, the related requirements are in what the CVV2 rules actually require.