Payments + PCI

Vorel never touches your customer’s card. When a Vorel voice or chat agent needs to collect payment from your customer (a restaurant booking deposit, a salon appointment confirmation, an auto-service intake), the agent does not read card numbers, accept DTMF keystrokes, or ask the customer to type their card into any Vorel-hosted form. Instead, the agent generates a single-use hosted-checkout session with a PCI-compliant payment provider, texts your customer the provider’s secure hosted URL, and waits for the provider’s webhook to confirm the payment. Vorel receives only the provider’s session reference and an outcome enum; the customer’s primary account number (PAN), expiry date, and CVC never traverse Vorel infrastructure. This page explains the PCI scope (and why it is SAQ-A, not PCI Level 1), the SMS-first user experience, the per-pack timeouts, the three architecturally hard-forbidden builds, and how the CI lint gate enforces these commitments in code.

​

The architectural commitment

Vorel’s payment-collection architecture is sealed by an internal, audited architecture decision record (PCI vault-redirect to a PCI-compliant payment provider). The decision binds Vorel to a single payment shape:

• The agent creates a hosted-checkout session via the payment provider’s server API.
• The agent sends your customer the provider’s hosted URL via SMS (voice channels) or an inline provider-branded button (chat channels).
• Your customer enters their card details directly into the provider’s hosted page.
• The provider acknowledges the payment via webhook to Vorel.
• Vorel receives the checkout session id, the payment-intent id, and a payment_resolution enum, nothing else.

The sensitive cardholder data (PAN, expiry, CVC, full magnetic-stripe data, full chip data) touch only the provider’s PCI Level 1 vault. Vorel’s role is to issue the link, observe the outcome, and reconcile the booking. This is what the PCI Council calls “outsourced payment processing with no electronic storage, processing, or transmission of cardholder data on the merchant’s systems.” It is the narrowest PCI merchant scope available.

​

SAQ-A merchant scope

Vorel’s PCI merchant scope is SAQ-A, Self-Assessment Questionnaire A. This is the questionnaire designed for merchants that have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers, and retain no electronic storage, processing, or transmission of cardholder data on their systems or premises. The contrast with PCI Level 1 (the merchant scope that vendors who actually touch PANs must clear) is material: The full PCI scope assessment is documented in the PCI Council’s SAQ guidance. Vorel sits in the SAQ-A column because, by architectural design, no card data flows through any system Vorel operates. Formal SAQ-A attestation is a self-assessment Vorel completes; it is not a third-party certification.

​

The SMS-first user experience

When the voice agent reaches a point in the conversation where a payment is needed (a restaurant booking deposit, a salon appointment hold, an auto-service intake confirmation), the flow is: If your customer ends the call before completing payment, the agent (TTS or chat-side) says: “I’ve sent you the secure payment link by SMS. You can complete it now or any time in the next 24 hours; we’ll hold your booking until then.” No mid-call re-engagement. No hard-fail. The booking sits in pending_payment state until the webhook arrives or the booking-hold window expires.

​

Per-pack timeouts

Different verticals have different urgency profiles. Restaurant diners are time-pressed and impatient; salon and auto-service customers can wait longer for the link to land. The per-pack windows are sealed in the same audited decision record: After the booking-hold window expires without a webhook completion, Vorel auto-cancels the reservation, writes an audit row (pci_vault_redirect_failed), and emits a payment_resolution='customer_abandoned' outcome on the call cost record.

​

The three hard-forbidden builds

The decision record names three payment-collection patterns as architecturally hard-forbidden. They will not ship without a policy amendment plus a code change to the lint gate. Each is forbidden because shipping it would pull Vorel into a PCI scope Vorel has architecturally committed to avoid.

1. DTMF card capture on voice paths. The voice service does not accept keystroke-based card-number entry. Any future PR that adds DTMF-keystroke handling to a payment-adjacent code path is refused by the CI lint gate. Reason: the moment the voice path routes a keystroke that could be a card digit, that service is in PCI L1 scope.
2. PAN, expiry, or CVC in any Vorel-hosted form. No Prisma model has a column for any of these. No log line carries them. No structured log field captures them. The lint gate greps every payment-flow file for these tokens and refuses to merge a match. Reason: the moment a Vorel-hosted form accepts a card field, the form host is in PCI L1 scope.
3. Persistent token storage outside the provider’s vault. Reusable payment-method tokens stay provider-side. Vorel only persists the checkout session id, the payment-intent id, and the payment_resolution enum; these are reference handles, not tokens that could be replayed against another payment processor. The lint gate refuses to merge a persistent token column on a payment-related Prisma model. Reason: a long-lived token that can be replayed against a payment processor is a stored-credential surface, and PCI scope follows it.

