Auditable Fintech Access by Polling SMS OTP Delivery Status Without Webhooks

To audit the status of SMS OTP delivery without webhooks, a bounded polling approach is recommended. After sending an OTP, the system should poll a provider-neutral status adapter at regular intervals, recording each transition in an audit log. The login process should indicate the OTP was sent and wait before offering a new attempt, but it should not claim delivery unless the adapter reports a terminal state like delivered, invalid recipient, or failed.

If no terminal state is observed within a short deadline, the poll should stop without assuming success or failure.

The cost of this approach can be calculated based on the number of OTP sends (N), the number of polls per send (p), and the number of retained status rows (r). Polling generates N * p lookups, while storing evidence creates approximately N * r rows. A six-check policy would result in up to six status reads per send. Reducing checks can lower the lookup count, but retention length does not affect this.

This polling method aligns with security best practices outlined in the OWASP Forgot Password Cheat Sheet: OTPs must be generated securely, linked to individual users, invalidated after use, and protected by rate limiting. The system should generate and link OTPs securely, invalidate them after use, and limit retries. Delivery state provides useful evidence and user experience feedback but does not prove the user's entitlement to the account.

Bounded polling involves receiving stale snapshots of the OTP delivery state. The first snapshot might show the message as accepted or queued, even if the phone has already received it, while subsequent snapshots may reveal terminal failure states. No polling interval can eliminate this limitation. The login page should inform users that an OTP was sent, provide a controlled retry mechanism after a server-defined delay, and avoid false promises of delivery unless the adapter confirms a terminal state while preserving evidence.

Design parameters include polling intervals (e.g., 1, 2, 4, 8, 12, and 18 seconds) and a maximum deadline (e.g., 45 seconds). Adding per-attempt jitter helps avoid synchronized status requests during traffic spikes, and outstanding checks should be canceled when a terminal state is reached. It's crucial to keep OTP and authentication clocks independent. If the poll deadline expires while the OTP is still valid, the authentication should not be expired, and the delivery record should not be altered.

In cases where immediate server-side reactions are necessary for high message volumes, alternatives like authenticated event callbacks or queue-fed delivery events should be considered. These mechanisms, when properly implemented with signatures, replay protection, deduplication, and evidence persistence, can provide better performance than polling.

However, polling remains a reasonable approach when callbacks are unavailable and a short-lived user experience hint is sufficient. The central trade-off lies in balancing immediate server-side reactions with the need for a user-friendly, non-instantaneous authentication process.