Transparent Redirect -- downsides?

[Tonearm]

Is anyone using a "Transparent Redirect" method of processing credit cards? From what I understand, this means posting the credit card form on your website to the processor and them transparently redirecting the user back to your site. This means you don't have to deal with PCI Compliance at all. Is there any downside to this?

[lorax]

If I understand you correctly, checkout is handled as a SaaS by a provider. I use this method for a handful of customers and it makes a LOT of sense to me for organizations with small budgets and want to save the headaches.

No downsides as long as you're transparent with the customer IMHO.

[jwolthuis]

This means you don't have to deal with PCI Compliance at all.

Not true; You still need to follow the PA-DSS guidelines.

For example, you can't create a form that collects payment info, stash it in your database, then post the info on behalf of the shopper.

Also, the guidelines require that you test your code against vulnerabilities. For example, can *I* post a redirect to your site, saying that a payment was successful? Do you log fraudulent attempts like this?

If you're storing payment authorization codes (handy if you ever need to issue a refund), are they stored securely in a separate database (not on your web server), behind a firewall?

[Tonearm]

If I understand you correctly, checkout is handled as a SaaS by a provider.

Actually no, you handle checkout yourself, but your checkout form posts directly to the processor. Here's a better description:

[braintreepayments.com...]

Not true; You still need to follow the PA-DSS guidelines.

You're right, I should have said PCI Compliance is much simpler and easier with transparent redirect.

If you're storing payment authorization codes (handy if you ever need to issue a refund), are they stored securely in a separate database (not on your web server), behind a firewall?

Is it required to store the authorization codes on a separate machine from the web server?