Every payments company says they’re “secure.” Many say they’re “PCI compliant.” The problem is: most can’t prove it, and when something goes wrong, you (the merchant) eat the damage—financially and reputationally. (hightechpayments.com)

If you’re here because you searched “Luis Requejo Miami,” understand the standard: you don’t trust marketing. You trust documentation and technical clarity.

This article is your checklist to separate legitimate providers from storefronts.

The uncomfortable baseline: “PCI compliant” means nothing without evidence

HighTech’s own guidance is blunt: without documentation, a PCI claim is worthless—and real PCI validation typically involves artifacts like an AOC, ROC, SAQ (depending on architecture), quarterly ASV scans, and penetration testing documentation.

What “proof” looks like (in plain English)

A key proof document is the Attestation of Compliance (AOC)—a formal declaration that an organization complies with PCI DSS. Stripe explains that the AOC summarizes how the assessment was done and who validated it (QSA audit or self-assessment path depending on merchant level), and it’s the document you share with banks/partners as evidence. (Stripe)

If a provider can’t produce proof, you should assume one of two things:

1. They’re not compliant, or
2. They’re reselling someone else’s compliant system and don’t control anything important.

Either way: your risk goes up.

Step 1: Demand the documents (don’t accept vibes)

Ask for these specifically:

A) PCI AOC (Attestation of Compliance)

HighTech calls the AOC the “ultimate test” and says legitimate providers proactively supply it with details like attestation date, audit firm name, scope, and level.
Stripe also outlines that the AOC is the formal declaration and must be renewed (commonly yearly).

What you ask:

“Please provide your PCI-DSS Attestation of Compliance (AOC) and the scope.”

B) ROC / SAQ (depending on architecture)

HighTech lists ROC and SAQ as part of real compliance evidence (architecture-dependent).

C) Quarterly ASV scans + penetration testing documentation

Also explicitly listed by HighTech as evidence, not optional marketing.

If they respond with a generic FAQ page: that is not compliance. That is deflection.

Step 2: Verify who actually controls the infrastructure (most “providers” don’t)

HighTech highlights that many “processors” are really ISOs/agents/resellers/white-label partners who don’t store/process/transmit card data themselves—they piggyback on someone upstream.

So ask these questions and require immediate answers:

• Who actually handles the card data?
• Who owns the vault?
• Who stores PANs?
• Who encrypts/decrypts the data?
• Who controls tokenization?

If they can’t answer instantly, they’re not the processor. They’re a storefront.

Step 3: Encryption claims are cheap—technical specifics are what matter

HighTech calls out the industry’s favorite nonsense phrases (“bank-level security,” “256-bit encryption,” etc.) and says real encryption standards must include details such as encryption method, encryption at rest and in transit, TLS version, key management policies, tokenization method, vault architecture, and HSM usage.

Your checklist: the minimum acceptable answer includes

• Encryption at rest + in transit
• TLS version (they should be at least 1.2; ideally 1.3)
• Key management and rotation policy
• Tokenization approach and vault design
• Whether HSMs are used for key material

If they can’t explain these, assume the “security” is mostly marketing.

Step 4: Tokenization isn’t a buzzword—vault ownership is the key question

HighTech is direct: tokenization is mandatory in modern setups, but many payment companies outsource tokenization to upstream platforms.

So don’t ask “do you tokenize?”—everyone says yes. Ask:

• Do you own the token vault?
• Who generates the token?
• Who controls token lifecycle and retrieval?
• What token type is it (single-use, multi-use, card-on-file)?

If they can’t answer, they don’t own it—they’re renting it.

Step 5: Data residency & storage—if they can’t answer, you’re gambling

HighTech points out that legitimate providers should be able to answer where data is stored (region, cloud vs on-prem, isolation practices, redundancy/failover). If they can’t, your customers’ data could be stored in unknown places under weak controls.

This is not paranoia. It’s basic due diligence.

Step 6: No security whitepaper = no seriousness

HighTech states that any company handling payment data should have a security whitepaper and lists what it should include: PCI level, encryption architecture, tokenization strategy, network segmentation, intrusion detection, fraud prevention systems, key rotation policies, code review practices, security team structure, and physical controls.

If there’s no whitepaper (or they refuse to share one), you’re dealing with an immature provider.

Step 7: SOC 2 is not optional if they touch sensitive data

HighTech argues that providers touching card data should be able to demonstrate SOC 2 (Type I/Type II, scope, summary letter). If they can’t, internal controls are questionable.

SOC 2 isn’t “PCI,” but it’s a strong signal of operational discipline.

Step 8: Fraud prevention ≠ security (and weak providers confuse them)

HighTech separates “security” from “fraud prevention” and says weak providers often pretend basic checks (AVS/CVV/IP blocklists/simple rules) equal a real fraud stack.

A serious fraud stack includes items like device fingerprinting, 3DS 2.0, real-time risk modeling, velocity monitoring, BIN intelligence, geolocation risk profiling, and more.

If your provider lacks these, expect chargebacks—and expect them to blame you.

The “No Excuses” PCI Decision Rule (use this to protect yourself)

HighTech’s conclusion is blunt: if a provider hides documentation, avoids technical questions, refuses to give an AOC, can’t explain encryption/tokenization, lacks a security team, can’t demonstrate SOC 2, or won’t provide a whitepaper—then they’re not PCI compliant no matter what their website claims.

My simplified rule:

If they won’t show evidence, walk away.

Quick Merchant Action Plan (copy/paste into your next vendor call)

1. Send: “Please share your PCI AOC and scope.”
2. Ask: “Who owns the token vault and controls token lifecycle?”
3. Ask: “What TLS version and key management practices do you use?”
4. Request: security whitepaper + SOC 2 summary and scope.
5. Confirm: where data is stored and how it’s isolated and replicated.

If they resist any step, you just saved yourself from a future disaster.