In large restaurant chains, every digital interaction matters: user sign-ups, logins, password resets, order confirmations, loyalty redemptions. Behind all of this, there’s a small but critical piece of infrastructure: the verification layer.
For one of the world’s leading restaurant brands, we designed and deployed a dedicated OTP platform on Esgasy Cloud, capable of handling one-time passwords (OTP) in real time via SMS and WhatsApp—with full control over security, permissions, expiry, and scalability.
This project is not “just sending codes”. It’s about building a core infrastructure component that we can now replicate for other large organisations with similar needs.
The Challenge: Centralising Verification Under a Dedicated Infrastructure
The starting point was clear:
- Centralise OTP and transactional messaging in a single platform.
- Guarantee:
- Security in OTP generation and validation.
- Permission control per project and per API key.
- Configurable expiry and temporal uniqueness of OTP codes.
- Deploy the solution on a European cloud infrastructure fully controlled by Esgasy.
- Design the platform as a repeatable product, not a one-off custom build.
The underlying question was:
How do you turn a seemingly simple flow (“send a six-digit code to this phone number”) into a robust, auditable and scalable platform?
The Solution: A Dedicated OTP API on Esgasy Cloud
1. Channels and Business Logic
The platform supports two primary channels:
- Transactional SMS: account sign-up, login, password reset, sensitive operations.
- WhatsApp: OTP and specific transactional communications where a conversational channel adds value.
On top of these channels, we implemented the OTP logic:
- Numeric codes of 6 digits.
- Configurable expiry via an expire parameter (in seconds).
- Temporal uniqueness per client/project, enforced via cache.
- Strict parameter validation to prevent incorrect usage or abuse of the API.
2. A Single Endpoint Orchestrating the Entire Flow
All logic is exposed through a single endpoint:
otp.esgasy.com/api/send/otp
This endpoint accepts, among others, the following parameters:
- secret: API key identifying the client or project.
- type: channel (sms, whatsapp, etc.).
- mode: usage/billing mode (e.g. credits-based).
- gateway: identifier of the configured gateway.
- message: message template, including the {{otp}} placeholder.
- phone: destination number in international format.
- expire: OTP expiry time in seconds (e.g. 300).
In the backend, a switch($service) handles the “otp” case with several control layers:
- Permission control: the API key must explicitly have the otp permission. If not, the service returns a clear 403 response.
- Parameter validation: presence of message, correct type for expire, valid phone format, etc.
- Cache and uniqueness: a cache container is created per secret, and a 6-digit OTP is generated that does not already exist in that space.
The result is an API that is simple to integrate for the client’s engineering team, but with all the intelligence required to keep usage secure, controlled, and auditable.
Technical Architecture: Debian, Cache and Service Hardening
The platform runs on a Debian server within Esgasy’s cloud infrastructure, with:
- Web server (Apache/Nginx) with PHP support.
- Database and administration tools (phpMyAdmin, etc.).
- CRON jobs for maintenance, cleanup, and monitoring tasks.
- A cache layer to manage:
- Temporal uniqueness of OTP codes.
- Expiry according to the expire parameter.
During early testing, some scenarios produced HTTP 500 responses. Instead of treating this as a simple bug, we used it as an opportunity to harden the service:
- Reviewing the full flow: permissions, parameters, cache, gateway interaction.
- Clear separation between:
- Client-side errors (4xx): invalid parameters, missing permissions, etc.
- Server-side errors (5xx): internal failures, infrastructure issues.
- Improved logging and traceability to enable fast incident resolution.
The goal was not just to “make it work”, but to ensure it behaves like a critical infrastructure component, with predictable behaviour both in success and in failure.
From Project to Product: A Replicable Model for Other Large Organisations
Now scaled for a world leader in restoration, this project was nonetheless designed from day one to remain fully scalable as future needs grow, as has already proved to be the case.
The kind of organisation that benefits from this platform typically shares several traits:
- High-volume B2C interactions where identity verification is critical.
- Multiple digital touchpoints: web, mobile apps, in-store systems, loyalty platforms.
- Strong requirements around security, auditability and uptime.
- Preference for EU-based cloud infrastructure and clear data governance.
Typical use cases include:
- New account verification.
- Login and step-up authentication.
- Password reset flows.
- Order and reservation confirmations.
- High-risk transaction approval.
- Transactional messaging linked to loyalty and rewards.
The Esgasy OTP platform becomes a reusable building block: same endpoint, same security logic, same architecture—adapted to each organisation through configuration and API keys.
Who Is This Kind of Platform For?
This type of OTP platform makes sense for organisations where verification is not a “nice-to-have”, but a core part of the business and risk model. For example:
- Banks and financial institutions
- Strong customer authentication (SCA)
- Transaction signing and high-value payment confirmation
- Step-up authentication for sensitive operations
- FinTechs and payment providers
- KYC flows and account activation
- Card linking, wallet top-ups, P2P transfers
- Insurance companies
- Policyholder verification
- Secure access to claims and documentation
- Healthcare and telemedicine platforms
- Patient and practitioner verification
- Secure access to medical records and appointments
- Large retailers and e-commerce platforms
- Account creation and login security
- Order confirmation and delivery validation
- Loyalty and rewards operations
- Telecom and utility providers
- Customer identity verification
- SIM swaps, contract changes, service activations
- Global restaurant and hospitality chains
- Account and loyalty programme verification
- Reservation and order confirmation
- High-volume, multi-country OTP flows
In all these cases, the organisation needs:
- A dedicated verification layer it can understand, audit, and evolve.
- A platform that can be tuned to its own risk appetite and UX constraints.
- A partner that treats OTP as infrastructure, not as a checkbox feature.
Why Work With a Technology Partner Instead of a Generic OTP Service?
The key difference is not just technology—it’s the operating model.
With Esgasy, the OTP platform is:
- Deployed on Esgasy Cloud: EU-based infrastructure, with direct control over application, infrastructure and security layers.
- Business-logic aware: permissions, expiry, uniqueness, validation rules… all can be adapted to the client’s requirements.
- Designed to evolve: the architecture is ready to:
- Add new channels.
- Integrate additional messaging gateways.
- Adjust logic as business and regulatory needs change.
- Built for partnership: the goal is not to “send messages”, but to support a critical business function over the long term.
What’s Next?
We’ve turned this project into an OTP platform ready to be deployed for other large organisations that need:
- Real-time verification via SMS and WhatsApp.
- A secure, EU-based cloud infrastructure.
- A technology partner who understands both the technical and business implications of treating OTP as core infrastructure.
If you’re responsible for security, digital, or infrastructure in a bank, fintech, insurer, healthcare provider, retailer, utility, or large consumer brand, and you want more control over your verification layer, we can walk you through how this platform works and how it can be adapted to your environment.
