RMS in a MOTO environment and fraud screening

hi

since most of our transactions come are MOTO, we need to have an AVS and CVV match before we can make a sale.

A transaction thru TPI's payment server gets approved even if AVS and CVV do not match. There is no way to set it to behave differently (unless you mess with the SDK). TPI's RMS plug-in informs the user of the status (match/no match), but by then transaction has already been approved and captured (if you could do auth only with the TPI payment server you could go in and void that auth, but even that would be an extra step in the workflow).

I would like to setup RMS to work like we have authnet/verisign set to work (reject if no avs and/or no cvv match) for MOTO orders. This obviously can't be done with built in functionality, as RMS wasn't built with the MOTO environment in mind. This can't be done with TPI's payment server either. Does anybody know if it CAN be done with PCcharge, ICverify, or mercury's payment server?

I don't mind doing my homework and I will post the answer here in case I don't get an answer.... but i imagine somebody out there already faced the same situation.

Thanks,

Reply to
Eddie B
Loading thread data ...

Eddie,

IC Verify and I'm pretty sure that PCC won't do it from within RMS. Mercury used to use the TPI software, but now they are using RMS' built-in. I don't think they can, but Marc Katz from Mercury is answering questions here or try emailing him to confirm at mkatz@*nospan*mercurypay.com

Reply to
Jeff

Eddie,

The built in EDC functionality definately won't do it. The TPI functionality is pretty close, since it will accept the CVV value. Perhaps you could talk to TPI about what you want. What you want them to do is to do an auth (often for $1) with the CVV value. If the result comes back without a match, then they would not proceed and would return a decline, indicating a CVV mismatch. I'm sure they could do it, but they don't do that today. Otherwise, I think you may be SOL. But perhaps there is is still something out there that I'm not aware of.

Good Luck, Marc Katz Mercury Payment Systems

Reply to
Marc Katz

PCCharge does have the option to decline transactions that don't match CVV or AVS. However, since the RMS integration with PCCharge does not include sending over CVV or AVS information, PCCharge would never have the option to decline because it never gets a chance to match.

Maybe your best bet is to get PCCharge, and open it directly to process MOTO orders (and set it to decline if those items don't match.)

Jared

Reply to
Jared

Reply to
Mark S

I did talk to TPI about it, and it is something that would have to be developed. We don't have the time to wait for this to happen. As Jared said, PCC outside of RMS might be the way to go. Could someone please point out some of the disadvantages of this method, aside from the extra step in the workflow?

Reply to
Eddie B

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.