Authy Laravel Package

Product Decisions This Supports

• MFA as a shippable increment, not a platform bet. The channel exposes Authy's SMS, voice, and in-app push verification behind a single toAuthy() method on any notifiable model, so "gate login behind two-factor" or "step-up verification before payout changes" becomes a sprint-sized deliverable rather than a quarter-long identity program. That difference matters when a security review or an enterprise deal has a date attached.
• Buy the vendor, borrow the adapter, own the abstraction. The real procurement decision is Twilio/Authy as your verification provider. This MIT package is a thin, replaceable integration layer that removes most of the build cost. Frame it that way in roadmap reviews: scrutinize the vendor contract, pricing, and EOL timeline — not the package.
• Channel strategy becomes a product lever, not an engineering constraint. SMS, voice, and push share one interface, so calls like "push-first for mobile users, SMS for web-only, voice fallback after repeated failures" are routing policy and configuration, not a second integration or a second vendor relationship. That unlocks segmentation by device, region, and risk tier — and it lets you encode cost ordering in one place (push is effectively free per attempt; voice is materially more expensive than SMS).
• Recovery and step-up flows, which are often higher value than login MFA. Phone verification at signup, account recovery when email is unreachable, and re-verification before sensitive changes (password, email, payout details, admin grants) all fall out of the same primitive. These close support-ticket volume and fraud losses that rarely show up in an MFA business case.
• Unblocking revenue against a known technical debt. If MFA gates an enterprise contract or a compliance finding, this lets you ship the gate now and defer platform work — a legitimate "unblock the deal, budget the migration" trade, provided the migration to Twilio Verify is scoped and funded in the same planning cycle rather than discovered later.
• Velocity and testability as legitimate roadmap arguments. Because it rides Laravel's native notification pipeline, you inherit queueing, rate-limit middleware, and Notification::fake() in tests. Shorter path to a working demo for a security questionnaire, and cheaper to test than bespoke HTTP calls.
• Scope clarity that protects your estimates. The package dispatches the challenge. It does not verify the returned code, enforce attempt limits, manage session state, or rate-limit. Plan the remaining work explicitly as a named workstream, or the MFA feature will look cheaper and smaller than it is — the most common way this adoption goes wrong.

When to Consider This Package

Adopt when:

• You are already a Twilio/Authy customer — contract, credentials, and billing in place — and want verification without onboarding a new vendor or a new security review.
• Your stack is Laravel on a PHP/Laravel version the package's composer.json still supports, verified against the last commit date rather than assumed.
• You need multiple verification channels (SMS, voice, push) and want one integration instead of three.
• You are running a time-boxed rollout to clear a security review or an enterprise blocker, and you are explicit internally that this is tactical.
• You want verification to flow through your existing notification and audit path (pair it with the database channel), so security logging and user communication are already solved.
• You can commit to building the missing half — verification-side logic, attempt limits, fallback factors, provisioning and backfill of Authy IDs — as an estimated workstream, not a footnote.

Look elsewhere when:

• Greenfield architecture. Twilio has signaled the Authy API's deprecation in favor of Twilio Verify. Starting new work on Authy bets against the vendor's own roadmap; evaluate Twilio Verify, Vonage, or self-hosted TOTP (pragmarx/google2fa) first.
• You already use Twilio Verify. Adopting this trades a supported API for a sunsetting one — a backwards move with no offsetting benefit.
• You need passkeys or WebAuthn. This is OTP-only and will not satisfy a phishing-resistant authentication requirement, which is where enterprise questionnaires are heading.
• Ecosystem trust is a hard gate. 57 stars and 0 dependents means no meaningful production-validation signal, plus single-maintainer risk. Answer that with the fork plan, not reassurance.
• You need an SLA, enterprise support, or a security questionnaire answered by the package author. Your support path is Twilio for the service and your own team for the adapter.
• Data residency or self-hosting is mandated. Authy is hosted; phone numbers leave your trust boundary.
• A leaked endpoint would be catastrophic and you have no rate-limiting capability. Nothing in the package prevents SMS pumping or toll fraud — per-user attempt caps, IP/geo velocity rules, and Twilio-side spend alerting are entirely yours.

PM diligence before committing: confirm Laravel/PHP compatibility and issue-tracker activity; read Twilio's current Authy EOL and Verify migration guidance and put the date on the roadmap at adoption time; check whether the package depends on twilio/sdk and whether that pin conflicts with your existing SDK; model per-verification pricing and set a spend cap; and confirm the channel routes by Authy ID, not phone number — meaning user provisioning and backfill is a migration project, not a config change.

How to Pitch It (Stakeholders)

For executives: This is a small, free (MIT-licensed) connector that lets us add SMS, voice, and push identity verification in roughly a sprint instead of a quarter, with no new infrastructure and no license cost. It is the fastest credible path to closing the security finding / unblocking the enterprise deal that has a date on it. Two caveats to say out loud: the underlying Authy API is on a published deprecation path toward Twilio Verify, so this is a tactical bridge rather than a ten-year foundation — and the package sends codes but does not validate them, so we are funding the verification logic, rate limiting, and provisioning work alongside it. Both are scoped, both are in the same plan; the ask is to fund the bridge and the migration together rather than discover the migration later.

For engineering: You get a thin, readable delivery adapter — essentially one channel class and a message builder on top of Laravel's native notification system. You inherit queueing, Notification::fake(), and your existing audit path for free. The real work is explicitly yours and should be designed behind a VerificationService interface from day one: challenge validation against the Authy check endpoint, RateLimiter on attempts, fallback factors (email OTP or TOTP) for users with null or stale Authy IDs, provisioning plus backfill for the existing user base, and one integration test or scheduled smoke check that actually hits the sandbox — because Notification::fake() will happily hide a broken API key. Three gotchas to design around: exceptions propagate out of notify() onto the login request path, queued retries re-send real billable tokens (set $tries = 1), and the channel returns an Authy ID rather than a phone number — returning the phone is the single most common integration bug.

For security and finance: Verification-side logic, attempt caps, and session state are not in the package — they are ours, and they are the difference between MFA and an open verification oracle. Plan for a per-user rate limit (e.g. 5 attempts / 10 minutes), geo/IP velocity rules, and spend alerting on the Twilio account, because a leaky trigger endpoint with no cap is a direct billing incident. Pricing is per-verification and channel-dependent: push is effectively free, SMS is modest, voice is materially more expensive — which is also the argument for push-first routing as a cost decision, not just a UX one.

One-line framing for the roadmap review: we are buying Twilio/Authy as the vendor and borrowing this MIT adapter as a replaceable seam — so review the vendor contract, pricing, and EOL date hard, treat the package as frozen and forkable, and hold the VerificationService interface as the point where we swap to Twilio Verify in an afternoon when the time comes.