PCI-DSS on messaging channels — the CPaaS buyer's checklist for scope separation

A bank or fintech evaluating a messaging platform asks "are you PCI-compliant" and gets the same useless "yes" as always. The problem is worse for messaging than for voice: a vendor can truthfully run SAQ A for its own card payments (via Stripe) and still have a messaging scope problem — the moment a customer types a card number into an SMS reply, a WhatsApp thread, or an email, that channel surface is carrying cardholder data, and nobody's SAQ A answer covered it.

This checklist runs PCI scope the way a procurement review should: the data classes that touch each channel, the platform-side transport facts to verify, the tenant-owned controls to operate per channel, and the boundary where self-assessment ends and a QSA has to confirm.

The division of responsibility is what separates a real answer from a claim, and the boundary must stay explicit. Devotel Orbit is the conduit; the scope decisions per channel are yours.

1) What PCI DSS means for messaging channels

PCI DSS (Payment Card Industry Data Security Standard) is the contractual standard the card brands require of any organization that stores, processes, or transmits cardholder data. It is proven through a Self-Assessment Questionnaire (SAQ) — the survey levels from the fully-outsourced SAQ A through the full SAQ D — and, for the largest merchants or any vendor that wants to market itself as a certified provider, through an annual Qualified Security Assessor (QSA) audit.

For a CPaaS vendor, there are two separate posture conversations:

1. The vendor's own card payments — how their platform handles the card data involved in its own billing (top-ups, saved payment methods). The honest SAQ A answer on Orbit is: cards go straight from your browser to Stripe-hosted elements; Orbit's backend never sees a primary account number and stores only Stripe tokens and display metadata.
2. Your customer data flowing through the channels — SMS, email, RCS, WhatsApp, voice. Every inbound or outbound body that mentions a card number is a scope-expanding event, because the general-purpose messaging store is not a PCI cardholder data environment (CDE).

Most vendors answer #1 and stay silent on #2. The checklist below handles both.

2) Scope per channel — what actually carries card data

The scope question is not "does the vendor encrypt things?" It is "which surfaces can possibly hold a PAN?" Enumerate them the way an acquirer would:

• Inbound SMS/WhatsApp/RCS replies and email — a customer who types a card number into a reply to your campaign has put cardholder data into your messaging store. Orbit does not redact SMS or WhatsApp bodies at ingest; the raw text is stored as received.
• Outbound bodies with PANs — a well-meaning agent who pastes a card number into an outbound SMS or email reply is the same exposure in the other direction.
• Voice DTMF capture — on the voice surface, a caller can tap a card number into a keypad. Orbit's masked-DTMF secure-payment capture pattern (the PCI Pal / Sycurio-class descoping pattern) prevents the card digits from ever landing in the call recording or transcript. This is a call-flow design choice — do not mix it into the messaging checklist.
• Payment webhooks (Stripe invoice/payment events) — these carry Stripe IDs and amounts, not card data; they are fine to log and replay.
• Link-tracking and click flows — a click-tracking redirect carries a URL; if a payment link or hosted checkout page is ever embedded in a message body, the URL itself is not card data, but the destination must be a PCI-descoped (Stripe-hosted or equivalent) page. PCI for the email channel is not the same problem as PCI for the web-link tracking destinations — the first is about text-as-received, the second is about where the URL lands.

The correct posture is categorical: the message bodies are stored as received, the sender's responsibility is to keep card numbers out of them, and Orbit handles the transport-level separation. A policy that says "we just encrypt everything" is deflection.

3) How Orbit delivers the transport facts

The platform-side facts a reviewer should verify, because they bound what scope looks like per channel:

• TLS on every endpoint — Orbit terminates TLS 1.2+ (TLS 1.3 preferred) with HSTS enabled and no mixed content. The message body travels encrypted in transit; that fact does not change, but it also does not descope the stored body — in-transit encryption and store-and-forward are different rows of the review.
• Stripe-hosted card capture for platform billing — every card flow in Orbit's billing surface is a Stripe Checkout Session or Payment Element; the backend stores tokens (pi_..., pm_...) and never a PAN.
• Voice procurement support — the voice side offers the masked-DTMF descoping pattern so a payment flow on the phone does not have to touch the recording surface at all.
• Write-time redaction vault (optional, tenant-toggled) — under Settings → Security, a tenant can enable PII redaction on AI-agent transcripts, which scrubs card numbers, phone numbers, emails, SSNs, and IP addresses from consecutive turns before they are stored. It covers agent transcripts only — not the inbox message record, and it does not back-redact earlier turns.

