Awesome, thank you John. Now I understand where you are coming from and why we couldn’t initially agree on this.
You are looking at it purely from a developer’s point of view and I have been looking at it from the point of view of a business that wants to have custom order forms. As a business we need to consider a lot more than just secure programming.
Keeping the servers PCI compliant is much more difficult than following the development best practices.
Since this thread may be read by other people in the future, I want to conclude it and address some questions you raised in the previous comments in context with your and my viewpoint.
1. Why would you want to use the Direct Post method described in the initial post?
Because as a business that is responsible for the server’s PCI compliance, you will reduce your PCI compliance liability from SAQ D to SAQ A-EP, which is easier to handle.
I think this is important for both developers like yourself and for end-users. Using that API will make it easier for your clients to be compliant.
2. Why do you think IS should implement an additional credit card submission method
In my previous posts I was comparing IS to braintree and stripe and arguing that since they have frameworks to submit credit card info in a way that makes PCI compliance very easy, that IS should too.
You rightfully pointed out that IS is not a credit card merchant and is simply a processor.
I still think they have the same responsibility though, because you can’t use IS’ e-commerce features effectively without adding credit cards to their system. If I start using stripe to charge my orders, I won’t be able to use IS subscriptions to actually bill them in regular intervals without crazy hacks.
The choices right now are use their hosted order forms and be PCI compliant. Or use the API, which makes PCI compliance on the server side a nightmare. I am fairly certain that the vast majority of people who are using the API to create orders have not gone through the ordeal of making their servers PCI compliant. Most people aren’t even aware that they need to.
This creates a risk for both the businesses and infusionsoft.
And yes, Infusionsoft is not a merchant account like stripe. But two similar and close competitors in the e-commerce space are recurly and chargebee.
Both of them have extensive documentation on how to be PCI compliant with custom order forms and offer multiple methods to add credit card data. One of which is an iFrame that brings PCI compliance for the business / server owner down to essentially zero.
Here’s their documentation:
Going forward I will submit a feature request as you’ve suggest. That seems to be a better place than here. And I would encourage anyone else who’s reading this to do the same.