SMS-Act Business & Enterprise Solutions
Enterprise teams procuring SMS verification capacity face a different decision than retail users. The 2026 carrier landscape — A2P 10DLC enforcement in the US, TRAI DLT scrubbing in India, Ofcom OBF filters in the UK, Anatel A2P registration in Brazil — has fragmented what used to be a single global number pool into per-country route stacks with sharply different pass rates. This page documents what SMS-Act offers procurement, integration, and platform-engineering teams, what we don't do, and how to evaluate us against Twilio Verify, Vonage Verify, MessageBird Verify, or building in-house against raw carrier APIs.
Need a contract today? Email biz@sms-act.net with: monthly verification volume estimate, target country mix, primary downstream platforms (e.g., Stripe / Meta / Google / a custom app), and whether you need NDA before sharing. Standard turnaround is 5 working days.
Right fit for SMS-Act enterprise
You operate at ≥5,000 verifications/month, your downstream platforms are mainstream (Meta, Google, OpenAI, Microsoft, Telegram, Discord, Tinder, Match Group, Uber, Bumble, Stripe, PayPal, Wise, Payoneer, AWS, Azure, Zoho, Slack, GitHub, TikTok, Shopee, Lazada, GCash, Amazon, eBay), and you need country-pool isolation for fraud-control purposes. Procurement is contract-based, not pay-as-you-go.
Wrong fit for SMS-Act enterprise
You need outbound SMS sending — that's A2P, and we are P2A only. Use Twilio, Vonage, MessageBird, Sinch, Plivo, or Azure Communication Services for outbound. You need bank-level KYC bridging (we don't issue regulated bank-of-record numbers). You need single-number permanence (we rotate numbers per activation; if you need sticky numbers for ongoing 2FA on the same end-user, you need eSIM or BYO-SIM, not a virtual SMS receive platform).
Why enterprises route through a verification platform instead of raw carriers
Building OTP receiving in-house against bare carrier APIs is technically possible. It usually fails commercially within 18 months. The root cause is that 2026's regulatory stack makes "carrier" a moving target:
- United States — A2P 10DLC. Since the Campaign Registry rolled out unregistered-traffic throttling (Nov 2023, hardened through 2024-2026), incoming-direction OTPs to unregistered T-Mobile and AT&T sub-pools experience 30-60% silent drop. Workaround requires Campaign Registry brand & campaign registration, which carriers gate.
- India — TRAI DLT. Telecom Regulatory Authority of India's Distributed Ledger Technology platform requires every commercial template to be pre-registered. OTPs whose sender header or content body don't match a registered template are scrubbed. Raw-carrier delivery rate without DLT registration runs <50% on Jio/Airtel/Vi.
- United Kingdom — Ofcom OBF. Ofcom's Originating Body Filter, jointly operated with UK Mobile Network Operators since 2024, prevents non-UK-originated OTPs claiming UK alphanumeric sender IDs. Delivery from non-resident A2P aggregators dropped from ~92% to ~71% during the Q4 2025 enforcement window.
- Brazil — Anatel A2P Registration. Since November 2025, Anatel enforces sender-ID registration for A2P traffic. Unregistered campaigns are throttled across Vivo, TIM, Claro, and Oi.
- Indonesia — Kominfo carrier whitelisting. Telkomsel, Indosat, and XL Axiata require pre-registration of A2P templates as of 2024. Bypass via international gateways has tightened.
The aggregate effect: a 2021-style "buy ten Twilio numbers and call it a day" architecture has dropped from ~88% global pass rate to roughly 62% in Q1 2026. Verification-platform middleware (Twilio Verify, Vonage Verify, SMS-Act, etc.) absorbs this complexity by maintaining country-specific route stacks, pre-registered templates where the regulator demands them, and HLR-aware number filtering.
Q1 2026 verification pass-rate matrix by industry × country
| Country | Productivity SaaS¹ | Cloud (AWS/Azure)² | Marketplace³ | Payment⁴ | Social / Dating⁵ |
|---|---|---|---|---|---|
| United States | 88% | 73% | 81% | 70% | 84% |
| United Kingdom | 86% | 71% | 79% | 69% | 82% |
| Germany | 84% | 70% | 77% | 67% | 80% |
| France | 83% | 70% | 76% | 67% | 79% |
| India | 87% | 81% | 84% | 72% | 86% |
| Indonesia | 89% | 83% | 87% | 76% | 88% |
| Philippines | 88% | 82% | 85% | 78% | 87% |
| Brazil | 82% | 71% | 78% | 65% | 80% |
| Russia | 85% | 78% | 82% | 74% | 84% |
| Japan | 86% | 75% | 80% | 71% | 83% |
¹ Productivity SaaS = Zoho / Slack / Notion / Atlassian / GitHub / Microsoft 365 / Google Workspace ² Cloud = AWS / Azure / GCP / DigitalOcean / Linode — failure driver is usually credit-card geolocation, not phone ³ Marketplace = Amazon / eBay / Lazada / Shopee / Mercari / Etsy / Poshmark / Allegro ⁴ Payment = Stripe / PayPal / Wise / Square / Razorpay / Mercado Pago / Payoneer ⁵ Social / Dating = Tinder / Bumble / POF / OkCupid / Match.com / Instagram / Snapchat
Source: SMS-Act internal aggregation, Q1 2026 (Jan-Mar). Pass rate = (successful OTP reception within 5 minutes) / (activations purchased). Excludes downstream KYC failures.
The 5-tier enterprise procurement framework
Different verification volumes need different procurement shapes. Match yourself to a tier before quoting.
| Tier | Monthly verifications | Pricing model | Account shape | Typical industry |
|---|---|---|---|---|
| Self-serve | < 500 | Pay-as-you-go | Single user | Indie devs, small SaaS |
| Team | 500 – 5,000 | Pre-paid balance + discount tier | One billing account, 3-5 users | Growth-stage SaaS, agencies |
| Business | 5,000 – 50,000 | Monthly commitment + overage | API key per environment | Mid-market SaaS, marketplaces |
| Enterprise | 50,000 – 500,000 | Quarterly commitment + custom SLA | Sub-account hierarchy, dedicated CSM | Fintech, ad networks, dating apps |
| White-label | 500,000+ | Per-verification reseller margin | Multi-tenant, DNS-pointed | Resellers, MVNOs, identity vendors |
The Business and Enterprise tiers are the procurement-friendly ones. They include written SLA, monthly invoicing in USD/EUR/RUB, dedicated technical contact, and country-pool isolation (your verifications draw from a sub-pool kept separate from the general retail pool, which reduces fraud-trigger contamination from other users).
Failure decode table: what to do when OTPs stop arriving
| Symptom | Likely root cause | Resolution path |
|---|---|---|
| "Number already in use" on the downstream platform | Number was previously used on that platform | Rotate via API — our pools deduplicate per platform but residual collisions exist on the long tail |
| OTP arrives but downstream rejects code | Code expired (most platforms time out at 5-10min) | Lower your end-to-end retrieval latency; switch to webhook polling rather than long-polling |
| OTP never arrives, balance refunded | Carrier route dropped the message at the regulatory filter | Switch to a different country / route — call /api/getStatus and look for STATUS_CANCEL |
| OTP never arrives, balance NOT refunded | OTP was likely delivered but to a recycled number whose previous holder caught it | Rare in our pool; report to support — manual refund within 48h |
| Sudden 30%+ drop across one country | Regulatory enforcement event (e.g., Anatel Nov 2025) | Route the country to a different sub-pool; CSM proactively notifies Enterprise tier |
| Inconsistent pass rates between dev and prod API keys | Test pool vs production pool routing differential | Use the same key for prod testing; do not draw from test pool for production traffic |
How to integrate
The REST API is documented at the customer portal once an enterprise account is provisioned. Three calls cover 95% of integration:
POST /api/getNumber— request a phone number for a target platform (e.g.,service=tgfor Telegram,service=wafor WhatsApp). Returns activation ID and number.GET /api/getStatus?id={activationId}— long-poll for the OTP. ReturnsSTATUS_OK:{code}when the code arrives, orSTATUS_WAIT_CODEwhile pending. Webhook delivery is also available.POST /api/setStatus— mark the activation as successful (finalize), refunded (release the balance), or extended (request a re-send window).
Average integration time is 1-2 engineering days for a single platform, 1 week for a multi-platform multi-country deployment with proper retry / route-failover logic. Reference implementations in Node.js, Python, Go, Java, and PHP are shipped with the enterprise account.
What the 5-tier framework explicitly excludes
We do not offer:
- Outbound A2P marketing/transactional SMS — use Twilio, Vonage, MessageBird, Sinch, Azure Communication Services
- Voice OTP (TTS or pre-recorded) — use Twilio Voice, Vonage Voice, Plivo
- Programmable voice calls in general
- Bank-of-record sticky numbers for 2FA over months/years — use eSIM provisioning (eSIM.net, Truphone) or BYO-SIM with virtual operator
- WhatsApp Business API messaging — that's BSP territory (Twilio, 360dialog, Meta Cloud API)
- Identity-graph services (resolving "is this person real") — use Persona, Onfido, Veriff, Trulioo
- Banking-grade KYC — use Sumsub, Jumio, ComplyAdvantage
Pretending we do these would invite procurement misalignment and compliance risk for you. The honest framing is: SMS-Act is a P2A receiving infrastructure for OTPs originated by third-party platforms.
SLA terms summary (Enterprise tier)
The full SLA is contractual and signed per customer. Common terms:
- Availability: API endpoint 99.9% monthly uptime, measured at our edge
- Tier-1 country pass rate: ≥85% (US, UK, DE, FR, IN, ID, PH, BR, RU, JP) monthly aggregate
- Tier-2 country pass rate: ≥75% (remaining 90+ countries)
- Median OTP latency: <30s from activation to webhook delivery
- Refund triggers: Any unfilled activation automatically refunds balance within 20 minutes
- Incident response: P0 (API down) acknowledged in 30 min; P1 (country-wide degradation) in 2h
- Service credits: 5% of monthly invoice per 0.5% missed pass-rate threshold, capped at 30%
Frequently asked enterprise questions
Q: Are SMS-Act and Hero-SMS the same company? A: No. SMS-Act has operated independently since 2023 with separate infrastructure, ownership, and roadmap. Hero-SMS was announced in December 2025 as the successor to SMS-Activate after its 2025-12-29 shutdown. SMS-Act predates that transition. Procurement teams should treat these as three distinct vendors when comparing options.
Q: How does SMS-Act compare on price to Twilio Verify? A: Per-verification, SMS-Act is typically 40-70% lower on Tier-1 countries because we operate on a different cost basis (we do not run an A2P sending stack). Twilio Verify's premium covers their A2P infrastructure and Verify-specific fraud product. If you are sending and receiving, Twilio's bundled pricing may be competitive. If you are receiving only, we are almost always cheaper.
Q: What's the typical fraud-protection stack on Enterprise tier? A: Buyer-side: IP allow-listing, API key rotation, webhook signature verification (HMAC-SHA256), per-account rate limits. Pool-side: HLR pre-filter (kicks out fixed-line / non-mobile numbers before they reach a registration flow), number-recycling cooldown, per-platform deduplication, anomaly detection on burst-buying patterns.
Q: How long is the contract minimum? A: Quarterly commitment (3 months) for Enterprise tier, monthly for Business. White-label requires 12-month commitment with quarterly volume reviews.
Q: Can SMS-Act sign a DPA (Data Processing Agreement) under GDPR? A: Yes. Our standard DPA covers Article 28 processor obligations, sub-processor disclosure, EU SCCs for international transfer, and 72-hour breach notification. Available under NDA from biz@sms-act.net.
Related reading
- SMS Verification Platform 2026 — selection criteria
- Overseas business registration — 5-tier framework
- Mobile receiving platform comparison — virtual / real / eSIM / VoIP
- Cloud SMS verification (AWS / Azure / GCP)
- Free vs paid SMS platforms — when each makes sense
Start the procurement conversation
Email biz@sms-act.net with your verification volume, country mix, and target downstream platforms. We respond within 24 hours with a tier recommendation and proposal outline. NDA available on request.
Open the SMS-Act dashboard · API integration · Pricing framework