We are using a payment processor called Worldpay which is UK based, who acts your payment processor and acquiring bank so its very easy for any merchant to sign up with them. They are using royal bank of scotland. I’ve recently started using vbv and securecode a few months ago, recently the card user raised a dispute one of those “I didn’t do it” types. It was a visa transaction, not mastercard. The transaction is question is a “cardholder not enrolled” status, which means we are fully covered by Visa merchant protection. But now its time for us to see whether this deal is too good to be true. I have a few questions
When I called up worldpay staff told me this transaction was marked as eligibility shift = Y. But yet they have frozen part of our cash reserves, in case this dispute ever materializes into a chargeback. Should I be worried? And will the fact that worldpay is uk based, our organisation in Asia and the card holder is from Brazil have any effect on eligibility shift? Will chargeback blocking still apply here? Worldpay seems to have its claws out ready to take the money back from us if the issuing bank wins the case.
The confusing thing worldpay said that eligibility shift is not 100% absolute (for user authenticated and cardholder not enrolled) and we still need to review each customer carefully before we accept his payment. They even said some fully authenticated fraudulent transaction have been chargebacked before. Or that issuing banks can simply change the reason codes to something else if the original fraud chargeback intended was blocked. Is there basis on what they have said and can we end up taking the losses? That’s bad since vbv was meant to alleviate merchants from such problems. Issuing banks seem to throw the unpleasantries back to us merchants instead of honoring the agreements set out by Visa/Mastercard.
Assuming cardholder not enrolled protection was really a godsend, and we receive full protection. But do we still have the responsilibilty to help issuing banks screen out fraud orders? Worldpay sometimes marks each transaction as a “warning” status. Previously without vbv, we might get more info from the buyer to make sure he is for real. But now with vbv, the logic would simply to accept all transaction marked “cardholder not enrolled” since if there was any problem later, it would be the problem of the issuing bank, not us. What is our responsiblities as merchant in this aspect?
Hope you can really answer these important questions. I’ve been having a lot of sleepness nights worrying about the eventual outcome of the dispute. Will update this forum when I get the verdict.
smallvolume - I assume you use AVS [address checks] and CVV [credit card code checks] as well as IP checks? Those things can help you cut back on the fraud orders. Even if you are protected, too much of those and the merchant account may shut you down and add your name on the bad black list.
Yes, we use AVS and CVV checks which helps to flag transactions as “warning” or “caution” status as I mentioned in point 3 above. Your point about needing to screen fraudulent customers or end up in visa’s black list despite protection. My first impression was that since using vbv any transactions that come through marked as “user authenticated” or “cardholder/bank not enrolled” and we can accept them without debate. I now understand why we might need to fulfil our role as merchants to screen out fraud orders. Since if issuing banks are forced to take losses again and again because we simply accepted questionable payments, then this will raise a red flag about the quality of our company. I hope thats the case, since I would want to know we are NOT wasting our time and resources to screen transactions e.g. asking for customer billing statements, etc, when we didn’t really have to because we are protected no matter what.
Should you be worried?
It depends. WorldPay is not a customer of Cardinal so we have almost no visibility on whether or not they are properly passing CAVV and ECI data.
And will the fact that worldpay is uk based, our organisation in Asia and the card holder is from Brazil have any effect on eligibility shift?
It shouldn’t have any effect on the protection as long as the tranactions are qualifying accordingly.
Will chargeback blocking still apply here?
No. Chargeback blocking is only available on US to US consumer transactions for Visa. You will still need to represent the transaction since you’re an international merchant.
Is there basis on what they have said and can we end up taking the losses?
No. If you are passing the data accordingly and transactions are qualifying for CPS Preferred and UCAF than the protection should be in place. Issuers changing reason codes is a myth. It’s highly unprobable since the dispute resolution groups are monitored by Visa and MasterCard and they operate under strict procedures. If you can identify a specific example of when this occurred WorldPay should present the case to Visa/MC. There are strict fines associated with this which they will execute.
Assuming cardholder not enrolled protection was really a godsend, and we receive full protection. But do we still have the responsibility to help issuing banks screen out fraud orders?
Absolutely. You need to run both AVS and CVV2 to qualify for the programs protection.
Advise:
Contact Worldpay and absolutely make sure the transactions have qualified for the correct interchange status. When you receive the CB make check what reason code it was chargedback for. Then follow the represent procedure for VbV merchants specified by Visa. WorldPay can provide this to you.
You can also contact your acquirer for additional information. Please also note that SecureCode is mandated for ALL merchants who accept Maestro, Switch, or Solo cards. If you are not running SecureCode and you accept these card types you orders will not pass authorization.
What will happen to a transaction that went through 3D secure processing and then was slightly different when actual processor authorization was processed? (amount change, shipping cost addition, split transaction, etc) Many merchants do not perform thier actual authorizations in real time but wait unitl stock levels are checked, shippint costs are verified, etc. Will the ECI and 3D secure validation hang on the transaction for fraud protection and interchange reductions? Thanks
I know this is an old thread but couldn’t help but reply on why this would happen. It is most likely that the bank declines 3D secure transactions that are verified because all liability will go to the issuing bank for chargebacks, whereas if verification fails, chargeback liability will reside with the acquiring bank. While 3D secure claims to protect merchants from chargebacks (ie, guaranteed payment, cardholders can still claim that “goods or services not rendered” and a chargeback will still be processed thru". Hope this helps.
It would be interesting to know if the issuing banks HAVE to abide by the rules of VbV, or if like the last poster suggests, and I am more likely to believe, they can choose to just not accept transactions that fall under the protection of VbV.
If I were a bank, that’s what I would do if I were allowed. Why would I want to take on the liability?
I been using CDG Commerce to process credit card payments where you Cardinal Commerce guys set the VbV/SC up for them, and in result for authenticated transactions I still received chargebacks for fraud- card absent reason code, the cards were issued in the US. AVS/CVV was total match.
And CDG people told that there is no such thing as chargeback protection for fraud reason code. What happened with ‘chargeback blocking’ ?
I am a future e-merchant who is interested in implementing 3D-Secure payer authentification. My business will be UK-based, and I am using UK Paypal Payments Pro API to process both credit cards and paypal payments. Paypal UK does not provide in-build 3D-secure check so I would like to have a developer implement it for my website. However, I have several questions regarding this service and I would be very grateful if somebody can provide me with some answers:
1-Knowing that the Paypal API is different in the US and UK, would the British Paypal API be compatible with a 3D-secure software?
2-if not, can I have a 3D-secure software or API run independently to perform the authentification before submitting the data to the Paypal payment processor?
3- Does anybody know a 3D-software or API provider that can provide this service?
4-Except the implementation costs, how much would it cost to me, as a merchant? (any setup fees? monthly fees? transactions fees?)
It seems to me that care must be taken to explain to the user when they’ll be taken to VbV. It isn’t common yet, so a clear explanation would help, I’m sure.
