Skip to main content

Discover UA02 - Fraud: Card Not Present

On this page
TL;DR

UA02 is Discover's primary fraud code for e-commerce and card-not-present transactions. The cardholder claims they did not authorize the charge. Your strongest defense is ProtectBuy (Discover's 3D Secure program): with full authentication, liability shifts to the issuer. Without it, you need AVS/CVV results, delivery proof, and device evidence. Response window is 30 calendar days.

Overview​

Discover files UA02 when a cardholder reports that a card-not-present transaction was not authorized. This covers online purchases, phone orders, mail orders, and any transaction where the physical card was not presented. It is the most common Discover fraud code and the equivalent of Visa 10.4 and Mastercard 4837.

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 did not authorize the transaction
  2. Transaction occurred in a card-not-present environment
  3. Dispute filed within the allowable time frame
  4. Cardholder did not benefit from the transaction

Transaction Must Be​

  • E-commerce (online checkout)
  • Mail order or telephone order (MOTO)
  • Recurring billing without proper ProtectBuy authentication
  • Any CNP environment

Time Frames​

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

Discover Retrieval Process​

Discover frequently sends retrieval requests before filing a chargeback. Treat these as your first line of defense. A strong retrieval response can prevent the chargeback entirely.

Respond to Retrievals Immediately

A strong response to a retrieval request can prevent the chargeback from ever being filed. Treat retrievals as urgent. You only have 14 days.

ProtectBuy (3D Secure) Liability Shift​

Full Liability Shift (Issuer Liable)​

When the transaction is fully authenticated through ProtectBuy:

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

No Liability Shift (Merchant Liable)​

ScenarioECIMerchant Liability
Authentication attempted, issuer unavailable06Reduced
Authentication failed or not attempted07Full
ProtectBuy not implementedN/AFull

ECI Values​

ECIMeaningLiability
05Fully authenticatedIssuer
06Attempted authenticationReduced merchant
07Not authenticatedMerchant

Representment Options​

1. ProtectBuy Authentication​

When to use: Transaction was authenticated via ProtectBuy (3DS).

Evidence required:

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

2. AVS and CVV Match​

When to use: Address and security code verified successfully.

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: Physical goods were delivered to the cardholder.

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: Digital products or services were accessed by the cardholder.

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: The cardholder has a history of undisputed purchases with you.

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 have direct communication acknowledging the purchase.

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%

Prevention Strategies​

Authentication​

  1. Implement ProtectBuy (3D Secure 2.0) - Primary liability shift for Discover
  2. Use frictionless flow - Better UX while maintaining protection
  3. Challenge high-risk transactions - Step up when fraud signals present

Verification​

  1. Require CVV2 on every transaction - Always collect the security code
  2. Check AVS - Verify billing address on every order
  3. Verify email addresses - Send order confirmations
  4. Phone verification - For high-value or high-risk orders

Evidence Collection​

  1. Log everything - IP addresses, device fingerprints, timestamps, session data
  2. Retain all communications - Emails, chat logs, call recordings
  3. Require delivery confirmation - Tracking plus signature for high-value orders
  4. Document account history - Build customer profiles over time

Fraud Screening​

  1. Real-time fraud scoring - ML-based detection at checkout
  2. Velocity checks - Flag unusual ordering patterns
  3. Device fingerprinting - Track and match devices across sessions
  4. Address validation - Cross-reference shipping and billing addresses

Common Mistakes​

  1. Not implementing ProtectBuy - Missing liability shift protection
  2. No delivery confirmation - Unable to prove receipt of goods
  3. Ignoring retrieval requests - Letting them auto-escalate to chargebacks
  4. Weak evidence packaging - Submitting incomplete or disorganized documentation
  5. Not logging device data - Missing key evidence for proving cardholder involvement
  • 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 if ProtectBuy was used --> If ECI 05, you have a strong defense
  2. Pull AVS/CVV results --> Document match status
  3. Gather delivery proof --> Tracking, signature, address match
  4. Check for prior undisputed transactions --> Same device/email/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