Voice Payments: How to Build a Secure Dasha and Stripe Flow

What are voice payments?

Voice payments are transactions that a person initiates or authorizes with spoken instructions. A customer might tell a phone assistant or smart speaker to pay a bill, approve an order during a call, or ask an in-app voice agent to charge a saved payment method.

The voice interface does not move money by itself. It captures the customer's intent, retrieves the correct account or order, requests confirmation, and calls a payment service. A bank, card network, payment processor, or other payment rail still executes the transaction.

That distinction determines whether a voice payment system is safe:

• Use speech for conversation and consent. The agent can explain the charge, read back the amount, and ask the customer to approve it.
• Use trusted application data for payment parameters. Your backend—not the language model—should supply the customer, amount, currency, order, and saved payment method.
• Use a payment provider for payment credentials and execution. Raw card numbers and card verification codes should not pass through the voice model, prompt, transcript, recording, or ordinary application logs.
• Use a separate authentication and risk layer. Authenticate through approved, independent factors. In a NIST-conformant flow, voice comparison cannot be used for authentication.

This architecture supports the convenience people expect from voice-activated payments without treating a spoken command as unlimited financial authority.

Three types of voice payment flow

"Voice payment" describes several experiences with different technical and compliance requirements.

An IVR payment is a telephone payment completed through an interactive voice response system instead of a live agent. Older systems lead callers through fixed menus. A conversational voice agent can understand a request in natural language, but the sensitive payment step still needs the same deliberate isolation.

For most AI voice products, the safest starting point is a hybrid:

1. Let the voice agent retrieve the bill or order and obtain explicit consent.
2. Charge a previously saved, provider-tokenized payment method when policy allows it.
3. Send a customer to a secure hosted page or specialized telephone-payment flow when a new payment method or step-up authentication is required.
4. Let the voice agent report only the processor-confirmed result.

How voice payment processing works

A reliable voice payment moves through eight distinct stages.

1. Identify the customer and transaction

Start from server-trusted context wherever possible. An authenticated app session may already identify the customer. An inbound phone flow may need an account number plus a separate verification step. An outbound call should carry a non-sensitive internal customer or order identifier in call metadata.

Do not let the agent search for a customer from loosely matching personal details and then expose account information. Apply the same authorization checks that your web or mobile application uses.

2. Retrieve the payable object

The agent calls a read-only backend tool for an order, invoice, loan installment, deposit, or other payable object. The backend returns only the information needed for conversation, such as:

• merchant or business name;
• order or invoice reference;
• amount and currency;
• due date;
• allowed payment options; and
• a masked payment-method label, such as card brand and last four digits.

The language model may phrase this information, but it should not calculate the amount or choose an arbitrary customer record.

3. State the terms clearly

Before a write action, read back the exact amount, currency, object, and payment method. Avoid vague prompts such as "Should I take care of that?"

A stronger confirmation is:

"You are authorizing a $74.20 payment for invoice 1842 using the saved Visa ending in 4242. Should I submit it now?"

If the caller corrects any term, return to retrieval or validation. Do not silently reinterpret the correction.

4. Capture explicit confirmation

Treat confirmation as a short-lived event tied to one transaction snapshot. If the amount, currency, recipient, order version, or payment method changes, invalidate the confirmation and ask again.

For higher-risk actions, require an approved authentication factor or a secure handoff. NIST's general rule allows only limited use of some biometrics alongside a physical authenticator, but its voice-specific rule is stricter: SP 800-63B-4 section 3.2.3.2 says biometric comparison based on voice shall not be used. In a NIST-conformant authentication flow, voice comparison cannot establish the caller's identity or satisfy an authentication factor, even when it is paired with a physical authenticator.

A separate fraud system may analyze suspected replay, synthesized audio, or other call anomalies outside the authentication decision. Treat that output only as a non-authentication risk flag that can trigger extra controls. It cannot identify the caller, satisfy an authentication factor, provide transaction consent, or authorize the payment.

5. Submit a narrow payment request

The voice platform calls your backend. Your backend verifies the request, reloads the authoritative order, enforces permissions and risk rules, and then calls Stripe. It does not trust an amount, currency, Stripe customer ID, or payment-method ID generated by the model.

Stripe's Payment Intents API tracks a payment through changing states and can surface additional authentication when required. Use it as the payment state machine rather than treating one API call as a guaranteed charge.

