Does using Accept.js require PCI compliance?

[kofhearts]

Currently our company uses the simple SIM payment method provided by Authorize.net.  This has been serving our needs but there is a serious problem that we encounter now and again "The script timeout error". The frequency of occurrence has increased over time. When script timeout occurs, we need to notify the user that the transaction didnt get through and we ask the user to re-register again. This has provided for poor user experience. We want to change this. 

Our company is also concerned about PCI compliance. At the best our company doesn't want to deal with PCI compliance. With the SIM method, we didnt have to deal with PCI compliance since the request went directly to the authorize.net servers. Authorize.net has recently launched a new payment method via the Accept.js and from the previous forum question, i was told that Accept.js is the recommended method of payment integration. So, my question is does using Accept.js require our company to be PCI compliant or does it not require PCI compliance at all? If the latter is the case, we will be happy to switch to Accept.js from SIM. I assume with the switch to Accept.js, we no longer have to face the annoying script time out error caused by relay response urls. I appreciate any help! Thanks!

[Aaron]

Hi @kofhearts,

To answer this question completely in a way that would be useful to others, it first helps to explain what "PCI compliance" even means. I apologize in advance for the length of this post, but if you hang out here for a while, you'll quickly learn that I'm pathologically incapable of using just one paragraph when several would do. :)

Ultimately, any type of payment processing needs to be compliant with PCI standards, meaning those security standards set out by the card brands working together as the PCI (Payment Card Industry) Council. Those security standards are codified as something called the PCI-DSS (Payment Card Industry Data Security Standard). Any card processing is subject to the requirements of the PCI-DSS. That means even the local deli using a dial-up terminal or the dentist using no terminal at all but just an old-fashioned "knuckle scraper" imprinter.

So what does that mean? Does it mean that anyone using a hosted payment form like SIM or even anyone using the "knuckle scraper" has the same requirements for server configuration and auditing and compliance testing and network scanning and so forth? No, thankfully it does not. There are different levels specified in the standard for different types of transaction processing. Merchants or entities that see or store card numbers in an electronic form will have a different set of requirements than merchants who are just having people pass through their site to make payments or merchants just handling physical cards.

At the most basic level, everyone taking payment card information in any form needs to make sure that they're following security best practices. In your case, you're not storing or even seeing the card number, so PCI-DSS requirements about card number storage don't apply. However, if your web site wasn't secure, you're still creating a potential breach. For example, let's say you left a default password in place for the actual web hosting and someone accessed your files. In that case, they could modify the script or page that hands off transactions to the SIM form and display their own form first to ask your customers for their card numbers, then transmit them to their secret hacker lair. They didn't technically steal any card information directly from you, but they hacked your payment infrastructure to steal that data from your customers. Ultimately it would be your responsibility for leaving your site wide open for them to do that. Compliance with PCI-DSS standards would prevent or minimize that risk.

So, at the basic level of a merchant that has a web site, takes payments, but doesn't do any of the actual processing or ever see the card number, there's still this basic set of requirements they have to meet. Who enforces this? Who checks to see if they meet these requirements? Generally all PCI compliance checking is delegated to the card brands (Visa, MasterCard, etc), and specific requirements are enforced in the contracts the merchant would have with their merchant account provider.

It's that merchant account provider or bank that would do any compliance checking required. At this basic level of processing where they merchant doesn't see the card info, the merchant is generally only responsible to complete and submit a Self-Assessment Questionnaire (SAQ) to certify that they're aware of each of the security requirements and that they're compliant with all of them.

