Security & retries

Keep the account key on your server

Your MeraOTP key can authorize real OTP sends and payment operations. Treat it like a password, not like a public website identifier.

• Store MERAOTP_API_KEY in your hosting environment or secret manager, outside the public document root.
• Never put the key in front-end JavaScript, a mobile app bundle, a screenshot, analytics, URLs or a public repository.
• Call MeraOTP from your own backend. The browser should call your application, not the authenticated MeraOTP API.
• If exposed, disable or regenerate the key from your account and update all of your integrations. The same key serves OTP and Payment Solution, so a rotation affects both.

There is no fixed-IP registration step for normal API authentication. Changing cloud addresses do not require a configuration change. This does not disable security controls: accounts can be blocked, abusive IPs can be blocked, and request limits still apply.

Bind an OTP to one person and one action

When a person starts login, store a server-side attempt containing the expected number, current user/session, action, idempotency key and returned message ID. Do not let a client replace that message ID with an arbitrary one from a different challenge.

Only proceed after the verification API confirms success for that attempt. Consume the attempt once in your own database or session, and establish a new authenticated session safely. An already verified challenge is not a new authorization for an unrelated login or financial action.

• Limit sends per phone number and per user/session, and add a resend cooldown. MeraOTP's limits do not replace your application's anti-abuse controls.
• Keep error messages useful without exposing whether an unrelated person's account exists.
• Never log OTP values, raw Authorization headers or complete recipient lists.
• Do not use SMS verification as a guarantee of a person's legal identity or protection against SIM swaps.

Retry the operation, not the charge

For OTP, assign one idempotency key to the intended send and save it before the request. A transport retry reuses that key and identical payload. A user-requested fresh code is a new attempt with a new key. If the provider outcome is uncertain, preserve the message ID and inspect its status before creating another send.

For payments, create your own unique order ID before calling MeraOTP. If link creation times out, do not generate a new customer order or automatically retry with an unrelated ID. A duplicate-order response means the original may already exist; inspect Payment Solution Activity, verify the original order, or ask support using that reference.

Back off after rate-limit or temporary-provider errors. Do not build a loop that retries indefinitely, generates fresh OTP keys every second or creates repeated payment orders while the user is waiting.

Never trust the browser as payment proof

Your server should decide the order amount, currency, allowed recipient and whether an order is unpaid. Values in a URL, screenshots and a success message displayed by a browser can be changed by the visitor.

• Use the authenticated payment-status API, or validate a signed webhook using the original raw body and the separate webhook secret.
• Match the response to your stored order and exact amount before fulfilment. Compare money using integer paise or decimal-safe logic, not binary floating-point equality.
• Protect fulfilment with an atomic database operation or a unique order-fulfilment record. Duplicate callbacks must not add balance or ship twice.
• Do not turn a previously confirmed success into unpaid merely because a later request times out.
• A closed checkout is not proof that no payment arrived. Reconcile the original reference when the payer reports a deduction.

A valid webhook signature proves that its body matches the sender's secret, not that it belongs to the order currently open in your browser. Order, amount, currency, status and duplicate-event checks are still your responsibility.

Production checks that matter

Use HTTPS and keep certificate verification enabled. Set bounded connection/request timeouts, redact logs, restrict access to your secrets and keep PHP/Node.js and application dependencies supported. Validate inputs on your backend even if the form already validates them.

Public documentation and API examples do not contain real account keys. The authenticated user panel, OTP verification pages and hosted payment pages are kept ad-free. An AdSense ownership meta tag is only site metadata; it does not execute advertisements or change API authentication.

For a suspected vulnerability, use the security support channel with a minimal redacted reproduction. Never post a working key or another user's personal data in a public issue or support screenshot.