[How To & Feature Request] PCI Compliant way to add Credit Cards

Hi,

I just figured out a way to add credit cards to a contact in a PCI compliant way. For a reason I can’t explain this API is not documented by Infusionsoft and I wanted to share my findings.

Important:
Before I show you how to do it, I would like to make you aware that this way is not perfect. At the bottom of this post I have included a feature request for IS to add a MUCH better way to handle PCI compliance on custom order forms. Pleas check it out and contact IS to request. If we show there is big demand for it, perhaps they will do it soon.

Background:
It’s always been possible to charge orders through the API after adding credit cards through DataService.add. But the problem is that it has to be done server-side, which means you have to send credit card details to your own sever.

That classifies you as a “credit card data processor” according to PCI and you become liable to the most stringent requirements of PCI compliance SAQ D. These are VERY difficult to pass.

Well, it turns out IS has an undocumented API to add credit cards through an AJAX direct post.

This makes you liable for the SAQ A-EP compliance. This compliance is still a pain in the… and you’ll have to do quarterly security scans of your pages, but it is much easier to pass than SAQ D. It makes it feasible (although still unnecessarily annoying) to create custom order forms and be PCI compliant.

With this post I want to share what I’ve learned about this process.

The PCI Compliant Process:

  • Make a server-side API call to CreditCardSubmissionService.requestSubmissionToken to get a submission token
  • Do a client-side AJAX HTTP Post to IS’ endpoint with the credit card details to create a card
  • Make server-side API call to CreditCardSubmissionService.requestCreditCardId to retrieve the IS credit card ID
  • Make a server-side API call to charge the order using the credit card id

