Security practices, clearly stated
MobDial handles communications, customer, and payment-adjacent workflows. This page describes current product and engineering practices without substituting marketing labels for third-party evidence.
Security controls in the platform
Controls still depend on correct deployment, configuration, credentials, and operational procedures. Product capability alone is not evidence that every environment or customer workflow is certified or compliant.
Identity & Access
MobDial uses authenticated sessions, role-based authorization, MFA-sensitive controls, and organization-scoped data access. Tenant identity is resolved and enforced server-side for protected application workflows.
Application Boundaries
API inputs are validated at application boundaries, database access uses parameterized queries, and sensitive provider credentials are kept in server-side environment configuration rather than customer-facing bundles.
Payment Tokenization
The current Authorize.Net card flow is designed around browser tokenization and opaque payment tokens. MobDial payment APIs are not designed to collect raw card numbers or security codes.
Webhook Integrity
Provider webhooks use signature verification and replay/idempotency controls before external events can change financial or operational state.
Auditability
Material application and billing workflows maintain audit and reconciliation records. Retention and evidence availability can vary by service, contract, and deployment configuration.
Web Security Headers
The web application applies controls such as Content Security Policy, HSTS, clickjacking protection, and restrictive browser permission policies at the application edge.
Support for customer compliance programs
TCPA & DNC Tooling
MobDial includes product controls for Do Not Call screening, calling windows, consent/revocation checks, and related communications safeguards. These tools support compliance programs but do not replace customer legal obligations or counsel.
Privacy Controls
MobDial documents its handling of personal information and customer data in the Privacy Policy and provides product controls for access, authorization, and data-management workflows.
Security Frameworks
MobDial may design controls with common security and privacy frameworks in mind. Framework alignment is not the same as an independent certification or attestation, and MobDial does not represent one on this page without current supporting evidence.
Customer Responsibilities
Security and regulatory obligations depend on each customer’s industry, data, configuration, use case, and contract. Customers remain responsible for determining the requirements that apply to their own operations.
High-risk workflow safeguards
- Organization scoping is required in protected data queries; database row-level policies are defense in depth rather than the sole tenant boundary.
- Structured validation is used at API and external-data boundaries for high-risk workflows.
- Payment and other consequential mutations use replay/idempotency controls to reduce duplicate execution risk.
- Secrets and provider credentials are intended to remain server-side and must not be committed to source control or exposed in customer responses.
- Signed provider callbacks fail closed when required verification evidence is absent or invalid.
- Security-sensitive changes are expected to pass the repository’s required type, test, compliance, deployment, and secret-scanning gates before release.
Ask for the evidence that matters to your review
Security attestations, penetration-test reports, contractual terms, subprocessors, and environment-specific controls can change over time. If your procurement or compliance process requires particular evidence, contact MobDial and identify the document or control you need. We will not represent an attestation as current unless we can support it with current evidence.
Responsible disclosure
If you believe you found a vulnerability in MobDial, please send the technical details needed to reproduce the issue to:
security@mobdial.comDo not include passwords, full payment-card data, private keys, or other unnecessary secrets in a vulnerability report.
Questions about security or procurement?
Tell us what your security, legal, or vendor-review process requires and we will respond with the documentation that is actually available for review.