The lint gate’s enforcement code can be walked through under NDA as part of the verification surface a CISO can review against the architectural claim.

​

The booking-hold semantics

When the customer ends the call without completing payment, the agent does not retry, does not block the call until the webhook arrives, and does not lose the booking. The architectural pattern is:

• The appointment / table reservation / intake slot is held in pending_payment state for 24 hours.
• The hosted-checkout URL remains valid for that 24-hour window.
• Your customer can return to the SMS link any time and complete checkout.
• On webhook completion within the window, the booking flips to confirmed.
• On window expiry without completion, the reservation auto-releases and an audit row records customer_abandoned.

This is the trade-off the ADR makes against “synchronous payment confirmation before call end.” Synchronous-wait would add 2–10 minutes of held call time and unacceptable voice-grade latency (per Vorel’s voice latency posture, where call-perceived latency is dominated by LLM-thinking time rather than network round-trips). The 24-hour hold preserves the booking without holding the customer on the line.

​

Audit-log actions

Every step of the payment flow lands in audit_log. Operators see the trail at the per-tenant audit surface; auditors and CISO reviewers can pull the chain for any individual booking.

• pci_vault_redirect_issued: agent created a hosted-checkout session and read the redirect line / sent the SMS.
• pci_vault_redirect_completed: the provider’s webhook acknowledged the payment within the booking-hold window.
• pci_vault_redirect_failed: the provider returned a hard failure, or the booking-hold window expired without completion.
• pci_enable_toggled: operator flipped tenants.pci_payment_enabled (enable/disable PCI flows per tenant).
• pci_vendor_changed: operator changed the configured PCI vendor (future-proofing; today a single hosted-checkout provider is the only allowed value).

The voice_call_cost.payment_resolution column on each call carries the outcome enum: collected_via_vault, failed_at_vendor, customer_abandoned, expired_pre_redirect, or NULL (no PCI flow on this call). Retention on voice_call_cost is 365 days per the audited retention policy: sufficient for billing reconciliation and PCI audit evidence.

​

When is PCI enabled?

PCI payment collection is operator-enabled per tenant, not customer self-service. Your Vorel operator flips tenants.pci_payment_enabled after:

• You confirm you have an account with the supported payment provider, with API credentials Vorel can use for your tenant.
• Your vertical pack is one of the three packs PCI ships for at v1: restaurant, salon, auto_service.
• Your operator captures the per-tenant payment-provider credentials encrypted at rest the same way CRM credentials are.

The real estate pack does not collect card payments at booking; viewings and qualification do not have a per-conversation payment moment. Clinic vertical is not enabled for PCI at v1; clinic payments are a HIPAA-adjacent flow that requires a separate per-customer engagement.

​

What about chargebacks and refunds?

Chargeback handling lives on the payment provider’s side; the provider is the merchant of record for the payment processing. Vorel surfaces a chargeback_received event when the provider notifies us, and the operator-side reconciliation surface shows the affected voice_call_cost row. Refunds run from the provider’s dashboard or via its API; Vorel does not initiate refunds programmatically.

​

Reversibility

Switching the underlying vault vendor (to an alternate PCI-compliant payment provider) is a code-level change at the vault-redirect handler. The architectural commitment (SAQ-A scope, no PAN/CVC/expiry on Vorel infrastructure, the three hard-forbidden builds) is not reversible without an audited policy amendment. If a future enterprise customer with ≥$100K/yr ACV requires Vorel to operate as a PCI Level 1 merchant, the decision record documents the conditions under which that path reopens: explicit founder authority, contract-conditional volume, and a new policy amendment. Until those conditions are met, vault-redirect is the only architecture Vorel ships.

​

Related docs

• Compliance: PCI sub-processor disclosure, SAQ-A scope row.
• Security overview: encryption posture, audit-log policy, append-only tables.
• Data retention: voice_call_cost.payment_resolution retention (365 days for PCI reconciliation).
• Pricing: which packs include payment collection at booking.