6. Handle intermediate states

A payment can succeed, fail, remain in processing, or require customer action. Map these machine states to a small set of conversation-safe outcomes:

The assistant should not turn a timeout into "paid" and should not expose processor diagnostics that are meant for operators.

7. Verify the durable result

Use a signed Stripe webhook to update your order system. Stripe recommends verifying the Stripe-Signature against the raw request body, returning a successful response quickly, handling duplicate events, and not depending on event order. Its webhook documentation covers those delivery behaviors.

Your order database should become the durable source of truth. The voice agent can then query a payment-status tool or tell the customer that confirmation will arrive by an approved channel.

8. Issue a receipt without exposing secrets

Give the customer a receipt or confirmation reference, amount, and status. Do not read back or store a full primary account number (PAN), card verification code, API key, or PaymentIntent client secret.

A secure Dasha and Stripe architecture

With Dasha, the conversation runs in a managed voice runtime. Dasha tools let the agent call your HTTPS endpoint using a defined JSON Schema. Your endpoint owns business authorization and communicates with Stripe.

The boundary should look like this:

Caller
  |
  | speech: request and explicit confirmation
  v
Dasha voice agent
  |
  | narrow tool call: trusted order reference or confirmation token
  v
Your payment orchestration endpoint
  |-- authenticate request
  |-- load customer and order from trusted storage
  |-- enforce amount, currency, permissions, limits, and order state
  |-- create or retrieve an idempotent payment attempt
  v
Stripe
  |
  | signed webhook
  v
Your order and receipt system

Notice what is missing: the caller never dictates a full card number or CVC to the general-purpose voice agent. Dasha receives the minimum conversational context; Stripe retains the payment credential.

This is an important product and compliance boundary. Dasha does not currently publish PCI DSS card-capture support or DTMF masking. Dasha publishes warm-transfer controls for whether recording and speech recognition continue during a transferred leg, but does not present those controls as a PCI-validated payment or card-capture solution. We therefore do not present Dasha as a system for directly capturing spoken card credentials. Review the current Dasha security posture, confirm deployment-specific details with security@dasha.ai, and work with your PCI adviser or Qualified Security Assessor (QSA) before enabling a regulated payment flow. This article is architecture guidance, not a PCI attestation.

Design a tool the model cannot misuse

Keep the write tool narrow. If the order ID is already present in trusted call metadata, the model may need to send only a one-time confirmation token. The following configuration is an illustrative custom-tool sketch, not a copy-paste Dasha or Stripe reference implementation. Validate the final schema, authentication, and endpoint behavior against the current documentation and your own security requirements.

{
  "name": "submit_saved_payment",
  "description": "Submit the already confirmed payment for the current order. Call once only after the customer confirms the exact amount, currency, order, and masked saved payment method.",
  "schema": {
    "type": "object",
    "properties": {
      "confirmation_token": {
        "type": "string",
        "description": "Short-lived token returned by the prepare_payment tool"
      }
    },
    "required": ["confirmation_token"],
    "additionalProperties": false
  },
  "webhook": {
    "url": "https://api.example.com/tools/submit-saved-payment",
    "headers": {
      "Authorization": "Bearer YOUR_DASHA_TOOL_SECRET"
    }
  }
}

Do not add model-controlled fields for amount, currency, customer_id, payment_method, capture, or recipient. Your server should resolve those values from the confirmation token and current order state.

Also avoid a success-looking fallback result. A payment tool failure must remain a failure or an unknown state; otherwise the agent can tell a customer that an unverified payment succeeded.

Make the backend authoritative and idempotent

The following Node.js implementation sketch shows the control pattern. It is not a complete or copy-paste Dasha or Stripe reference implementation. It intentionally leaves authentication, transaction isolation, storage, expiration, error mapping, and framework details to your production stack.

