Odoo core ships a strong TOTP-based two-factor authentication for internal backend users, but it runs out of road exactly where customer-facing risk lives. There is no native OTP challenge on the website login and signup forms, no phone-number verification at registration, no step-up confirmation on eCommerce checkout, and no OTP gate on sensitive portal actions or POS operations. Fraudulent signups, unverified mobile numbers, account-takeover on the customer portal, and unauthorized POS refunds or price overrides all slip through because Odoo has no channel to challenge the person on the other end. Adding a WhatsApp app-authenticator on top of TOTP does not solve this either — your customers don't run a TOTP app; they have a phone number.

We build a dedicated Odoo module that delivers one-time passwords over WhatsApp (via the WhatsApp Cloud API or a BSP such as Twilio/360dialog) and SMS, then verifies them across every customer-facing surface. Technically, the module introduces its own otp.request and otp.channel.config models (models.Model) that store a hashed OTP, an issue timestamp, a configurable TTL, and an attempt counter, with @api.depends computes for is_expired and attempts_remaining. Provider credentials and routing rules live in encrypted ir.config_parameter records surfaced through a res.config.settings panel. The verification flows hook the website controllers (website_sale, portal, and auth_signup) so login, signup, and the checkout confirmation step raise an OTP challenge rendered in QWeb/OWL, and the POS is extended with a small OWL screen that confirms high-risk actions before they commit. A dedicated ir.actions.server / automated action re-sends or escalates when the primary channel fails.

Security and configurability are first-class. OTP TTL, code length, maximum retries, resend cool-down, and rate limits per phone number are all admin-configurable. Access is enforced with ir.model.access.csv plus record rules so an OTP request is only ever visible to the user or session that owns it, and every issue/verify/fail event is written to the chatter and to an audit log for compliance. Multi-provider fallback routing means if WhatsApp delivery fails or a number is not WhatsApp-reachable, the module automatically falls back to SMS (or a secondary provider) using a priority-ordered otp.channel.config chain, so a single provider outage never locks your customers out. All OTP dispatch is also exposed over Odoo's XML-RPC/JSON-RPC API so headless or mobile front-ends can trigger and verify the same flows. It works on Odoo Community and Enterprise across 17.0, 18.0, and 19.0 — we handle the version-specific controller and OWL differences.

Because this is a build-to-order engagement, nothing is a black-box download. We start with a short scoping call to map exactly which surfaces you want gated (website login, signup, checkout, portal actions, POS), your provider(s), your compliance needs, and your Odoo version and edition. We then build against a written scope, ship the module to a staging instance for UAT, and only go live once you've signed off. Typical delivery is one working week from confirmed scope, and you receive the full source, a git repository handover, and a post-go-live support window.