Helcim vs Stripe: what your integration does to your SAQ
Published
Helcim and Stripe both court developers, and both publish which self-assessment questionnaire (SAQ) each way of building a checkout puts you on. Line their docs up and they match almost rung for rung: a hosted page, a card form in the processor’s iframe, your own fields, and raw card numbers through your server. So online, the form you file depends on what you build, not on which logo you pick. They part ways off the website: on staff keying phone orders, on how many questionnaires you answer, and at the counter.
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.
Swipe sideways for more vendors
| What you need | Helcim | Stripe |
|---|---|---|
| States its own PCI DSS Level 1 statusReq. 12.8.4 | Yes | Yes |
| Publishes which SAQ each integration lands onSAQ eligibility | Yes | Yes |
| Card form in its iframe that its docs map to SAQ ASAQ A | Yes | Yes |
| Mobile SDK its docs map to SAQ ASAQ A | Ask the vendor | Yes |
| Full card numbers by API only after a compliance reviewSAQ D | Yes | Yes |
| Folds several of its products into one questionnaireValidation | Yes | No |
| Web terminal it offers for routine phone ordersSAQ C-VT | Yes | No |
| Phone orders without card data on your sideSAQ A (MOTO) | Yes | Yes |
| Validated P2PE listing on PCI SSCSAQ P2PE | No | Yes |
| Runs your quarterly ASV scansReq. 11.3.2 | Ask the vendor | No |
| Makes your business PCI compliant by itselfReq. 12.8.1 | No | No |
The integration dial: same rungs, same forms
The more of the card form your own code builds, the more of the standard lands on you. Slide the dial to see where the card number travels at each rung, which product each provider puts there, and the form its docs name. The Council’s count of requirements sits under each rung.
How much of the card form do you build?
Slide or tap a rung. It starts on the processor's iframe.
The processor's card form sits in an iframe on your page
1. Your web page
Can affect the form
Hosts the frame and its scripts
2. Your server
No card data
Gets a token only
3. Processor
Handles the card
Serves the fields in the frame
Helcim names
HelcimPay.js payment modal
FormSAQ A
FiledHelcim's dashboard questionnaire
“Because we render the payment modal in an iFrame on your website, sensitive credit card details never touch your website or server.”
Stripe names
Elements
FormSAQ A
FiledStripe's PCI wizard
Stripe.js and Elements “host all card data collection inputs within an iframe served from Stripe’s domain (not yours).”
Council count: Processor iframe on your page27 requirements
The step that matters most is from the second rung to the third. If any element of the payment page delivered to the shopper’s browser comes from the merchant’s own website, SAQ A does not apply; SAQ A-EP may. That is why Helcim.js and Stripe.js v2 both land on SAQ A-EP, while HelcimPay.js and Elements stay on SAQ A. SAQ A still asks something of the iframe rung: the merchant confirms “that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s),” and 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 both, and the guide to the SAQ types covers the rest.
Stripe’s map has a rung Helcim’s lacks: its Mobile SDK, which it maps to SAQ A when you use only the UI components from its official SDKs. Helcim’s PCI pages name no mobile SDK, so an in-app checkout is a question for Helcim. The same rungs on a gateway-only provider are in Authorize.net vs Stripe.
The top rung is locked at both
Neither provider lets you send raw card numbers to its API on a whim. Both switch that off until they have seen your compliance paperwork, and both ask again every year. Helcim’s page spells out more of its gate.
Helcim: full card numbers
By defaultRefused with an error
You sendA technical overview or diagram, and an AOC showing SAQ D
Reviewed byHelcim's cyber-security team and CTO
Typical wait5–10 business days
Each yearHelcim asks for the latest SAQ D
“Failure to provide this updated documentation in a timely manner may result in full card number processing being disabled for your integration.”
Stripe: raw card data APIs
To turn onContact Stripe support
You sendA current SAQ D, or a Level 1 onsite AOC
Reviewed byNot named on the page
Typical waitNot stated
Each yearFresh documentation
“The simplest way for you to be PCI compliant is to never see, or have access to, card data.” A business that fully outsources card handling may send an SAQ A instead, on Stripe’s conditions.
Keyed and phone orders: where they part
Here they read differently. Helcim describes its Virtual Terminal as “like having a cash register in your web browser,” for “payments taken over the phone,” and maps it to SAQ C-VT. Stripe maps manual entry in its Dashboard to SAQ C-VT too, but calls it “possible for exceptional circumstances only, not routine payment processing.” For phone orders it describes third-party pay connectors that take the card by keypad or voice, where “the user should not have access to the card data while it is being presented over the phone.”
Swipe sideways for both providers
| Phone-order route | Helcim | Stripe |
|---|---|---|
| You send a payment link; the customer types the cardCouncil: SAQ A | Payment Links: SAQ A, listed for “mail/phone order” | Not in its SAQ table. Ask Stripe which form a link order fits. |
| Staff key the card into the processor's web terminalCouncil: SAQ C-VT | Virtual Terminal: SAQ C-VT, made for “payments taken over the phone” | Dashboard: SAQ C-VT, “for exceptional circumstances only” |
| A pay connector takes the card by keypad or voiceCouncil: SAQ A | Not covered on its PCI pages. Ask Helcim. | SAQ A, where “the user should not have access to the card data” |
| Card numbers kept on your own systemsCouncil: SAQ D | SAQ D, its row for “electronic storage of cardholder data” | SAQ D, for “electronic storage of cardholder data within their environment” |
Filing each year
Both providers work out your form for you. They differ on what happens when you use several of their products at once, and on where the harder forms go.
Filing with Helcim
Picks your formFrom the products you have recently used
Several productsOne combined questionnaire, several SAQ reports
Answered inThe dashboard for A, C and C-VT; an upload for A-EP and D
First deadlineGenerally 90 days from approval
learn.helcim.com/docs/complete-pci-saq
Filing with Stripe
Picks your formIts wizard reads your integration method
Several methodsCompliance shown separately for each
Answered inThe PCI wizard, or an upload in the PCI Dashboard
First deadlineAsk the vendor
docs.stripe.com/security, stripe.com/guides/pci-compliance
Either way the work on your side is the same: keep each provider on your list of service providers and check its compliance status at least once every 12 months (Requirement 12.8.4). If you also take cards at a counter, the readers bring their own form. Stripe Terminal has a solution on the Council’s P2PE list and Helcim does not; Stripe vs Square covers that side.
Each provider on its own
Helcim
Payment processor with a developer API: hosted pages and Payment Links, the HelcimPay.js modal, Helcim.js fields, a Virtual Terminal and its own readers.
FitsBusinesses that take cards online, at a counter and by phone, and want their Helcim products in one questionnaire
States its own Level 1 statusYes
Maps each integration to an SAQYes
Mobile SDK mapped to SAQ AAsk the vendor
Not stated on their site when read on 2026-10-22.
P2PE solution on the Council's listNo
Runs your ASV scansAsk the vendor
Not stated on their site when read on 2026-10-22.
“Helcim is a PCI Level 1 Service Provider,” its security page says, and “We do not store CVV, PIN, EMV, or mag data.” Its developer docs put the choice plainly: HelcimPay.js “will provide the most reduced PCI compliance scope available,” Helcim.js less, and full card numbers the least.
Its SAQ table lists the full card number API as “Legacy,” and the API refuses card numbers unless Helcim has approved you.
VerdictDaily keyed phone orders, and one combined yearly questionnaire
Stripe
Payment processor and gateway: Checkout, Elements, mobile SDKs, Terminal readers, a Dashboard and a raw card API.
FitsDevelopers building web or app checkouts who want the SAQ named for each integration
States its own Level 1 statusYes
Maps each integration to an SAQYes
Mobile SDK mapped to SAQ AYes
P2PE solution on the Council's listYes
Runs your ASV scansNo
Stripe says “A PCI-certified auditor evaluated Stripe and certified us to PCI Service Provider Level 1.” It adds: “We analyze the user’s integration method and dynamically inform them of which PCI validation form to use.”
Its guide maps the Mobile SDK to SAQ A when you use only its official UI components, and warns that “writing your own code to handle card information” can make you “ineligible for an SAQ A.” Asked “Does Stripe provide ASV scanning?”, its FAQ answers “No.”
VerdictA checkout inside a mobile app, and phone orders through a pay connector
Questions developers and merchants ask
Is Helcim or Stripe more PCI compliant?
Both state PCI DSS Level 1 status as service providers, and neither makes your business compliant by itself: “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.” What changes your workload is the integration you build, and on that they line up rung for rung.
Do HelcimPay.js and Stripe Elements both keep me on SAQ A?
Both providers map them to SAQ A. The Council adds its own test: “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 SAQ A guide covers that second line.
Can my staff take phone orders every day in Stripe's Dashboard?
Stripe maps Dashboard entry to SAQ C-VT but says manual card payments there are “possible for exceptional circumstances only, not routine payment processing.” Its phone-order section describes third-party pay connectors instead, which it maps to SAQ A. Helcim describes its Virtual Terminal for keyed cards, including “payments taken over the phone,” and maps it to SAQ C-VT. Either way, SAQ C-VT expects “an isolated computing device and a securely connected web browser.” The phone payments compare covers pay connectors.
Do I still need ASV scans on SAQ A?
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. Stripe’s FAQ says it does not provide ASV scanning; Helcim’s help page says “Your SAQ will specify if this is needed.” Plan on an approved vendor: what an ASV scan covers.
I use Helcim at the counter and Stripe online. How many questionnaires?
Each way you take cards is assessed for what it is, and each provider asks about its own products. Helcim folds its own products into one questionnaire; Stripe says that with several of its methods “you must illustrate compliance for them separately.” Before you start an SAQ, confirm with the organization you submit it to (usually your acquirer, the merchant bank) that you are eligible for it. The SAQ type finder sorts a mixed setup.
Sources
- Helcim: Security (helcim.com), read on 2026-10-22
- Helcim developer docs: Understanding PCI Compliance (devdocs.helcim.com), read on 2026-10-22
- Helcim developer docs: Processing with Full Card Numbers (devdocs.helcim.com), read on 2026-10-22
- Helcim developer docs: Overview of HelcimPay.js (devdocs.helcim.com), read on 2026-10-22
- Helcim developer docs: Overview of Helcim.js (devdocs.helcim.com), read on 2026-10-22
- Helcim help: Manually submitting your PCI compliance (learn.helcim.com), read on 2026-10-22
- Helcim help: Completing your PCI questionnaire (learn.helcim.com), read on 2026-10-22
- Helcim help: What is the Helcim Virtual Terminal? (learn.helcim.com), read on 2026-10-22
- Stripe: Security at Stripe (docs.stripe.com), read on 2026-10-22
- Stripe: A guide to PCI compliance (stripe.com), read on 2026-10-22
- Stripe Support: Enabling access to raw card data APIs (support.stripe.com), read on 2026-10-22
- Stripe Support: PCI compliance FAQ (support.stripe.com), read on 2026-10-22
- PCI SSC: SAQ Instructions and Guidelines, PCI DSS v4.0.1 r1 (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: Prioritized Approach Tool for PCI DSS v4.0.1 (Req. 11.3.2, 12.8.1, 12.8.4) (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: Validated P2PE Solutions list (pcisecuritystandards.org), read on 2026-10-22