Run the following four checks in your vendor questionnaire; they are the checklist's operational core:

1. Verify the alphanumeric sender-ID / header registration. For the registered markets (most of Europe, much of APAC), the from on your SMS must be an approved sender-ID registration row in Orbit's compliance endpoints, or the pre-send gate blocks with SENDER_ID_NOT_REGISTERED. Unregistered alphanumeric senders are a filter-by-carrier problem that also corrupts the audit trail you would want for a PCI review. Verify before go-live, not after.
2. Verify sandbox mode while testing. Send test traffic with a dv_test_sk_* key or the org's test-mode toggle. A live credential can never resolve to sandbox, and vice versa. Do not let a test PAN-reply land in your production inbox.
3. Tokens, not raw values. Where you store anything related to payments (for example, a saved payment method for platform billing), verify that Orbit's records hold Stripe tokens and display metadata — the last four digits and brand — and nothing that looks like a PAN, CVV, or track data.
4. Segment the certification claim from the transport claim. If a vendor says "we are PCI-compliant," ask whether they mean a Level 1 RoC from a QSA (like Stripe's) or an SAQ A (like Orbit's own billing posture). The first is a certification; the second is a scope answer. Both matter, but they are not the same thing, and a vendor that cannot break them apart is not answering.

4) The exclusion list — content types that leave scope cleanly

Some content types leave PCI scope cleanly no matter how they are used. Enumerate these in your architecture note so your QSA can mark them out-of-scope. Examples: URL-only click events (the link itself, not its destination's payloads), delivery-status lifecycle events (message.sent, message.delivered, message.failed), sender-ID registration rows, payment invoices and amounts (Stripe IDs and aggregates), and non-card payment method references (bank transfer, SEPA, ACH, BACS). The full boundary is documented in the PCI DSS posture page.

5) When to escalate to a QSA

Self-assessment has a boundary. Escalate to a QSA or your acquirer's review board when any of the following is true:

• Your team processes more than 6M card transactions per year on your own rails, or wants to market itself as PCI Level 1 — that requires a RoC from a QSA.
• Your messaging scope has narrowed to something other than the fully-outsourced model (for example, a purpose-built card capture flow that is not Stripe-hosted).
• Your acquirer or one of the card brands asks for a RoC rather than an SAQ — that closes the debate by procedure.
• You have a breach or a near-miss that touched a messaging surface — that is a reviewable incident, not a training-exercise.

Orbit's posture and its SAQ A claim are documented on the PCI DSS compliance page, with the SAQ A attestation available under NDA from compliance@devotel.io. The page also lists the adjacent surfaces — voice residency and retention, the masked-DTMF secure-payment flow, and the redaction vault concept — so a reviewer can map each checklist row to a public anchor instead of transcribing a demo.

Frequently asked questions

If a customer sends a card number over inbound SMS/WhatsApp/email, is it in scope?

Yes. That message body contains cardholder data, and the general-purpose messaging store is not a PCI CDE. Orbit stores inbound bodies as received today; handle this with agent training and, where AI agents run conversations, the write-time redaction option under Settings → Security.

Is the PCI question different for email than for the tracking links it carries?

Yes. Email's PCI question is about text-as-received in the message body. Click-tracking links are a different surface: the URL is not card data, but the destination must still be descoped (Stripe-hosted or a similar PCI-aware page). Review both paths explicitly rather than assuming one covers the other.

Does Orbit claim to be "PCI-compliant" as a platform?

No, and no vendor should. Orbit's own card handling is outsourced to Stripe's PCI Level 1 environment (SAQ A scope, attestation renewed annually). On the channel side, the tenant retains the scope separation duty; Orbit provides TLS, token-only storage for its billing surface, and the docs anchors, while you map the channel scope yourself.

When do we need a QSA instead of a self-assessment?

When you breach the fully-outsourced model, pass the 6M/year threshold, or want to market a Level 1 claim — or when an acquirer, a card brand, or an incident forces it. Self-assessment ends at SAQ; certification begins at RoC.