Morning all,

Curious for some input.

Customer filed a Reg e dispute for tickets that were purchased that he vehemently states he did not do/authorize. Customer has provided multiple emails from a shared email address with his spouse that is on file with the bank, showing tickets were purchased through a reseller site for an NFL game in a town about six hours away from us. The email documentation has his shared email address, name, address, purchase amount, and confirmation number on it. He is adamant his spouse, a joint owner on the account, did not do the transaction in question.

Customer has also shared with the bank that he spoke with the merchant and they provided the same information above, but noted the phone number used for the transaction is one digit different than his.

We've contacted the merchant and located the transaction in question with an automated IVR system with his phone number on file, although the system stated it was for a different event. I plan to follow up on that, just to confirm. Merchant would not provide any additional information to the bank by phone call. All documentation he's provided to us, shows that he has been provided the links to accept the tickets, thus the potential benefit of the transaction.

To be clear, I have no evidence he sat at the computer or device and made the transaction. However, we have documentation showing he will benefit by accepting the tickets in the emails he provided. I realize it's a business decision how we proceed, but I'm curious how other like minded Reg E processors in this forum may handle this dispute. My compliance lead (also on this forum) and I have picked this apart and at this point we are leaning on a refund, but are planning to applying PC and submitting it as a dispute to the merchant through the networks, but again additional cost for something that his documentation shows he can benefit from the transaction.

Any thoughts?

Perhaps try that IVR with the "wrong" phone number that was one digit off and see if it comes up with the proper event? My thought is that the "right" phone number might be finding the previous legitimate purchase and the disputed purchase may live underneath that "wrong" phone number.

CNP when there is no physical good delivered can get a little more difficult to prove the Reg E claim was authorized activity.

If the ticket was retrieved through email, it's certainly possible there is another household member besides the joint owner that is able to access the email, or that the cardholder's email is compromised and an unknown actor is able to access the email. Someone with such access to the cardholder's inbox could also "delete the evidence" of confirmation emails around this purchase.

If the purchase comes up under the "wrong" phone number when you call the IVR, you could try your luck at chargeback.

If they represent with compelling evidence, fight the compelling evidence if the phone number in the compelling evidence comes up incorrect. I'm often successful here if the compelling evidence has any inconsistencies. Alternately, the compelling evidence might have additional evidence for your investigation.

Of course, where it's CNP, make sure the transaction wasn't 3D Secure eligible before you try the chargeback. If it was, you might not have chargeback rights but there may be additional evidence for your investigation within your processor's 3D Secure system.

The other thing to consider in all this, before chargeback or potential pre-arb comes into play, is the cost of the transaction if you absorbed it as cost of doing business. Chargebacks and prearbs have fees associates (particularly if you are on the losing end), as well as the cost of your wages and time.

Thanks MtnHiker.

I'm concerned if it's a 3D Secure. Our processor doesn't show us if the merchant participates until we do a chargeback, which is a major pain point for me. We currently do not participate in 3D secure.

Part of thing I'm torn on with the emails is what if someone had access to the email and the card, maybe a child. Certainly unauthorized then. Still question if the customer is being fully truthful with us, but we'll never know that side of the story.

Yeah, if the merchant participates in 3D secure and you do not, that will shift the liability to you. Usually Ticketmaster direct is 3D Secure.... I'll stop short of saying that is the case 100% of the time, but we usually see Ticketmaster as 3D Secure. Maybe it's not TM, just throwing it out there.

You are forbidden to "require" this, but I think you could "ask" if the cardholder is willing to sit with a rep and see if the confirmation/ticket retrieval email is in their inbox? Willingness or refusal to take this step might tell you something.

I think it's getting close to time to consider 3D Secure. We're loosing more and more chargebacks because of it.

Honestly, the customer's been very forthcoming with documents and working with us. What makes me wonder is we have the ticket retrieval email in his email inbox and has provided that to us but maintains his statement he didn't do it.

It's definitely worth looking at; you'll lose 100% of chargebacks that were 3D Secure eligible if you don't participate. If 3D Secure was implemented well by yourself and your card processor, it should hopefully prevent transactions from happening if there is low confidence that it is your cardholder.

My $0.02 on 3D secure is if you wind up going out of your way to make it "zero friction" it doesn't have much value over the neural scores you probably already get from the card brands or services like Falcon. If your 3D secure implementation can authenticate your cardholder with a pw or 2FA, then it adds a lot of value. Sometimes it comes down to what your card processor can do for you with 3D Secure and how much friction you want to introduce at the time of purchase.

If he retrieved the confirmation from his inbox but maintains it wasn't him, I think that comes down to whether you can prove he authorized it or if there is sufficient possibility it was "unauthorized family activity," or perhaps his email was hacked.