app.post("/tools/submit-saved-payment", async (req, res) => {
  verifyDashaToolAuthorization(req);

  const { callId, callAdditionalData, arguments: args } = req.body;
  const confirmation = await confirmations.get(args.confirmation_token);

  if (!confirmation || confirmation.callId !== callId) {
    return res.status(403).json({ status: "not_authorized" });
  }

  // Never accept the price, customer, or PaymentMethod from model arguments.
  const order = await orders.lockAndGet(callAdditionalData.order_id);

  if (!order || order.customerId !== confirmation.customerId) {
    return res.status(404).json({ status: "order_not_found" });
  }

  if (order.status === "paid") {
    return res.json({ status: "already_paid", receipt: order.receiptRef });
  }

  assertSameTerms(order, confirmation);
  enforcePaymentPolicy(order, confirmation);

  // beginOrGet atomically gives every retry of this confirmed action
  // the same logical attempt and idempotency key.
  const attempt = await payments.beginOrGet({
    orderId: order.id,
    confirmationId: confirmation.id,
    orderVersion: order.version
  });

  // Authorize only the first submission or a same-key retry inside your
  // local retry window. Block if a prior result is unresolved, or if the
  // processor may have pruned the key, until reconciliation is complete.
  const submission = await payments.authorizeProcessorCall(attempt.id);

  if (!submission.allowed) {
    return res.status(202).json({ status: "verification_required" });
  }

  const intent = await stripe.paymentIntents.create(
    {
      amount: order.amountCents,
      currency: order.currency,
      customer: order.stripeCustomerId,
      payment_method: order.stripePaymentMethodId,
      confirm: true,
      metadata: { order_id: order.id }
    },
    {
      idempotencyKey: attempt.idempotencyKey
    }
  );

  await payments.recordProcessorState(order.id, intent.id, intent.status);

  return res.json({
    status: mapStripeStatus(intent.status),
    payment_reference: intent.id
  });
});

Stripe supports idempotency keys on API requests, but they are not a permanent duplicate-payment ledger. Stripe can automatically remove a key after it is at least 24 hours old. Reusing that key after it has been pruned creates a new request.

Use one stable key and the same parameters for retries of one logical attempt, within a local retry window that does not assume retention beyond 24 hours. Persist the order, confirmation, attempt, idempotency key, processor object ID when known, and last known processor state in your own database. If a submission has an unknown outcome, or its key may be past Stripe's retention window, a repeated voice command must not create another PaymentIntent or charge. Retrieve the known PaymentIntent or reconcile processor and webhook state first. Only a separately confirmed attempt after the previous attempt reaches a definitive non-payment state should receive a new key. These durable guards complement Stripe's idempotency layer.

Keep Stripe credentials server-side. Stripe's integration security guide recommends low-risk payment integrations that send payment information directly to Stripe instead of through your servers. It also makes clear that PCI DSS remains a shared responsibility between Stripe and the business accepting payment.

Use a secure handoff for new cards and extra authentication

If the caller does not have an eligible saved payment method, do not ask them to read a full card number into the voice model. Use one of these patterns:

1. Hosted checkout: Send a single-use link by SMS or email and keep the voice conversation open for non-sensitive guidance.
2. Specialized IVR or DTMF flow: Transfer the payment leg to a provider designed to isolate telephone card data.
3. Authenticated app or web flow: Ask the user to approve the payment in a signed-in application.
4. Human escalation with a protected payment surface: A representative can help with the transaction without hearing or seeing raw payment credentials.

If Stripe reports that additional customer action is required, route the user through the appropriate Stripe-supported confirmation experience. Do not ask the voice model to collect authentication secrets or attempt to work around the issuer's step-up flow.

Stripe also documents a specific mail order and telephone order (MOTO) flow for the supported Stripe Reader S700/S710 and BBPOS WisePOS E. It requires contacting Stripe Support for access. Stripe treats these transactions as card-not-present and places responsibility for customer identity verification and applicable legal, network, consent, and PCI obligations on the merchant. If eligible, treat MOTO as a separate secure handoff in which card entry happens on the supported Terminal reader—not as direct spoken-card capture by Dasha.

Are voice payments secure?

Voice payments can be secure, but speaking is not automatically safer than tapping or typing. Security depends on the complete system boundary.

The Payment Card Industry Security Standards Council's telephone-payment guidance explains why that boundary matters: voice and screen recordings, agent desktops, IVR systems, and connected telephony infrastructure can enter PCI DSS scope when they capture or transmit payment card data. It also recommends technologies that prevent cardholder data from entering call recordings.

For an AI voice agent, the rule is straightforward: if sensitive payment data enters the audio path, it can propagate into transcription, prompts, tool arguments, traces, recordings, analytics, backups, and support workflows. Preventing collection is safer than trying to redact every copy later.

Security controls every production flow needs