(In many jurisdictions, these standards or similar concepts are actually codified into law. That doesn't necessarily mean there are governments out there checking your PCI compliance paperwork, but it does mean that in the event of a breach, parties not following these standards could be more easily held liable for damages, fines, and penalties.)

Anybody dealing with electronic transactions should be familiar with at least the basics of PCI-DSS compliance. For more information, there are lots of resources at https://www.pcisecuritystandards.org including background on the SAQ at https://www.pcisecuritystandards.org/pci_security/completing_self_assessment

In your particular case, you're already using a solution (SIM) that probably makes your list of requirements for PCI compliance relatively small. You (or the merchant if that's not you) fills out an SAQ and submits it to your merchant account provider. (I don't know all the specifics of your application or configuration, but I'm assuming that you're not doing anything else in your processing that would expose you to a higher set of requirements.)

You'd like to move away from SIM, but don't want to move to anything that increases your PCI burden. That's totally understandable and desirable, and to meet your needs, we've created the "Accept" suite of features. All of our API features with the "Accept" name are designed to limit the scope of the data that your application is exposed to, and thus limiting your PCI compliance requirements.

Accept.js specifically is one tool that does this, designed specifically for a developer who wants full control over the payment form and doesn't want to redirect to a web page or load another web page in a lightbox or iframe over their own. Accept.js is a script that takes the card information entered into your payment form and returns a payment "nonce" (a one time use token representing the card number) that you submit with the rest of the form. It's ideal for use in situations where loading any other form for the payment information would be impractical. Because the actual card information is taken by a script running in the customer's browser, and sent to Authorize.Net directly by the browser, your server will never see that actual card information.

For those developers already using SIM, a closer analog to what they've been using is "Accept Hosted". This is a hosted payment form that you can redirect to or pull up in an iframe or lightbox. It's essentially the modern, more flexible replacement for SIM. That's probably the feature that I'd look into first if I were in your situation.

The notifications to you should definitely be more reliable with Accept Hosted, and as an additional form of notification, we've also implemented support for Webhooks to send notifications of many different event types.

Hopefully this clears up some of the possible confusion. We can't make any sort of blanket statement like "Use this feature and you don't have to be PCI compliant!", because, well... everyone has to be PCI compliant. And even with the Accept features, we can't really give specific guidance on which of the Self-Assessment Questionnaires would apply, since a lot of that might depend on how you use the feature or what else you're doing within the app. However, I can say that if you're using Accept Hosted to do the same thing that you're using SIM for, you should be subject to the same low level of compliance requirements using whichever Self-Assessment Questionnaire you were using before.

If any of this is unclear, or you need any more help, let me know!

[kofhearts]

Thanks for taking time to address this issue and thanks for providing an alternative. I will make a switch to "Accept Hosted" method. I have two questions, however.

1) SIM uses relay response urls so the problem we have been facing are of script timeouts. Does accept hosted also use relay response and have script timeout errors?

2) I have not found a convinient way using SIM to display the error when the user mistypes credit card information in checkout page. Since the requst leaves the system, i couldnt use ajax to just send the payment in the same window and show the error message instantly highlighting the fields with errors. Is this possible using the new "Accept Hosted" method? In short, i want to use ajax to send the payment and if an error occurs, i want to show the error instantly with fields highlighted in the credit card page. This also prevents having the user to type again all credit card information rather than only those fields that had errors. 

I appreciate your help and taking time to help me with this issue. Thanks a lot!

[Aaron]

Hi @kofhearts,

1. No Relay Response in Accept Hosted.

2. The payment form in Accept Hosted does a lot of checking interactively. If a customer enters a card number that doesn't pass the Luhn check or enters an expiration date out of range for example, the form alerts them immediately. ZIP codes automatically pull up city and state. And when there's an actual decline, the customer is left on the form with the opportunity to change their input. So, the form may work for you as is. You may want to play with it and see if it meets all of your needs.

However, while the appearance of the form is somewhat customizable, the behavior with regards to error checking is not. If there's any additional or different error handling that you want to do, you really might need to do your own form, at which point Accept.js is your solution.

[AmberE]

Hello Aaron,

Your first response was great and detailed, but I am still unclear if accept js use qualifies for SAQ A (like SIM did) or SAQ AEP, in the description you mentioned accept is good for merchants wanting to move away from SIM but not add to their PCI Complaince. I think I am hung up on where it says the card number is entered into the payment form before returning a nonce thats then passed to Auth.net.  Does that mean the merchants ecommerce site should go through the same as direct post/javascript merchants have to due to the site producing the payment form, because if the merchant site producing the form was compromised it could cause an issue, thus making scanning required?   (for this question example is I am only ecommerce accepting thru website using accept js, no phone orders)

[Aaron]

Hi @AmberE,

I'm afraid I can't really answer specific questions on which SAQ would be applicable, since a lot of that is dependent on your own setup. You'd really have to have your assessor give you that recommendation.

What I can say is that Accept.js lets the browser do the work of exchanging the payment data for the single-use token. That means your server doesn't get the payment data if everything's working right. However, if your server is compromised, that page that runs the Accept.js script could be rewritten to send the payment data somewhere else.

Because there's definitely a level of security and controls required on your side to keep that from happening, I'd lean towards the more rigorous SAQ (SAQ-A-EP) if in doubt.

If you want something more like SIM, where the actual payment form is hosted on our side, you can look into our Accept Hosted forms. I can't go as far as specifying what SAQ is appropriate for the usage of Accept Hosted, but it works the same way as SIM where a payment form is either embedded in an iframe or redirected to.