4 ms·

> 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 w

by qeorge 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. I think it has to be the latter. I would expect any good auditor would notice this and flag it, but perhaps I'm being naive. > The rules are pretty straightforward, I've never been tempted to store CC information anywhere. I agree. In this case we'll just skip the confirmation screen, possibly using JS to simulate one where its available. Its frustrating though, because I hate impacting the customer experience because of technical issues (especially in e-commerce). > 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. What's a good IPSP to use for this? Would we be able to mask the URL with one of our own, provided we buy our own SSL? I've looked at PayPal's Direct Pay, Mercury Pay, and several others but haven't found one that provides a good user experience, allows us to mask with our domain, and allows the branding we need. FoxyCart.com looked promising, but they don't support users without Javascript, so that's a non-starter (and illegal). >> 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. Thank you, very good to hear confirmation on this. > 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. This was actually the method we used during the initial build, just as a placeholder. But it just seems so inherently wrong. My fear would be these pages being cached, and then the customer's CC info would be sitting on disk waiting for a piece of malware to find it. I know we could send a no-cache header, but I don't trust the browsers to honor the directive. And even though the risk would be offloaded to the user, we still want to avoid putting their data in harm's way whenever possible. I really appreciate all your thoughts on this matter. I feel like this is a big blind spot for many online merchants, and is worth getting right.

jacquesm 17y ago
This is getting long :) Feel free to email me by the way. Tegarding the 'auditors', mistakes are made, it happens and not all audit rounds are equally good. Some are downright ridiculous (telling you to change stuff the previous audit told you to do). I don't think it is appropriate to advertise any IPSPs here, the biggest things to look at are segregated merchant accounts, how long have they been in business, hold back period, fees, integration capabilities, customer service department reputation and references. Roughly in that order. It also helps if they process a sizable volume so that when there is a problem it is not just your problem. Masking your own URL is the one thing that always seems to come up as a 'desirable' because nobody likes to send the customer elsewhere at the moment of making the sale. But in practice it doesn't really matter much, as long as you get editorial control over the content of the landing page on the IPSP side and the customer is aware that a transition is going to happen and they get back to where they were on completion of the transaction. The latter is very important. If your IPSP can not give you that sort of functionality then it might be problematic, it could cost you sales. Using your own SSL certificate is not going to be enough to mask the IPSPs URL, after all, once the data captured gets posted you are on their domain anyway. I personally prefer to have the transition happen at the same moment you go from unencrypted to encrypted, that way you sort of guide the customer to the very last step before the payment happens. Depending on your environment that means they've filled up their cart or selected the type of subscription they wish to purchase and then the next click will take them to the 'checkout' where their payment information is captured. I agree the repost seems wrong, but the good news here is that if you are in https anyway then caching is not your problem. No browser or proxy will cache that stuff, if it has passed there once during the post it might as well pass twice more, no harm done. The only thing that is vulnerable to is mitm and by that time that has already happened, the only difference being that your mitm now has three copies of the data instead of just one.
- qeorge 17y ago
  IMHO, eliminating any potential source of confusion from a checkout flow is worth doing, and so masking the domain is usually worth it. And although we know it doesn't make a difference in practice, customers and clients don't like it. Your point about SSL and mitm makes sense. I'll look into the idea of temporarily storing the data in hidden fields, and if I find anything definitive I'll be sure to update. Thanks for the followups, I greatly appreciate your help. If I have further questions I will email you.

by qeorge 17y ago

jacquesm 17y ago

This is getting long :) Feel free to email me by the way. Tegarding the 'auditors', mistakes are made, it happens and not all audit rounds are equally good. Some are downright ridiculous (telling you to change stuff the previous audit told you to do). I don't think it is appropriate to advertise any IPSPs here, the biggest things to look at are segregated merchant accounts, how long have they been in business, hold back period, fees, integration capabilities, customer service department reputation and references. Roughly in that order. It also helps if they process a sizable volume so that when there is a problem it is not just your problem. Masking your own URL is the one thing that always seems to come up as a 'desirable' because nobody likes to send the customer elsewhere at the moment of making the sale. But in practice it doesn't really matter much, as long as you get editorial control over the content of the landing page on the IPSP side and the customer is aware that a transition is going to happen and they get back to where they were on completion of the transaction. The latter is very important. If your IPSP can not give you that sort of functionality then it might be problematic, it could cost you sales. Using your own SSL certificate is not going to be enough to mask the IPSPs URL, after all, once the data captured gets posted you are on their domain anyway. I personally prefer to have the transition happen at the same moment you go from unencrypted to encrypted, that way you sort of guide the customer to the very last step before the payment happens. Depending on your environment that means they've filled up their cart or selected the type of subscription they wish to purchase and then the next click will take them to the 'checkout' where their payment information is captured. I agree the repost seems wrong, but the good news here is that if you are in https anyway then caching is not your problem. No browser or proxy will cache that stuff, if it has passed there once during the post it might as well pass twice more, no harm done. The only thing that is vulnerable to is mitm and by that time that has already happened, the only difference being that your mitm now has three copies of the data instead of just one.

qeorge 17y ago
IMHO, eliminating any potential source of confusion from a checkout flow is worth doing, and so masking the domain is usually worth it. And although we know it doesn't make a difference in practice, customers and clients don't like it. Your point about SSL and mitm makes sense. I'll look into the idea of temporarily storing the data in hidden fields, and if I find anything definitive I'll be sure to update. Thanks for the followups, I greatly appreciate your help. If I have further questions I will email you.