Secure card payments

The secure payment flow collects card details and submits charges while your application orchestrates the conversation and chooses which prompts to play.

1. Collect the card number

Start a dedicated card-number dialog. Your application controls the prompts, while the platform suppresses live DTMF events during secure collection.

When collection finishes, your application receives only:

• The last four digits, for safe display and confirmation.
• An opaque card UUID token.

The full card number is never returned in an HTTP response, webhook, or DTMF event. The token references a dedicated in-memory vault entry, is bound to the current call, and cannot be used by another call or after the call ends.

The platform validates the card number. Invalid numbers and incomplete input produce distinct errors so your application can choose the next prompt or retry behavior.

Even on an error path, any card-derived display value is limited to the last four digits.

2. Collect the CVV

Use the dedicated CVV collection command to capture the three-digit security code. The digits and their live DTMF events are not exposed to your application.

The result is a separate opaque CVV UUID token backed by the same call-scoped, in-memory vault. The CVV itself is never returned.

3. Charge the card

Send the Charge command with:

• The card token.
• The CVV token.
• The expiry date.
• Your terminal credentials.

The expiry date may be collected separately with the regular Collect Digits command.

The platform resolves both tokens inside the secure boundary, submits the payment to the selected provider, and returns whether the charge succeeded or failed.

Both tokens must exist and belong to the active call. They expire when the call ends, regardless of whether a charge was attempted.

Payment provider

Each integration identifies the payment service it uses. Supported providers include nedarim (Nedarim Plus) and Kesher, with more providers coming. All providers use the same secure collection and charging flow.

Security model

The secure payment flow uses data minimization to keep the cardholder-data path as narrow as possible.

The collection component holds sensitive digits only during collection, then transfers them immediately to ephemeral, call-scoped in-memory storage.

The vault retains them only until the call ends and never persists them to disk.

Tokenization and trust boundaries

Your application receives opaque references instead of the primary account number (PAN) or CVV.

This tokenization keeps raw payment credentials on the protected side of the platform trust boundary and limits exposure across your application, webhooks, and operational tooling.

The card and CVV tokens reveal no credential data and are not globally reusable payment instruments. Each reference is bound to one active call and expires with that call.

Segmentation and least privilege

The vault is a segmented service with a deliberately narrow interface. Under the principle of least privilege, only the secure payment path can resolve vault references.

Other platform components operate on opaque tokens and do not need access to the underlying values.

This separation reduces the attack surface and limits the blast radius of a compromised application-facing component.

Context-bound authorization

A Charge command carries the card and CVV vault references together with the session UUID.

Before resolving either value, the secure payment service applies call-scoped authorization: both entries must exist, remain unexpired, and belong to the active session.

Suppression and redaction

Throughout secure collection:

• Raw digits and individual keypresses are excluded from application and platform logs, reducing accidental disclosure through observability pipelines.
• Live DTMF events remain suppressed so downstream consumers cannot reconstruct the input.
• The collection window is redacted from every active call recording, so the card number and CVV are not present in recorded audio.