Skip to main content

Discover UA02 - Fraud: Card Not Present

This is the Discover code for a customer denying an online or phone order: UA02. Looking for Visa 10.4, Mastercard 4837 or Amex F29?

Read the code off your notice: a dot means Visa, four digits and no dot is Mastercard, one letter and two digits is Amex. Get that right first, because the response deadline runs from 20 days on Amex to 45 on Mastercard.

TL;DR
  • UA02 is Discover's main fraud code for e-commerce and card-not-present orders. The cardholder says they didn't authorize the charge.
  • ProtectBuy (Discover's 3D Secure) is the defense that actually works. Full authentication shifts liability to the issuer.
  • Without it you're arguing with AVS/CVV results, delivery proof, and device logs. That wins sometimes, not most of the time.
  • You get 30 calendar days on the chargeback. Only 14 on a retrieval request.
  • The retrieval is the cheaper fight. It's the one people skip.

A cardholder told Discover they didn't place an order you fulfilled. Online, phone, or mail. That's UA02. It's the same complaint as Visa 10.4 and Mastercard 4837. On Discover it's the fraud code you'll see most.

Overview​

A cardholder says the charge wasn't theirs, and no card was present. Discover files UA02. That's online checkout, phone orders, mail orders, and anything else where the card never physically showed up. There's no chip read to fall back on. Everything you'll argue with is data you captured at checkout.

When This Code Applies​

  • Cardholder denies making an online purchase
  • Stolen card credentials used for a CNP transaction
  • Account takeover resulting in unauthorized orders
  • Family member makes purchase without cardholder knowledge
  • Friendly fraud (cardholder authorized the purchase but denies it)

Conditions for Valid Dispute​

Issuer Must Verify​

  1. Cardholder didn't authorize the transaction
  2. Transaction happened in a card-not-present environment
  3. Dispute filed within the allowable time frame
  4. Cardholder didn't benefit from the transaction

Transaction Must Be​

  • E-commerce (online checkout)
  • Mail order or telephone order (MOTO)
  • Recurring billing without proper ProtectBuy authentication
  • Any other environment where the card never physically appears

Time Frames​

StageWindow
Retrieval request response14 calendar days
Chargeback response30 calendar days
Second chargeback30 calendar days

Discover Retrieval Process​

Discover usually sends a retrieval request before the chargeback. That's your first and cheapest line of defense. Answer it well and the chargeback may never happen.

Answer Retrievals The Same Day

A good retrieval response can stop the chargeback before it exists. You get 14 days. You'd build the same file later anyway.

ProtectBuy (3D Secure) Liability Shift​

Full Liability Shift (Issuer Liable)​

The issuer eats the loss when all three of these are true:

  • ProtectBuy challenge completed by cardholder
  • ECI 05 = fully authenticated
  • Valid cryptogram present

Who Carries the Loss, by ECI​

ScenarioECIWho pays
Fully authenticated05Issuer
Authentication attempted, issuer unavailable06Reduced merchant liability
Authentication failed or not attempted07Merchant, in full
ProtectBuy not implementedN/AMerchant, in full

Representment Options​

1. ProtectBuy Authentication​

When to use: ProtectBuy ran and it passed.

Evidence required:

  • ECI value showing full authentication (05)
  • Cryptogram/CAVV
  • Authentication timestamp
  • ProtectBuy transaction ID

2. AVS and CVV Match​

When to use: AVS and CVV both matched.

Evidence required:

  • AVS response showing match (full or partial)
  • CVV2/CID match confirmation
  • Delivery confirmation to the AVS-verified address

3. Delivery Confirmation​

When to use: It got delivered. You've got tracking.

Evidence required:

  • Carrier tracking showing delivered status
  • Signature confirmation
  • Delivery address matching billing or AVS-verified address
  • Photo proof of delivery (if available)

4. Digital Goods Access​

When to use: They used it. You've got logs.

Evidence required:

  • IP address at time of download or access
  • Access/usage logs showing activity after purchase
  • Account login history
  • Download confirmation records

5. Prior Transaction History​

When to use: They've bought before and never disputed.

Evidence required:

  • Previous undisputed transactions from the same account
  • Matching email, device, or IP across transactions
  • Established customer relationship documentation

6. Cardholder Communication​

When to use: You've got the cardholder on record about the order.

Evidence required:

  • Order confirmation sent to and opened by cardholder
  • Customer service correspondence about the order
  • Chat transcripts or call recordings
  • Shipping address confirmation from cardholder

Required Documentation​

Evidence TypeStrength
ProtectBuy authenticated (ECI 05)Very Strong
AVS match + CVV match + signed deliveryStrong
Tracking delivered + AVS matchMedium-Strong
Prior undisputed transactions + device matchMedium
No authentication or delivery proofVery Weak

Win Rate Expectations​

Defense TypeExpected Win Rate
ProtectBuy authenticated (ECI 05)70-85%
AVS + CVV + delivery proof45-60%
Prior transaction history + device match35-50%
Standard evidence only25-40%
No evidenceUnder 15%

Read that table as a decision, not trivia. Without ProtectBuy your best case is a coin flip.

Prevention Strategies​

Authentication​

  1. Turn on ProtectBuy (3D Secure 2.0) - Moves the loss to the issuer
  2. Run the frictionless flow - Most customers never see it
  3. Challenge the risky ones - Only when a signal fires

Verification​

  1. Require CVV2 every time - Collect the code, no exceptions
  2. Check AVS - Every order, not just the big ones
  3. Verify email addresses - A bounced confirmation is a signal
  4. Call for the big ones - High-value or high-risk orders

Evidence Collection​

  1. Log everything - IP, device fingerprint, timestamps, session data
  2. Keep the conversation - Emails, chat logs, call recordings
  3. Require delivery confirmation - Tracking, plus signature on big orders
  4. Track account history - Today's boring order is tomorrow's evidence

Fraud Screening​

  1. Real-time scoring - Catch it at checkout, not later
  2. Velocity checks - Flag ordering patterns that aren't normal
  3. Device fingerprinting - Match devices across sessions
  4. Address validation - Cross-check shipping against billing

Common Mistakes​

  1. Skipping ProtectBuy - You're eating avoidable fraud
  2. No delivery confirmation - You can't prove they got it
  3. Ignoring retrieval requests - They don't go away, they escalate
  4. Dumping files on the issuer - A messy packet reads weak
  5. Not logging device data - No proof they were there
  • UA01 - Fraud: Card Present
  • UA05 - Fraud: Chip Card Counterfeit
  • UA06 - Fraud: Chip Card Lost/Stolen
  • UA11 - Cardholder Claims Fraud

Next Steps​

Got this chargeback?

  1. Check whether ProtectBuy ran → ECI 05 and you're in good shape
  2. Pull AVS/CVV results → Document the match status
  3. Gather delivery proof → Tracking, signature, address match
  4. Look for prior undisputed orders → Same device, email, or IP?
  5. Respond within 30 days → Representment Workflow

Prevent future UA02 chargebacks:

  1. Implement 3D Secure / ProtectBuy for liability shift
  2. Set up dispute alerts to refund before chargeback
  3. Configure fraud detection to catch unauthorized use early

See Also​

Last updated on