Africastalking Laravel Package

Product Decisions This Supports

• Whether to launch phone-first in African markets. SMS remains the only near-universal reach channel across Kenya, Nigeria, Ghana, Uganda, Tanzania, Rwanda and Zambia, where email and smartphone penetration lag. This package turns "should we go mobile-first?" from a quarter-long platform debate into a ~1-day engineering spike. Decision enabled: launch with phone number as primary identity, email as secondary, and validate demand before committing to a comms platform.
• Vendor selection: Africa's Talking vs Twilio / Vonage / Infobip / Termii / BulkSMS. AT usually wins on per-message cost, local shortcodes and per-country sender ID support. Critically, because the integration lives in Laravel's notification layer rather than in domain code, reversing that decision later costs one adapter class plus a config change. That reversibility is what makes it rational to commit to a regional provider before you have volume leverage for negotiating.
• Build vs buy on messaging plumbing. The alternative is a bespoke HTTP client with retries, queue wiring, credential handling, and test doubles — weeks of undifferentiated work with no user-visible payoff. Buying it redirects PM and engineering capacity to the things users and regulators actually judge: message copy, template management, consent capture, opt-out handling, delivery reporting.
• Investing in a notification abstraction rather than a vendor adapter. Laravel's Notifiable model lets product decide channel per event, per user, and per country, and define fallback chains (SMS → voice → WhatsApp) without touching business logic. The abstraction is the durable asset; the AT adapter is disposable. PM implication: fund the abstraction, rent the adapter.
• Roadmap sequencing of use cases:
  • OTP / 2FA (signup, login, wallet actions, agent banking, KYC) — highest value, lowest content risk, correct pilot.
  • Transactional alerts — order confirmed, payment received, out for delivery, appointment reminder, renewal.
  • Operational alerts — driver assignment, stock-out, account status, shift reminders; frequently B2B and high willingness-to-pay.
  • Re-engagement / light marketing — only with explicit opt-in, functioning STOP handling, and registered sender IDs.
• A clean MVP-vs-platform scope line. This package is SMS send only. USSD sessions, mobile-money collect/payout, airtime rewards, inbound two-way SMS and delivery-receipt webhooks all require the AT SDK or REST API directly. That gives you a defensible split between "notification MVP" (weeks) and "communications platform" (quarters) — a real staffing and build-vs-buy conversation rather than an implementation detail.
• Compliance and consent treated as product requirements. SMS forces consent records, sender ID registration and per-country rules (Kenya DPA 2019, Nigeria NDPR, POPIA). The package solves none of this, but it makes consent capture cheap to instrument at the exact moment notifications are introduced. Decisions enabled: where consent is captured, how opt-outs are honored, what the audit trail looks like.
• Risk posture on a thin dependency. 25 stars, zero dependents, MIT, community-maintained channel group, last release November 2025. Acceptable for a pilot; acceptable for OTP if you pin the version and vendor the two source files. Not a reason to block, but a reason to budget an hour of diligence per Laravel upgrade.

When to Consider This Package

Adopt when:

• You are on Laravel and already (or are willing to) use the native notification system as your messaging abstraction.
• Your target markets are AT-covered countries and SMS is the realistic channel for identity verification or transactional alerts.
• Volume is modest and predictable: one recipient per notification, OTP and transactional traffic. This is a notification channel, not a campaign engine.
• Your team values a small, auditable surface area — a channel class and a message builder — over a large SDK integration.
• You need the vendor decision to stay reversible while you test the market.

Look elsewhere, or plan a companion build, when:

• You need bulk campaigns, drip sequences or broadcast — the channel is one-recipient-per-notification by design; use the AT bulk endpoint from a dedicated job with batching, backpressure and rate limiting.
• You need delivery receipts, two-way SMS, USSD, or mobile money — those are AT SDK/REST work outside this package's scope; treat them as a sidecar, not an extension of the notification class.
• You need multi-provider failover out of the box — you will write a thin SmsNotifier interface and bind it yourself (15 minutes, and worth doing on day one).
• Your stack is not Laravel, or your team has standardized on a vendor-agnostic comms platform (Twilio/Infobip) for global reach and consolidated billing.
• Governance thresholds apply: zero dependents and a single-maintainer risk profile mean a security or procurement review may require vendoring the two source files, a pinned version, and a named owner for quarterly upgrade checks. If your organization cannot accept that ownership, choose the AT REST API directly.

Preconditions before any production traffic: E.164 normalization at the notification boundary, queued delivery with bounded retries, a duplicate-suppression guard for OTP, sender ID registration started on day one (approval is a compliance lead time measured in days, not a deploy step), and a scheduled balance check — balance exhaustion is the most common silent SMS outage.

How to Pitch It (Stakeholders)

One-liner: This is a small, MIT-licensed adapter that plugs Africa's Talking SMS into Laravel's built-in notification system, letting us ship phone-first signup, OTP and transactional alerts in about a day of engineering instead of building and maintaining a messaging client.

To executives:

• Time to market: roughly one engineering day to a working OTP versus weeks for a bespoke integration. It lets us test "phone number as primary identity" as a cheap hypothesis in our African markets rather than a platform bet.
• Cost of being wrong is low. The vendor decision is reversible: because SMS sits behind Laravel's notification abstraction, switching providers later is one adapter file plus a config change. We are not locking in.
• Roadmap clarity: it cleanly separates the notification MVP (weeks) from a communications platform with USSD, mobile money and delivery receipts (quarters). That is a scope and headcount conversation we can have with real numbers.
• The risk is known and bounded, not hidden: 25 stars, no dependents, one maintainer. Mitigation is version pinning, vendoring two files, and a quarterly upgrade check — hours, not a project.

To engineering:

• It's a channel class plus a fluent message builder. The entire surface area you will ever depend on is two files — read them once and you know everything.
• It composes with what we already have: Notifiable, queued notifications, Notification::route() for phone-only recipients like pre-signup verification and guest checkout.
• The abstraction is the asset. Wrap it behind an SmsNotifier contract early so provider switches and country routing are container bindings, not refactors.
• Do not stretch it. Bulk sends, delivery receipts, USSD and mobile money go direct to the AT SDK/REST API in separate jobs and controllers — not into the notification class.
• Day-one non-negotiables: queue every send, normalize phones to E.164 at the routing boundary, cap retries with jittered backoff, dedupe OTP dispatches (a lost HTTP response after delivery means a duplicate SMS), rate-limit per account tier, and log with user/event correlation while treating AT's dashboard as delivery source of truth.

To compliance/ops:

• The package sends and forgets — consent capture, STOP handling, sender ID registration and per-country record-keeping are ours. Start sender ID registration immediately; approval timelines are the schedule risk, not the code.
• We get a natural instrumentation point: consent can be recorded at the same boundary where notifications are first introduced, giving us an audit trail from launch rather than a retrofit.