7 ms·

Thanks jacquesm. I'm somewhat familiar with PCI standards, and your answer is what I suspected. However, it doesn't totally answer my question, because confirma

• andymism 17y ago
  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?
• jacquesm 17y ago
  I'm guessing - without further information - that some of these people are not aware they are crossing the line, or that they have very special arrangements with the CC companies regarding the machines where this is happening. The demands on such a situation are pretty draconic, one step shy of having an armed marine in front of your server, otoh you have to sympathize with that since any machine that stores this information - even if only for 30 seconds - is with a high enough volume of cards a disaster waiting to happen. The rules are pretty straightforward, I've never been tempted to store CC information anywhere. For the record, a friend of mine runs a fair sized (E 150M+ / year) IPSP and I helped implement some of the bits, notably vbv, and yes, we do store the CC information there but those servers are in a class of their own with respect to security, nothing that I could justify for the sake of having a confirmation form. As to not building any kind of on-site payment processing into your site, yes, you can do that but you really should not want to. After all the target profile of your site goes up tremendously if you do that and you get very little gain for it back (the payment page is still on your server). That leaves all the employee and sysadmin related risks unmentioned, but those are unfortunately a reality as well. Most IPSPs (or at least the half decent ones) allow you to upload the registration form to their server. The idea is you pre-capture all the fields that you are interested in on a form on your site, the submit then populates the authorization via an underwater call to the server of the IPSP, then you redirect the user to your form on the server of the IPSP where they get their choice of credit cards and enter other sensitive information. That's where the final confirmation screen sits. The only really big downside here - and it is a serious one if your IPSP is not solid, which unfortunately has been the case several times, see DMR and IBill) is that if your IPSP bites the dust you lose the CC DB. This sucks royally, so you should limit your choice of IPSPs to those that require you to run your own merchant account. That way you are 100% sure that some other joker running fraudulent or wrongly tagged transactions is not going to cause your business to fall over one fine idle Tuesday. Storing the CVV2 data is out even for IPSPs, they only use it to verify the card at the moment the pre-auth for the first transaction comes through, after that it simply says 'verified' in their records, no need to store the CVV. > We build a lot of e-commerce sites for clients, and our standard MO has been to send the data to the gateway immediately and never store it. That's the way to do it. > In this particular case, a desire for a confirmation page was voiced Doesn't your IPSP provide you with this function ? After the confirmation they are allowed to send you back all the relevant information under water or in a POST to the return page, whatever works best (I prefer the under water system because it stops people from attempting to mess with the post fields). You are definitely asking the right questions here, as to how 'others' are pulling this off I'd have to look at specific examples and I might be able to tell you. I know some of the larger operators are willing to pay a premium to be able to hold on to the card info for various reasons but usually they find that the best way to do this is to abstract out this portion of their business and spin it out as an IPSP. It makes sense, because the investment is a sizable one and it is good business once you have the tech you might as well sell it as a service. EDIT: Theory about how you could make this work: You could simply send all the data back in the form in hidden fields, show whatever you want to show (last four digits of card numer, no CVV), ask the user to confirm which re-submits all the hidden fields and then go to the IPSP for the transaction. That way you get your confirmation form and you do not store any data at all, it's either in the users browser (their risk) or underway to the IPSP, the only time it is on your server is the exact moment you pass it on. Still, this is not as secure as having the IPSP serve up the pages.