Security & compliance

Security by architecture, not by promise.

Card data never reaches Voicent. Not encrypted in our systems, not briefly in memory — at all. There is no code path in our platform that can read a card number, because the number is never sent to us.

The core design principle

Descoping, not defence.

Most payment security pages describe how a vendor protects the card data it holds. Voicent's approach is different: we don't hold it.

When the workflow reaches the payment moment, the call hands to Twilio's PCI-certified voice platform. Twilio captures the caller's keypad digits inside its own environment and suppresses the tones so they never reach the audio stream the agent is listening to, then passes the card straight to the payment connector, which routes it to your gateway.

What comes back to Voicent is an outcome — a masked card number, a brand, an expiry, a reference, a status. Never the full number, never the CVV. This is structural rather than a policy promise: there is no code path in Voicent that can read a card number, because the number is never routed to it.

Where the card actually goes

Caller keypadDigits entered on the phone
Cardholder data environment
TwilioPCI DSS Level 1
Payment connectorPCI DSS L1 · SOC 2 · ISO 27001
Your gatewayPCI DSS Level 1
VoicentOutside the boundary

What crosses back to us: masked PAN brand expiry status reference id — never the full card number, never the CVV.

Certifications

Who holds which certificationMost vendors blur this. In a regulated vertical you'll be asked for evidence, and evidence has to name the right entity.
TwilioCaptures keypad digits inside its own voice platform
PCI DSS Level 1
Payment connectorReceives the card from Twilio, routes it to your gateway
PCI DSS Level 1SOC 2 Type 2ISO 27001
Your gatewayAuthorises the card
PCI DSS Level 1

Whichever processor you already run. The major gateways all hold Level 1 attestation; we work to the one you have rather than moving you.

VoicentOrchestrates the conversation and the compliance gate
No PCI DSSNo SOC 2No ISO 27001

We state this plainly because implying inherited certification is the most common misrepresentation in this category, and you'd find it during vendor review anyway. These standards certify the handling of cardholder data — an attestation covering an environment with no cardholder data in it is a weaker signal than the architecture that keeps it out. SOC 2 is on our roadmap, not in our marketing; we'll publish the report when we have one.

Because the digits are intercepted before reaching any of your systems, neither your application nor ours forms part of the cardholder data environment — which typically reduces a merchant's obligation to a short self-assessment. Your exact SAQ depends on your whole payment estate, not just the voice channel. Confirm it with your acquirer or a Qualified Security Assessor. Nothing here is legal or compliance advice.

What we hold, and what we don't

What Voicent stores

  • Call and session metadata — identifiers, timestamps, durations
  • Payment outcomes: masked card number, brand, expiry, amount, status, and the connector and gateway reference identifiers
  • The customer or debtor records you supply: name, contact details, account references, balances
  • Compliance audit events: disclosures made, consent given, identity verification outcomes, call attempt counts

What Voicent never stores

  • Full card numbers (PAN)
  • CVV / CVC
  • Raw audio from the capture window
  • Connector credentials for the card-submission leg — these live in Twilio's connector configuration, not on our infrastructure

How what we do hold is protected

  • All API traffic and webhooks are served over TLS; non-TLS connections are rejected
  • Data at rest is encrypted using the underlying platform's managed encryption
  • Webhook payloads are signature-verified before processing; unverified requests are dropped
  • API keys are scoped per environment, with separate sandbox and live credentials, rotatable by you without a support ticket
  • Access to production data is restricted to named accounts with individual credentials and multi-factor authentication

Reliability

A payment is never silently lost.

Security in payments includes not charging someone twice and not losing track of a transaction. The payment layer is built for the specific failure modes of a phone payment.

Idempotency throughout

Retries at every layer — the connector, our webhooks, the client — reuse the same idempotency key, so a repeated attempt returns the original result rather than creating a second charge.

Two independent result streams

The synchronous callback when the payment session ends, and the asynchronous connector webhook for outcomes that resolve after the call. Anything the gateway leaves unresolved is reconciled from the webhook, which retries until acknowledged.

Failure is never silent

A payment is treated as successful only on an explicit success status. Ambiguous or missing status is treated as a failure and surfaced, never assumed complete.

Reconciliation references

Every transaction carries your own reference alongside the connector and gateway identifiers, so a payment traces back to the call and the account it belongs to.

Regulated collections

The compliance gate is structural.

Payment capture is gated behind the checks a compliant collections call requires. Each is a branch condition in the workflow graph, not an instruction in a prompt the model might skip.

What this is, and what it isn't

This is an enforcement layer that makes the required steps structurally hard to skip, and an evidence trail for the day a call is challenged. It is not a legal opinion, it does not cover every state-level requirement, and it does not substitute for your own compliance counsel. Agencies remain responsible for their own FDCPA obligations. We built it because "the agent forgot the disclosure" is a bad failure mode, not because software can absolve a collector of liability.

Data residency

Where the data sits, and what it is never used for.

Payment data processed through the payment connector may be stored in the European Union, depending on the connector configuration. If US-only residency is a requirement for your agency, raise it during onboarding — it affects connector selection, and it's better established before integration than after.

Voicent operates on US infrastructure and processes your customer and debtor data solely on your instruction. We do not sell data, and we do not use your call content or customer records to train models.

Found something? Tell us.

If you believe you've found a security issue, email us. We acknowledge within two business days.

We don't run a paid bug bounty. We do commit to acknowledging researchers publicly with their permission, and to not pursuing legal action against good-faith research conducted without accessing other customers' data.

security@voicepay.ai

How payment capture works·The collections workflow·Privacy policy