4 ms·

One thing you can try is to submit the credit card information as an Authorization Only transaction first. Most gateways will respond with a transaction id that

One thing you can try is to submit the credit card information as an Authorization Only transaction first. Most gateways will respond with a transaction id that you could then resubmit after confirmation from the user as a Prior Authorization and Capture transaction that would complete the transaction. Authorization Only transactions and their transaction ids expire after a set period of time if they're not submitted for capture (e.g., 30 days for authorize.net). You won't ever have to store actual credit card information in this scenario (just transaction information) and you can freely show the the last 4 digits of credit used. That's one solution I can think of, but if you can dig up a PCI compliant method to actually store the data, please share.

qeorge 17y ago
That's a really good idea Andy, and the gateway we're using in this particular case is primarily designed for restaurants (MercuryPay) so this would be commonplace for them. I wonder though if its a faux pas to run the card at all without confirming first. I would be fairly upset if a merchant authorized my card (resulting in a hold) and I didn't complete the purchase, but if the authorization is for a short enough time I think this would be OK. Also, a key function of the confirmation page is to minimize the number of invalid requests sent to the gateway, as too many bad requests can cause them to raise the rates. I'm starting to think there is no PCI compliant way to store a CVV2 for any period of time whatsoever, but I'm also incredulous that so many brand name merchants would so wantonly violate the policy. Perhaps with enough volume and Level 1 compliance the gateway will make an exception.
- jacquesm 17y ago
  The customer should not normally see any started but not completed transactions, but there have been cases where this data did become visible leading to lots of confusion. Confusion = Chargebacks. So you have to make really sure that there is no way the fact that you did that gets back to the customer. Are you doing your own scrubbing ? Or do you purchase a scrubbing service from the gateway provider ? The gateway is not the one that decides if you can store CVV2, the card companies make that decision. The rules for that are available, it's a fairly strict standard though. Encrypted harddrives, all kinds of physical security. I'm guessing that that is the reason why you see big name merchants do this, but hardly any little ones. I know of one company that actually set up an IPSP just for that purpose. They now make more money on that part of their business than on the original business...
- andymism 17y ago
  Jacques makes a good point that you should be careful with customers seeing started but not completed transactions. Any confusion on the customer's part is bad news. If you're going to go the route of authorization only then capture, then I'd suggest that you invalidate authorizations yourself after a set period of time (maybe a few minutes?) rather than let the gateway invalidate it based on their criteria. This doesn't, however, solve your problems with the number of requests sent to the gateway. I don't know much about MercuryPay (and their website is scarce on in-depth developer info), but maybe you could work with them on posting payment information and holding it until the transaction is confirmed?

qeorge 17y ago

That's a really good idea Andy, and the gateway we're using in this particular case is primarily designed for restaurants (MercuryPay) so this would be commonplace for them. I wonder though if its a faux pas to run the card at all without confirming first. I would be fairly upset if a merchant authorized my card (resulting in a hold) and I didn't complete the purchase, but if the authorization is for a short enough time I think this would be OK. Also, a key function of the confirmation page is to minimize the number of invalid requests sent to the gateway, as too many bad requests can cause them to raise the rates. I'm starting to think there is no PCI compliant way to store a CVV2 for any period of time whatsoever, but I'm also incredulous that so many brand name merchants would so wantonly violate the policy. Perhaps with enough volume and Level 1 compliance the gateway will make an exception.

jacquesm 17y ago
The customer should not normally see any started but not completed transactions, but there have been cases where this data did become visible leading to lots of confusion. Confusion = Chargebacks. So you have to make really sure that there is no way the fact that you did that gets back to the customer. Are you doing your own scrubbing ? Or do you purchase a scrubbing service from the gateway provider ? The gateway is not the one that decides if you can store CVV2, the card companies make that decision. The rules for that are available, it's a fairly strict standard though. Encrypted harddrives, all kinds of physical security. I'm guessing that that is the reason why you see big name merchants do this, but hardly any little ones. I know of one company that actually set up an IPSP just for that purpose. They now make more money on that part of their business than on the original business...
andymism 17y ago
Jacques makes a good point that you should be careful with customers seeing started but not completed transactions. Any confusion on the customer's part is bad news. If you're going to go the route of authorization only then capture, then I'd suggest that you invalidate authorizations yourself after a set period of time (maybe a few minutes?) rather than let the gateway invalidate it based on their criteria. This doesn't, however, solve your problems with the number of requests sent to the gateway. I don't know much about MercuryPay (and their website is scarce on in-depth developer info), but maybe you could work with them on posting payment information and holding it until the transaction is confirmed?