Here is an example of how this could be done in python and the browser console.

 In [40]:  infusionsoft.CreditCardSubmissionService('requestSubmissionToken', 727953, "https://your.server.com/cc_success", "https://your.server.com/cc_failure")`

 Out[40]: '8fa6567f-fbbe-4c8f-a739-85ebe31bfa55'

The returned value is the unique token. This should be used when you POST the credit card info to IS. If the POST is successful, IS will redirect you to the success url and if it fails to the failure one.

Here is the AJAX Post request that I did in the web inspector console. I used the same field names as in the CreditCard table reference. I assume you can submit all the other fields that are saved for a credit card, but I haven’t tested it yet.

data = {'token': '8fa6567f-fbbe-4c8f-a739-85ebe31bfa55', 'NameOnCard': "Test User Browser 6", 'CardNumber': "4698226949164271", 'CardType': "Visa", 'CVV2': "123", 'ExpirationMonth': "12", 'ExpirationYear': "2020"}
var success = function( data, textStatus, xhr ) {
  console.log("Success: " + xhr.getAllResponseHeaders());
};

$.post("https://XXXXXX.infusionsoft.com/app/creditCardSubmission/addCreditCard", data, success).fail(function( data, textStatus, xhr ) {
  console.log("Request failed, but we expected that");
});

The result was:

19:07:44.454     2018_04_ta_secure_order_exception_f8481e8:1 Failed to load https://XXXX.infusionsoft.com/app/creditCardSubmission/addCreditCard: Redirect from 'https://XXXX.infusionsoft.com/app/creditCardSubmission/addCreditCard' to 'https://your.server.com/cc_success?cardType=Visa&expirationMonth=12&expirationYear=2020' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://your.server.com' is therefore not allowed access.

19:07:44.454 VM550:6 Request failed, but we expected that

Here are the response headers IS sent (copied from the browser’s web inspector Network tab):

cache-control: no-cache, no-store
content-language: en-US
content-length: 0
date: Mon, 07 May 2018 11:07:43 GMT
expires: Mon, 07 May 2018 11:07:44 GMT
location: https://your.server.com/cc_success?cardType=Visa&expirationMonth=12&expirationYear=2020
pragma: no-cache
server: Apache-Coyote
set-cookie: JSESSIONID=9D7CF429C25339F0E58B218C50E996A9; Path=/; Secure; HttpOnly
set-cookie: app-lb=!w1WF0ptGvp1qSWAUzgOrpnnCD5SNotHmtKGR0OLseFbJQHIY1bhScwAPLLhRbd5QsRA33agIZou19Dct4X4lY1b+rFLYQw/gj0c9INBsj9ZIG+r1IDAag19U2XnlOObKe0QBzTl9cVZ8jentTSlJxUgl0q+nIZ8=; path=/; Httponly; Secure
status: 302
strict-transport-security: max-age=31536000; includeSubDomains
vary: Accept-Encoding
x-frame-options: SAMEORIGIN

IS is redirecting the request to the success URL. The card has been added successfully.

But as you can see the AJAX request fails due to cross-origin policy, because IS doesn’t set the ‘Access-Control-Allow-Origin’ on this POST result.

Although the request fails and we see an ugly error in the console, IS is still adding the card successfully. So we don’t need to worry about that.

Next we can retrieve the card ID server-side with the same token we received earlier:

In [41]: infusionsoft.CreditCardSubmissionService('requestCreditCardId', '8fa6567f-fbbe-4c8f-a739-85ebe31bfa55')
Out[41]: 
{ 'capturedVerificationCode': 'false',
 'cardType': 'Visa',
 'companyName': '',
 'contactId': '727953',
 'creditCardValidator': '',
 'email': '',
 'expirationMonth': '12',
 'expirationYear': '2020',
 'externallyUpdated': 'false',
 'id': '101073',
 'last4': '4271',
 'status': '3',
 'statusMsg': 'Validated 5/7/2018',
 'verificationCode': ',
[...]
'}

As you can see the card was added successfully. The real output included a lot more fields, such as billing address, but I redacted them, because they were not set (since we didn’t set them in the POST request).

Now the card is added and we can create and charge an order with it.

As I said, the advantage of this process is that the card information is not processed by you and your PCI scope is dramatically reduced.

Feature Request: An iframe method to add a credit card
Although this is better than the DataService.add method, it still creates a certain amount of risk for our customers and requires us IS users to have higher security standards on our websites.

The best way to add a credit card form is through an iFrame, which makes you liable for the simplest PCI compliance form SAQ A. It’s just 20 questions you have to answer.

Most other payment processor such as stripe, braintree and so on are offering this:

The only way to be liable for SAQ A with Infusionsoft is to use the hosted webforms, but I consider that a non-option in 2018…

  • The URLs are not trust worthy for our customers, because they are not on our domain
  • The pages are not attractive and not mobile responsive

And yes, I know there are services that make the forms prettier, but is it reasonable that we need expensive third party options for something so simple?

Questions & Requests to IS:

  1. Can you please properly document this?

  2. Can you please add the Access-Control-Allow-Origin header to the POST request page?

Call to action to all IS users:

PLEASE reply here, share this and contact IS requesting for them to add an iFrame option.

Further Resources:
This guide from PCI explains the PCI challenge and the different compliance forms in detail:

So we’ve always maintained local ajax calls to our own server endpoint (ie not using url so the communication stays on the same server until sent to IS) and that is how most do it. We don’t call IS via AJAX but rather let PHP using the compliant api call do it so nothing needs to then be broken up in the communication process and the only external traffic is the encrypted call to IS which already handles the requirement of not sending contact and CC information in the same call as well…ie it’s tokenized the same as you’ve described. Is there a reason you find it necessary to try to AJAX to Infusionsoft? That would be the last resort approach to me…is there a special use case?

So we’ve always maintained local ajax calls to our own server endpoint (ie not using url so the communication stays on the same server until sent to IS) and that is how most do it. We don’t call IS via AJAX but rather let PHP using the compliant api call do it so nothing needs to then be broken up in the communication process and the only external traffic is the encrypted call to IS which already handles the requirement of not sending contact and CC information in the same call as well…ie it’s tokenized the same as you’ve described. Is there a reason you find it necessary to try to AJAX to Infusionsoft? That would be the last resort approach to me…is there a special use case?

Hi John,

Why using the IS API directly is NOT PCI Compliant

There is a big difference between POSTing credit card data to your own and to IS’ servers.

The distinction is that if credit card data leaves the customer’s browser and hits one of your servers, you become a credit card processor-- even if you don’t store the details and only forward them directly through the API to Infusionsoft.

Being a “credit card processor” from a PCI viewpoint requires you to get the highest level of PCI compliance for merchants (SAQ D).

You can get the details from the “Best Practices Securing Ecommerce” document that is straight from the PCI council. It describes the API method you are using on page 17 and classifies it as liable for the highest level of PCI compliance.

Here is a quote from there; emphasis is mine:

2.5 The Application Programming Interface (API)
Merchant e-commerce systems that receive or store cardholder card data (even temporarily) require greater security controls than the previously discussed methods [iFrame; Direct Post].

In the payment methods discussed earlier in this document, risks are minimized due to payment service providers receiving cardholder data directly from the customer, reducing security responsibility for merchant systems.

The merchant system’s handling of cardholder data in the API method may require that the entire set of PCI DSS controls be applied to the merchant’s in-scope systems, people, and processes.

Even worse, according to my understanding using the API this way puts your entire company in scope for the highest level of PCI compliance and not just the one web server where you process credit card details.

So in summary, the API is PCI compliant as long as your entire company that is processing the credit card data has implemented all the required security measures to be PCI compliant, submitted the forms with proof to PCI and has been given the OK.

If you haven’t then you are not PCI compliant while using the API.

Consequences of not being PCI compliant
Merchant accounts require annual filling out of the Self-Assessment Questionnaire (SAQ). You can pick yourself which one you fill out, but roughly, as an e-commerce business you should use…

  • SAQ A (The simplest, no effort form) if you only use IS hosted order forms
  • SAQ A-EP (hard) if you use the AJAX Direct POST method I described above
  • SAQ D (hardest / impossible for most) if use the IS API on your own server

Of course you can simply fill out the simplest SAQ A that has no special requirements and most merchants will never notice or know that you are using the IS API.

But, if there is a sudden increase in fraud on credit cards that have been previously used in your business, you will become a suspect. Whether the breach actually occurred in your business or not, an investigation will be started.

The investigation will find that you did not correctly fill out the SAQ and that you have been endangering credit card data for months or years.

In the best case scenario you will get a $5,000 to $100,000 fine for each month that you continue to be not compliant and your credit card transaction fees will go up significantly.

In the worst case, your merchant account will be shut down and visa and master card may refuse to EVER work with you again.

It’s not a likely risk, but it is a possible risk with an extremely high consequence. What would it mean for your business if you couldn’t process credit cards anymore (Even if it was just for a few months while you try to sort it out)?

It would probably kill most small online businesses.

Infusionsoft’s Role In This
I love Infusionsoft and there is a reason we are using them, but I really think they have dropped the ball on this one.

Due to their lack of solutions for this, they have pushed people into non-PCI compliant ways of accepting payments.

  • They don’t provide order forms that are appropriate for 2018… The forms haven’t changed since… 2013? Are not attractive, not professional, not user-friendly, not mobile-responsive and are hosted on a dodgy domain (from a customer’s perspective).
  • Unlike most other payment processors they don’t provide a simple PCI SAQ A compliant way to integrate an order form on your own website (iFrame)
  • The only custom order form solution that somewhat makes it possible to be PCI compliant is not documented and buggy (CORS).
  • The only alternative to IS-hosted order forms that most users know of is the document server-side API that creates a huge regulatory risk for IS users and puts our customer’s credit card information at risk

How Infusionsoft can solve this

First, they should document and improve the existing Direct POST API method. This is a first step that will allow custom order forms for business who are desperate enough to go through the additional cost and effort of PCI compliance.

But it is not enough for most IS customers. Being in compliance for SAQ A-EP (Direct Post Method described in my first post) is hard.

  • You need to hire a company to do quarterly security scans and fix any vulnerabilities they might find immediately.
  • You have to fill out long and complicated questionnaire.
  • You might attract additional attention and requirements from the PCI council
  • It is (relatively) expensive… (But then again, how much money are you losing through low conversions on your IS order form? Perhaps it IS appropriate for your business and you should at least have a working option.)

That’s why most payment processors have created a simple way to allow their users to accept credit cards on their own website using an iFrame. I can’t think of any other major payment processor of the size of IS that doesn’t have a SAQ A PCI compliant order form process.

SAQ A is a simple questionnaire with about 20 questions. No further requirements needed.

IS needs to create an iFrame method that allows you to embed an iframe where credit card information is entered. The custom order form can then submit the credit card data directly to IS without it being entered on your own server. IS then adds the card to the contact and communicates back the credit card Id back to your website. You can then do an AJAX call to your own server with the credit card Id to process the rest of the order.

If you’ve ever shopped at a website that uses stripe, then you’ve probably submitted your credit card info through an iFrame method. It is literally indistinguishable from the rest of the website, but the credit card data doesn’t touch the company’s server at all.

I would be happy to help create this API and provide guidance from a customer’s perspective of what I would need. Anything that would help IS implement this.

Alternatives

There is a company that specializes in creating PCI compliant iFrame bridges between payment providers:

I received a quote that implementing Infusionsoft would cost $6,000 and 6-8 weeks. If IS ignores this request, perhaps there are more people here who would be interested in splitting the cost of this.

But I really I don’t think it is reasonable for us to pay $6,000 to a third party just because Infusionsoft has ignored the needs and ability to protect customer credit card data of their users for years.

Infusionsoft is a credit card processor by PCI DSS standards and their API is also an approved method. Prior to that point in the process, it is up to the server setup and the programmer to know what they are required to do…it’s not really that difficult or bulky to follow in compliance. So I’m not sure what other api is required?

We’ve setup many PCI compliant sites for clients (confirmed by DSS investigations post production). No issues ever. So what api functions are you really referring to?

I completely agree with you here. The problem is that the server has to meet different requirements depending on how exposed the server is to credit card information.

With the IS API you have to pass credit card info directly through your own server. And if you do that, you have to meet the highest PCI requirements (SAQ D).

This is where I disagree. According to my research (quoted directly from PCI council’s documentation) POSTing credit card data directly to your server requires you to pass the strictest of PCI requirements.

I am not saying that it is not possible to be PCI compliant with the current IS API, but you are not compliant unless you…

  • Filled out the SAQ D questionnaire with over 300 questions
  • Submitted proof that you fulfil the requirements of all 300 questions
  • Setup quarterly security scans of your clients servers by an approved scanning vendor
  • And probably a bunch of other requirements that I am not even aware off…

Perhaps you did go through all that trouble, but I can’t imagine you consider having to go through that effort, the scanning, the 300 questions “not really that difficiult”.

Perhaps you didn’t know you are subject to stricter PCI requirements and had your clients fill out the simple SAQ A form.

And perhaps the PCI investigators didn’t do any thorough digging and didn’t notice that you were POSTing credit card data to your clients servers. (And how would they if you didn’t mention it and they didn’t audit your code.)

But if that’s the case, your clients are probably currently not PCI compliant and they are bearing a (in my opinion) high risk if a breach occurs and a more thorough audit brings this to light.

It doesn’t matter that IS is PCI compliant and that you are using an approved API. You have to become PCI compliant because credit card information is hitting your servers and now you are responsible for protecting it.

So on the one hand your PCI compliance has nothing to do with IS, because it happens before IS even comes into play.

On the other hand, the only reason you are subjected to PCI compliance is, because IS does not offer a way to submit credit card information directly to IS without hitting the your server.

Technically you are responsible and not IS. But most payment processors have given their users APIs that don’t require them to take on PCI compliance. There is a reason why they’ve gone through the trouble.

I encourage you to take a look at Stripe’s security page:

Here is a screenshot from it. I’ve selected a method to submit credit card details that is equivalent to the current IS API and you can see their recommendation is that you should not use it, because it comes with too much regulatory burden.

Instead they recommend you use the API that makes use of a client-side iFrame where credit card data never touches your website or server.

Perhaps I am wrong… And I would LOVE to be proven wrong on this.

But I have studied the official documentation extensively and the only reason I am presenting this stuff here and being so intense about it, is because I am certain that I am right. I am certain its nearly impossible for the average IS using small business to take on the PCI SAQ D burden. Which means it is impossible to setup an order form that is not hosted by IS and stay PCI compliant.

But there are simple solutions that don’t require PCI compliance on our part. Other payment processors have been providing their users with for years with them and take it very seriously.

I think IS should give us the same tools. Even though most people don’t know about these requirements and for most business who do it in a non-compliant way nothing will ever happen, because nobody will ever notice.

But it would be bad enough if even just one business got destroyed because of this issue. Because IS didn’t provide an easy PCI compliant method to add cards and didn’t properly inform and educate their users about the PCI requirements if you are using their API.

That one business could be mine, or yours or one of your client’s. It’s like a god damn game of financial Russian roulette.

You are probably the most experienced and most respected member of the API community. If anyone has any pull with IS and could get them to act it is you, since clearly nobody else (not even the IS team) has any interest in this topic.

Hi @Kim_Streich,

So I didn’t reference posting to a different server. The IS api handles FROM a server to IS and you can’t just willy nilly setup a information collection without careful protocols. But, I would never suggest anyone post data on their own across origin. The projects we’ve worked on all were first verified to the task of the form collecting information. However, from that point, there were no calls by url but rather absolute path (meaning information never leaves the server) except and up to the point it is sent via the IS api or the approved merchant account provided api. The only other condition is using hosted payment pages which takes the PCI burden from the server since nothing is ever collected on the server to begin with. I honestly have not come across a situation where it was deemed necessary to collect the information and then send it to yet another server, so I’m not sure why that would be an assumption but the process is collect, keep all information local, do not store the information, use the approved tokenization provided by the merchant or credit card processor and then from their use the approved tokenized methods moving forward. I think the key separation from what you are describing is the ‘POSTing to another server’ which is completely unnecessary.

I am not talking about additional transmission outside of your own server.

As soon as credit card data comes into contact any point with your server you become liable for extensive PCI requirements (SAQ A-EP or SAQ D).

You become liable for SAQ D if you POST to your own server (irregardless of whether it is AJAX or a form submission and whether it is using an absolute path or not). That’s because credit card data passes through your server and could be collected by hackers or employees who have access to your servers.

Even if all you do is host the webform with the inputs on your own server and then even without transmitting the data to your own server, send it directly to IS (The method I described in my initial post), you are still liable for SAQ A-EP.

Both SAQ D and SAQ A-EP require you do fill out a very long questionnaire, do quarterly security scans and all kinds of other things. It’s very hard to be PCI compliant if your server is in scope for PCI purposes.

If you have a self-hosted order form where people enter credit card data and you are not filling out SAQ A-EP, or SAQ D and are not doing the security scans, you are not PCI compliant.

That’s straight from the PCI documentation for e-commerce. You can read about the API method on page 17.

The only way to not need these extended PCI requirements are:

  • Use an iFrame to submit the card details directly to IS (The feature I am requesting here)
  • Link to an IS hosted order form

If you are doing anything else, you are liable for SAQ A-EP or SAQ D with the quarterly security scans.

These regulations have changed around 2014 or 2015. So perhaps when you looked into it, it was fine to have credit card data go through your own form and server.

I really wish you were right and none of this PCI compliance nonsense was necessary for us, but all up-to-date documentation I can find on this shows me that this is not the case. At least not since around 2014.

Unfortunately, unless you can show me up-to-date documentation that there is some kind of exception to this, I believe we are all liable to super complicated PCI requirements if we use the current IS API to implement order forms.

And I will continue insist that IS should provide a method that doesn’t create a massive PCI compliance burden for us.

2 Likes

No one is debating liability. However, I’ve not indicated anything about information “passing through” anyone’s server either…because it is transient information, meaning no project I’ve ever worked on stores the data. It is simply captured to send into IS and then is expressly destroyed (per PCI regulations)…it CANNOT be stored on a server that has not been approved as a card processor service but it CAN be used (with compliant conditions) to capture that information to send to an approved processor using an approved protocol (which the IS api is). This is the role that IS plays.

But it is not difficult for a website to ensure compliance. IS provides PCI DSS approved compliance in connection to the part of the process they provide. It is not incumbent upon them to provide compliance for IS users that collect information outside of the scope of IS itself. That is our responsiblity, not theirs. The api provides a compliant method…but our websites are not their responsibility.

Using an iframe is a single method that could otherwise be instituted in a number of ways. In fact, Iframes are considered to be one of the most weakest points in any security analysis and would only be realistic if the content of the iframe were a hosted payment page…which most merchant gateways do not allow HPP’s to be place into iframes. The reason for this is because within an iframe, I can use injection to modify the host payment page. So iframes are generally and expressly prohibited by many to begin with. Since IS used to allow iframe insertion and since has changed that to not allowing them, I do not think it will be something they will be considering any time soon.

I’ve read the documentation you note many times and I have passed compliance inspections and interview every time. I did this by not expecting IS to be responsible for anything outside of their app/servers. The api is compliant and I know the requirements for using it. It’s not on IS to go beyond that, it is on the programmer to ensure that their practices are compliant up to where the api is used to communicate to their servers. Prior to that point it is not their responsibility, nor can it be. There are far to many ways that people try to do things for anyone to cover all those bases, and again, it’s not their responsibility to ensure that everyone is compliant outside of their server/apps.

However, the biggest factor is that IS is not a merchant services provider. Even their Infusionsoft Payments is actually a third party gateway run by WePay. While they may be a card processor in the strictest sense, they don’t have any services to provide a hosted payment page for. They facilitate third party merchant gateway service communications…nothing more. They themselves are not the gateway. Meaning that if you need a HPP then you would have to use the HPP from the gateway service you use that IS connects to…IS themselves, however, have nothing to do with the payment process further than facilitating the request to the third party service…on a server somewhere else. They do store the CC information, and that qualifies them as a card processor by definition, but they do not provide merchant gateway services and that means they do not have (nor should they) their own HPP.

Still, if you wish to request a feature or improvement, the place to do so would be https://infusionsoft.com/tellus/

Thanks for your detailed response John. I apologize, but I think I still don’t understand your viewpoint (although I REALLY want you to be right. I just need to understand the facts so I can implement a solution that works in our business).

To help us get on the same page, can you help me answer these questions:

1) When you setup a custom order form that uses the current IS API for your business or your clients, which PCI SAQ do you fill out and why?

My understanding is that you have to fill out the strictest SAQ D. The fact that you don’t store credit card details doesn’t matter. The only thing that matters is that credit card data hits your server, even if it is just for a moment while you pass it on to IS.

2) What steps do you take to ensure you are PCI compliant?
My understand is that it is a HUGE effort for anything except for the simple SAQ A. Because, if you are liable for SAQ A-EP or SAQ D, you will need to…

  • Use DSS compliant hosting providers and can’t use shared or managed hosting
  • Have to get quarterly security scans
  • A bunch of other complicated requirements that I’m not even clear on yet

I am hoping to find an answer of how all of that can be bypassed with the current API.

So the only concern on our level is that the client is clear on the fact that they are responsible for making their servers compliant and from our level we commit to following compliant programming practices. Since, as a vendor, our exposure is limited, the code level is all we have to ensure as long as the client is clear that we do not assume the burden of ensuring their server’s compliance. There are a number of ‘details’ that programmers must be aware of, but none of them are complicated on that level.

For example, I cannot send out information from the server over the internet without an approved process. The IS api is an approved process as it covers the security and encryption requirements. However, Infusionsoft is only a card processor and not a payment processor, which has fewer implications to it. So I have to ensure that ONLY the api is used for anything outside the server that a solution resides on. This is in the form of local calls and not url addresses, for example. You can make all the local path calls you want on the same compliant server. But if you use a url to address those calls then it will go out over the internet, unprotected, before actually reaching it’s endpoint and that would be non-compliant.

Programmers also need to be aware that they cannot store information on the server even if the server is DSS compliant, because they are not an approved processor or gateway. Again, this applies to everything involved information wise, including log files or database entries. So we just don’t store information on servers, don’t send information out anywhere except for using the IS API and we ensure that any calls that are otherwise made are only local to that server. We then ensure that all memory/disk locations that temporarily held that information before transport to IS are written over with zero’s before we deallocate that space.

There are a number of ‘little’ but important things to account for but, like I said, non of it’s overly complicated when it comes to actually doing them.

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.

https://infusionsoft.com/tellus/

I wanted to add my thoughts here.

After reading through the PDF that Kim provided (thank you for that) I see now that the method we’ve been using which I thought kept us from having to pay for quarterly audits actually does not keep us from that.

As far as I can tell, we’re taking the most efficient approach possible at the moment. We store the token in the session (and auto-generate a new token every few minutes to avoid problems when someone takes too long to fill out the form). We post directly to the Infusionsoft endpoint for adding credit cards, using a success redirect that has variables hacked into it (because IS doesn’t return any of the variables we include in the query string). Once the success url is hit we get the token from the session and find the credit card ID from that. This method feels a little like duct tape and glue to me, but it works.

I see now that this unfortunately does leave us still under SAQ A-EP which seems to be a little more intense that I think we’re prepared to handle investment wise.

Having an iframe method available from Infusionsoft would be a tremendous help for us so we could actually complete the PCI compliance forms. The only things I would mention in regards to possible iframe forms is that I would love to see the card number field and expiration fields be masked and the card type be automatically determined from the number.

I put a lot of work into customizing the form to add a new card in our member area, I’d hate to revert back to something that feels old and clunky but at the same time, falling into SAQ A is probably more important.

Take a look at OrderForms.com or NexusMerchants.com

Both of these do slightly different things.

OrderForms.com allows you to create responsive mobile ready order forms and connect to Stripe and Infusionsoft.

NexusMerchants.com allows you to use Stripe as a native merchant account with Infusionsoft orderforms and subscriptions.

I just want to thank Kim for creating this thread and highlighting this point.
Receiving payments in a professional manner with IS is the one aspect that frustrates me considerably, yet is arguably the most important function of ours and I’m guessing most businesses. Especially those who use the ecommerce addon.

I am not a developer, just coming from business operators perspective. I don’t believe I should have to resort to 3rd Party applications to achieve what I want.

@Kim_Streich Thank you so much for this post. I am new to IS but am working with a client whose developer was looking at using the API (receiving a POST to their own server first) based on SAQ-A and I was concerned that this may be wrong. Your position matched my thoughts exactly. Are you aware of any movement on this since May ? Thanks in advance

Unfortunately I am not aware of ANY progress. Not even a comment from the developers or other IS staff…

To be honest, if you are new to IS, I would encourage you to consider using a different solution.

Thanks for the update on there being no update. The customer is an IS user, I’m new to it but I’m just so glad my 30 years of development spotted a potential issue and started my investigating. I’m surprised that IS don’t even have any method of passing user details in via the api and then an iframe to allow updates. Thanks again.

Yep, I agree. It’s super standard for all other providers to offer an iframe…