For a NIST-conformant flow, voice biometric comparison has no authentication role. A separate fraud system may flag suspected replay or synthesized audio as non-authentication telemetry, but that signal cannot establish identity or authorize a payment. Design the flow so a convincing voice still has to pass approved, independent controls.

Benefits and limitations of paying by voice

Where voice payments help

• Hands-free access: A customer can pay while their hands are occupied or when navigating a visual interface is difficult.
• Accessibility: A well-tested conversational flow can reduce reliance on small screens and complex forms. It still needs non-voice alternatives and testing with people who use assistive technology.
• Faster repeat payments: A recognized customer can retrieve an exact balance and approve a saved payment method without re-entering details.
• 24/7 self-service: Customers can resolve routine balances outside staffed hours.
• Guided recovery: The agent can explain a decline, missing account, or required handoff in plain language instead of ending at an error code.

Where voice introduces risk or friction

• Recognition errors: Noise, packet loss, accents, names, numbers, and currency amounts can be misunderstood.
• Ambiguous consent: Casual phrases such as "that's fine" may not clearly authorize a charge.
• Privacy: Other people may overhear account information or a payment confirmation.
• Authentication tradeoffs: Adding necessary verification can reduce the speed that makes voice appealing.
• Integration gaps: Not every merchant, bank, wallet, or payment method supports the same voice workflow.
• Compliance scope: Capturing payment credentials in the call can make telephony, recording, support, and data systems part of the regulated environment.

Design for these limitations instead of describing voice as inherently frictionless or fraud-proof.

Voice payment use cases

Voice works best when the payable object is already defined and the customer wants a low-friction way to act.

Bills and account balances

The agent can retrieve an outstanding balance, explain the due date, and charge an eligible saved method after explicit confirmation. Utilities, lenders, insurers, healthcare administrators, and subscription businesses can use this pattern, subject to their industry and regional obligations.

Repeat purchases and reorders

A customer can reorder an item from a known catalog and approve the final total. The backend should still validate inventory, price, delivery address, taxes, and payment eligibility before asking for confirmation.

Deposits and appointment payments

The agent can quote an exact deposit tied to an appointment or reservation. If a new card is needed, the agent can send a secure checkout link and continue scheduling after the backend receives payment confirmation.

Payment reminders and collections

A voice agent can explain an amount due and present approved options. Collection rules, consent, call timing, disclosures, and dispute handling vary by jurisdiction and use case; the conversation layer does not remove those obligations.

Agent-assisted customer service

The agent can resolve the reason for a call, prepare the payment, and hand off only the credential-collection step. This preserves conversational context while isolating sensitive data.

How to test a voice payment system

Do not test only the happy path with processor test cards. Test conversation, payment, security, and operational behavior together.

Functional scenarios

• exact confirmation and successful payment;
• customer changes the amount or order before confirming;
• no saved payment method;
• additional authentication required;
• card declined or payment method unavailable;
• duplicate tool invocation;
• caller repeats "pay it" after a delayed response;
• Stripe API timeout before and after a PaymentIntent is created;
• same logical attempt retried after the idempotency key may have been pruned;
• unresolved prior submission followed by another spoken confirmation;
• webhook arrives twice or out of order;
• call ends while payment is processing;
• already-paid order;
• cancellation, refund request, and human transfer.

Conversation and accessibility scenarios

• similar-sounding order numbers;
• dollars versus cents and different currencies;
• background noise, interruption, and silence;
• speech variation across the population you serve;
• caller using a screen reader or alternative channel during secure handoff;
• shared-room privacy and masked readback;
• an unauthorized person who knows account details;
• replayed or synthesized speech.

Use Dasha's tool testing to validate schemas and endpoint responses before calling, then inspect completed conversations with the Call Inspector. Because call inspection can include transcripts, recordings, model activity, and tool execution details, your tests should verify that no raw payment credentials appear in any of those surfaces.

Stripe recommends sandbox testing for payment flows and webhook delivery before going live. Its testing guide includes test payment methods and scenarios; never use real card details in a test environment.

Metrics that reveal real quality

Track more than payment volume:

• payment completion rate;
• authorization and decline rates by approved segment;
• secure-handoff completion rate;
• abandonment by conversation step;
• duplicate-charge and duplicate-attempt rate;
• unauthorized-attempt and step-up rate;
• time from confirmation to durable payment status;
• tool timeout and webhook delay rate;
• recognition repairs for amounts, order references, and confirmations; and
• support contact, dispute, refund, and chargeback rates after voice payments.

