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.