Visa 12.6 - Duplicate Processing/Paid by Other Means
Overview
Used when a cardholder was charged multiple times for a single transaction, or when a charge appeared on both card and another payment method.
When This Code Applies
Duplicate Processing
- Same transaction submitted twice
- Multiple authorizations cleared separately
- Batch submitted multiple times
- Technical error caused duplicate
Paid by Other Means
- Charged to card AND paid cash
- Charged to card AND different card
- Charged to card AND via check
- Charged to card AND bank transfer
Time Frames
| Scenario | Dispute Window |
|---|---|
| Standard | 120 days from duplicate transaction date |
| Each duplicate | Can dispute each extra charge |
Conditions for Valid Dispute
Cardholder Must Show
- Same goods/services charged multiple times
- Only one transaction should have occurred
- Additional charge(s) were unauthorized
- Not separate valid transactions
Evidence of Duplicate
- Same amount
- Same/similar date
- Same merchant
- Single purchase occasion
Representment Options
1. Not a Duplicate
When to use:
- Two separate, valid transactions
- Different items/services purchased
- Different dates (days apart)
- Cardholder made both purchases
Evidence required:
- Separate receipts for each transaction
- Different items on each receipt
- Proof cardholder participated in both
- Transaction timestamps showing separation
2. One Charge Already Refunded
When to use:
- Duplicate was identified and refunded
- Credit already processed for extra charge
Evidence required:
- Refund transaction details
- Refund ARN
- Date refund processed
3. Split Transaction
When to use:
- Large purchase split into multiple smaller charges
- Disclosed to cardholder at time of purchase
- Common for high-value items
Evidence required:
- Receipt showing split
- Cardholder acknowledgment
- Total matches purchase amount
4. Different Services/Products
When to use:
- Multiple charges for different things
- Cardholder confused but both valid
Evidence required:
- Itemized receipts for each charge
- Service dates (if different)
- Order numbers (if different)
Required Documentation
| Evidence Type | Strength |
|---|---|
| Separate receipts + different items | Strong |
| Refund already processed | Strong |
| Split transaction documentation | Medium-Strong |
| Same receipt, different totals | Weak |
Representment Time Frames
| Stage | Window |
|---|---|
| Response | 30 days |
| Pre-arbitration | 30 days |
| Arbitration | 45 days |
Prevention Strategies
Technical Prevention
- Transaction IDs - Unique identifier per transaction
- Duplicate detection - Real-time at POS/gateway
- Batch review - Check before settlement
- Timeout handling - Proper retry logic
- Error recovery - Don't resubmit blindly
Process Prevention
- Single swipe/entry - One entry per transaction
- Receipt verification - Customer sees charge
- Confirmation screen - Digital transactions
- Staff training - Avoid accidental duplicates
- End-of-day review - Catch before settlement
Monitoring
- Duplicate alerts - Flag same card, same amount
- Same-day review - Multiple transactions review
- Batch analysis - Look for patterns
- Exception reporting - Investigate anomalies
Technical Causes of Duplicates
| Cause | Prevention |
|---|---|
| Timeout retry | Wait for response, don't auto-retry |
| Double-click | Disable button after first click |
| Batch resubmission | Mark processed batches |
| Network hiccup | Implement idempotency |
| Terminal error | Staff training on error handling |
Win Rate Expectations
| Scenario | Expected Win Rate |
|---|---|
| Separate valid transactions | 65-80% |
| Refund already issued | 80-95% |
| Split transaction documented | 55-70% |
| Cannot prove separate | Under 25% |
Common Mistakes
- No duplicate detection - Duplicates not caught
- Same receipt - Can't show different transactions
- No unique IDs - Hard to prove separation
- Slow refunds - Customer files before credit
- Poor batch process - Resubmitting settled items
Distinguishing Duplicates from Legitimate
Likely Duplicate
- Same exact amount
- Same day (within hours)
- Single purchase scenario
- Customer bought once
Likely Separate Transactions
- Different amounts
- Different days
- Different items
- Customer returned/bought again
Related Codes
- 12.5 - Incorrect Amount
- 13.1 - Not Received
Next Steps
Got this chargeback?
- Compare transaction records → Are these truly different transactions?
- Check if refund already issued → Already credited one?
- Pull separate receipts/orders → Show different purchases
- Respond within 30 days → Representment Workflow
Prevent future 12.6 chargebacks:
- Implement duplicate detection at POS/gateway
- Add unique transaction IDs to all charges
- Review batches before settlement
- Check operations checklist