Hello All!
Just yesterday we had a patron who asked to pay with his Citibank generated credit card number. I am not exactly on top of all the most recent payment method changes, but it seems as though with select cards, you can be signed up for this service which will help protect you against fraud by literally generating a temporary card number that is only valid for a couple of days. We tried processing the card number, and that did not work; he said that might be because he generated it a couple of days ago. So he generated a new one, and we tried that; that one did not work either. As such, he was a pretty amenable guy, and we just processed it using one of his other, regular card numbers.
My question is whether anyone else has had experience with this, and if you have gotten them to work. I have to imagine that there might be only so much control over which we can have on this, but I at least wanted to ask the question. At any rate, if this is what card companies are starting to do (and, if I put on my PCI Compliance/Data security hat, I certainly would argue strongly for them), then obviously at some point we would need to be able to keep up with it, too.
We are on Version 15.0.6, RAMP, Vantiv processing. We have VX805 chip readers, but that was not in play here. Appreciate any thoughts. Thanks!
John
Hello,
This isn't really new functionality. I've been using virtual credit card numbers for almost a decade - its so great to use on something that has a trial period that requires a credit card. Setup a virtual CC # for an amount and date range and then you don't have to worry about it if you forget to call and cancel :)Also, as Chris noted Apple is already using this pretty transparently with Apple Pay - when you take Apple Pay you'll find the credit card number that it provides is not actually the card holders. I'd be curious to see what the error codes you got back when trying to process this - I wonder if its an AVS or CVV issue and not really the CC #.
Well if it is not new, it is new to me.
Not having been there myself, it is hard to say for sure, and you never can tell as by the time the error makes its way to IT half of the time it is made to sound like the errors are always so bad that the system is freaking out and will be shut down. That said, I got word from a staff member who is usually pretty good about these things; he indicated that it was just a general error sort of issue. Not a CVV or AVS issue that he could tell from how he described it to me. Just sort of a general declination.
Hi John -
We're happy to take a look at the payment logs with you to determine why this was declined. You may find some detail by querying V_PAYMENT_GATEWAY_ACTIVITY as well. If you'd like assistance, feel free to open a TASK ticket and we'll jump in.
Thanks,
Patrick
I looked there, and it looks like the AVS result code is 'R' and the CVV result code is 'P'. From general google results, I am given to understand that 'R' means "System unavailable; retry" while 'P' means "Not Processed".
Given the above, it appears that, for whatever reason, these transactions were just not being processed, despite everything working at the time. And the successful run of the "regular" credit card number two minutes later would again seem to disprove the notion of an issue. We had no other reported credit card processing issues that day either.
Happy to continue this in a TASK ticket if you feel like that is worthwhile, but I doubt there is anything specific to our set up in particular that caused this.
Good sleuthing... Could be that the processor's AVS system was having a problem right at the time of that transaction. Without knowing more, I would guess that if they tried this again it might work. Beyond that, if it was declined again with the same results you might need to ask the payment processor about that.
Thanks!