PCI Compliance Scanner
Scan your payment code
0 security rules across 7 languages. Every finding explained in plain English with a copy-paste fix.
1
Where are you in your integration?
›
Just starting
Haven't chosen a processor yet
Mid-build
Actively writing the integration
Live in production
Already processing payments
You're at the right starting point — but not this page. Compare processors first to find the best fit for your SaaS, understand true costs, and get a personalised integration checklist.
Compare processors →2
How are you handling card data?
›
Question 1 of 3 — PCI SAQ Classification
Hosted fields / Stripe ElementsiThe card form lives on your processor's servers, not yours. You never see raw card numbers. Examples: Stripe Elements, Adyen Drop-in, Checkout.com Frames. Lowest PCI scope.
e.g. Stripe Elements — card input hosted by your processor
Redirect to processoriCustomers leave your site to enter card details on the processor's payment page, then return. Examples: PayPal redirect, some Stripe Checkout flows. Very low PCI scope.
Customer leaves your site to complete payment on the processor's hosted page
Pass-through (your JavaScript collects it)iYour page hosts the card form, but the card data is sent straight from the browser to the processor — it never lands on your server. Example: tokenizing JS without hosted Elements. Moderate PCI scope (often SAQ A-EP or C).
Your page has the card form but sends data directly to the processor
Your own card form (direct API)iYou built a custom form that collects card details. Card data touches your servers before being sent to the processor. Highest PCI scope — SAQ D territory.
Card data passes through or is processed on my backend
3
Are you storing any card data?
›
Question 2 of 3 — PCI SAQ Classification
No — we don't store card data
No card numbers, CVVs, or raw card data in our database
Yes — card data is stored in our system
Card numbers or other cardholder data is persisted in our database
4
Have you registered as a Payment Facilitator with your processor?
›
Question 3 of 3 — PCI SAQ Classification
No — I use Stripe, Adyen, or similar to collect payments
Most SaaS companies. Your processor manages merchant accounts and compliance. You are their customer.
Yes — I'm a registered PayFac
You've completed formal PayFac registration with your processor. You underwrite your own sub-merchants and take on significantly more compliance and liability.
Not sure
Read what a PayFac registration actually involves
A PayFac registration is a formal process where your processor approves you to onboard and underwrite other businesses as sub-merchants. If you haven't gone through a specific approval process for this, you're not a PayFac — so we'll treat you as a standard merchant for your SAQ result.
SAQ A
Smartriarch determines your likely SAQ level based on your answers. This is a guide only — confirm your SAQ classification with a qualified QSA before submitting to your acquiring bank.
What should I upload?
Upload the file that contains your payment processor API calls — not your entire codebase.
›
Common file locations by stack
Node.js / Express
routes/payments.js · controllers/payment.js · api/stripe.js
Next.js
app/api/payment-intent/route.ts · pages/api/stripe.js
Python / Django
payments/views.py · apps/payments/stripe.py
Python / Flask
payments.py · routes/payment.py
Ruby on Rails
app/controllers/payments_controller.rb
PHP / Laravel
app/Http/Controllers/PaymentController.php
Java
PaymentService.java · StripeController.java
Go
handlers/payment.go · internal/payments/stripe.go
What NOT to upload
Your entire codebase or repo zip
.env files or config files with real credentials
Database files or migration files
Frontend-only files with no API calls
Scanning a full payment module? Upload a .zip
Zip your app/payments/ directory and upload it — Smartriarch scans every relevant file inside (
.py · .js · .ts · .tsx · .rb · .java · .go · .php) and shows you consolidated results grouped by file. We skip dependencies, tests, and migrations automatically.
Not sure what to scan? Start with the file that contains your payment processor API calls — for example, your Stripe, Adyen, or Authorize.net integration file. You can always scan multiple files separately.
5
Upload your code to scan
›
Drop a file or .zip archive here
or click to browse
.py · .js · .ts · .tsx · .rb · .java · .go · .php · .zip (up to 50MB)
📦 Zip your payment directory for a full codebase scan — we'll scan every relevant file inside.
Paste your code
Filename (optional)
Which processor does this code integrate with?
Coverage: US and Canada · International coming soon
Takes 30–60 seconds
🔒 0 rules — PCI core plus processor-specific checks for 17 processors: Stripe, Adyen, Checkout.com, Worldpay, Fiserv / Clover, Braintree, Square, Authorize.net, Finix, Nuvei, Global Payments GP-API, Global Payments GP-ECOM, Rainforest, Stax, Payoneer, Airwallex, Mollie
✨ AI-powered — every finding explained in plain English with a copy-paste fix
📄 PDF report — exportable compliance report for your records
Coverage
0
detection rules across 7 languages
Python · JavaScript · TypeScript · Ruby · PHP · Java · Go
PCI DSS 4.0 requirement mapping on every finding
AI plain-English explanations + copy-paste fixes
PDF compliance report download
Real-world results
19
total findings caught across 5 validated codebases
Most common violation
Missing idempotency keys on payment intent calls
Every scan makes Smartriarch smarter for everyone.
After scanning
Monitor changes automatically →
Stay ahead of API changes and PCI SSC updates.
Stay ahead automatically.
Monitor processor API changes and PCI updates. Smartriarch watches changelog and rule-set drift so you don't have to.