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!