Review recordings and transcripts only under an approved retention and access policy, and only after keeping sensitive payment data out of them.

A production checklist

Before enabling voice payments for real customers, confirm that:

• the voice agent never requests or repeats a full card number or CVC;
• the customer and payable object are authorized server-side;
• amount, currency, recipient, and saved payment method come from trusted storage;
• the customer hears and confirms the exact transaction terms;
• confirmation expires and is invalidated by any material change;
• one logical payment attempt has one stable idempotency key;
• durable order and attempt state blocks a new processor request when an earlier result is unresolved or its idempotency key may have expired;
• the order is locked against concurrent or duplicate payment attempts;
• Stripe keys are restricted, server-side, and stored in a secrets manager;
• Stripe webhook signatures are verified from the raw request body;
• duplicate and out-of-order webhook events are safe;
• the agent never equates a timeout or fallback with success;
• new cards and additional authentication use a secure handoff;
• transcripts, recordings, tool payloads, traces, and backups contain no raw payment credentials;
• decline, processing, cancellation, refund, and transfer paths are tested;
• legal, payment-network, privacy, accessibility, and PCI responsibilities have been reviewed for the actual deployment; and
• production monitoring can reconcile every spoken confirmation, processor attempt, order state, and receipt.

Build the conversation around a protected payment boundary

A good voice payment experience feels simple because the architecture is strict. The agent understands the request, retrieves authoritative data, confirms one exact transaction, and invokes a narrow backend action. Stripe handles the payment state. Signed events update the order. Sensitive credentials never enter the general voice pipeline.

We help technical teams build and operate that conversational layer with telephony, tools, testing, monitoring, and production call execution. Start by building one end-to-end flow against Stripe's sandbox: retrieve one order, confirm one saved method, submit one idempotent attempt, and reconcile one signed webhook. Then test the failure and handoff paths before expanding access.

Explore Dasha's voice AI backend or start with the Dasha documentation to build the conversational workflow around your payment service.

Voice payments FAQ

Are voice payments safe?

They can be safe when the voice layer handles intent and confirmation while a compliant payment system handles credentials and execution. Authenticate the customer through independent, approved factors, and do not let raw card data enter transcripts, recordings, prompts, or tool logs. A NIST-conformant authentication flow cannot use voice comparison as an authentication factor.

What is the difference between voice payments and voice banking?

Voice banking covers a broader set of spoken account tasks, such as checking a balance, finding a transaction, transferring funds, or paying a bill. Voice payment refers specifically to the transaction flow that moves or collects money.

What is an IVR payment?

An IVR payment is a phone payment completed through an interactive voice response system. The system may use fixed prompts, keypad tones, speech recognition, or a conversational agent. If it collects card data, assess the PCI DSS scope of the payment leg, telephony, recordings, connected systems, people, and processes, then apply the required controls.

Can a customer pay entirely by voice?

Yes, when an authenticated customer has an eligible saved payment method and the backend can submit the exact confirmed transaction. New cards, additional issuer authentication, or higher-risk payments commonly require a secure browser, app, DTMF, specialized IVR, or human-assisted handoff.

Can Stripe process payments taken over the phone?

Stripe documents mail order and telephone order (MOTO) payments for the Stripe Reader S700/S710 and BBPOS WisePOS E. Merchants must contact Stripe Support for access. Stripe treats MOTO as card-not-present, and the merchant remains responsible for verifying the customer's identity and meeting applicable legal, network, consent, regional, and PCI requirements. In a Dasha workflow, MOTO is a separate secure handoff to a supported Terminal reader—not permission to route spoken card details through the voice agent.

Does a voice payment system need voice biometrics?

No. Many flows authenticate the customer through an existing app session, account credentials, a possession factor, or an out-of-band approval. For NIST-conformant authentication, voice biometric comparison cannot be used at all, even alongside a physical authenticator. A separate fraud system may use call anomalies as a non-authentication risk flag, but that flag cannot establish identity, satisfy an authentication factor, or authorize a payment.

How do Dasha and Stripe work together?

We manage the real-time conversation and call your HTTPS tools. Your backend validates the customer, order, confirmation, and policy before calling Stripe. Stripe tracks and processes the payment, then sends signed events back to your backend. The agent receives only the minimum status needed to guide the customer.