Helcim vs Square: how much PCI work each leaves a small business

The PCI side, row by row

Each row is a question the standard makes you answer about a provider, with the requirement or form it maps to. “Ask the vendor” means the provider’s own pages did not say when we read them on 2026-10-22.

What each one tells you to file

Helcim publishes a table that ties each of its products to an SAQ type, and its system “automatically determines the Self-Assessment Questionnaire (SAQ) type(s) that apply to you.” Square answers the same question with a statement instead.

Helcim’s map makes your annual job visible: you can see which form each new product adds before you switch it on. Square’s answer is lighter on paper but leaves the reading to you, and Requirement 12.8.1 still says a compliant provider does not “remove the entity’s responsibility for its own PCI DSS compliance.” Whichever you choose, the SAQ type finder checks the form against how you actually take cards.

Online: HelcimPay.js and the Web Payments SDK

HelcimPay.js renders “the payment modal within an iFrame overlaid on any website or application that has been whitelisted in your Helcim account, so that your customers can process payments securely without payment details touching your website or server.” Helcim’s developer docs say that with it “you would only need to complete the annual PCI compliance SAQ-A questionnaire.” Its older Helcim.js is different: it “uses HTML input fields,” so card details “technically touch your website,” and Helcim points you to SAQ A-EP.

Square’s Web Payments SDK “produces a secure single-use payment token that your application web client sends to your backend,” so your backend handles a token rather than the card number (the tokenization guide explains why that matters). Square’s Content Security Policy page ties the SDK’s setup to the latest PCI DSS requirements and lists frames from web.squarecdn.com, Square’s own domain. What it does not do is name an SAQ. Ask Square which form your checkout fits.

The Council’s test is the same for both. SAQ A needs “All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor,” and the merchant must confirm “that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” The Council counts 27 requirements for a processor iframe on your page and 139 for SAQ A-EP. SAQ A for v4.x includes Requirements 11.3.2 and 11.3.2.1 (external vulnerability scans) for merchants whose pages redirect to, or embed, a processor’s payment page. The SAQ A guide walks through that last line.

At the counter: readers and P2PE

Helcim maps its POS app with the Helcim Smart Terminal or Card Reader to SAQ C: “Merchants with payment application systems connected to the Internet, no electronic account data storage,” at a single store not connected to other premises. Square says its integrated system “provides end-to-end encryption for every transaction at the point of swipe, dip, or tap and tokenizes data once it reaches our servers,” and asks for no questionnaire on one condition: “Provided you use Square for all storage, processing, and transmission of your customers’ card data.”

Encryption is not a P2PE listing. A PCI-listed P2PE solution “can significantly help to reduce the PCI DSS validation effort of a merchant’s cardholder data environment,” and only a solution on the Council’s list qualifies a merchant for SAQ P2PE. On 2026-10-22 neither Helcim nor Square had one. If the shortest counter questionnaire matters most, the listed options are in Clover vs Toast, and the P2PE guide explains the list.

Keyed payments: both virtual terminals

Both providers sell a virtual terminal for phone, mail and invoice payments. Helcim’s is “like having a cash register in your web browser,” and its docs map it to SAQ C-VT. Square Virtual Terminal “turns your computer into a credit card terminal,” where you “can manually enter your customer’s card number, expiration date, and CVV.” Square names no SAQ for it.

SAQ C-VT is for “Merchants that manually enter payment account data a single transaction at a time via a keyboard into a PCI DSS validated and compliant third-party virtual payment terminal solution, with an isolated computing device and a securely connected web browser.” Most of its criteria are about your computer, not the provider, so they decide the form whichever terminal you pick. Check yours:

Each provider on its own

What their PCI pages promise

Both providers make a strong claim about your compliance on their own pages. Read side by side with the standard, each one describes the provider’s half of the job.

“The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.”

PCI DSS v4.0.1, Requirement 12.8.1, applicability notes

Helcim’s sentence names Helcim.js, which its own developer docs place on SAQ A-EP, so “fully compliant” depends on which tool you use. Both claims describe the provider’s systems; neither covers the computer, inbox or paper file on your side. Requirement 12.8.4 asks you to check each provider’s compliance status at least once every 12 months. The PCI scope checker finds the parts that stay yours.

Questions merchants ask