Why We Chose Pay per Success Instead of Charging Every Request
Learn why LessOTP deducts credit only after successful production verification instead of every request, while keeping staging free.
Why LessOTP Uses Pay Per Success Billing
Many verification providers charge when a request is created or a message is dispatched. That model is convenient for providers, but not always fair for products: users may drop off, messages may arrive late, webhooks may temporarily fail, or codes may expire without producing a successful login.
LessOTP uses a pay per success model: credit is deducted only when a production verification succeeds. In staging, no credit is deducted so developers can test integrations without paying for experiments.
Per Request vs Per Success
| Aspect | Charge per Request | Pay per Success |
|---|---|---|
| Billing Moment | When request is created or message is triggered | When verification.success is reached |
| User Drop-off Risk | Can still be billed even when users do not finish | No charge when verification does not succeed |
| Developer Staging | Experiments may consume paid quota | Staging is free with ledger amount 0 for audit |
| Value Alignment | Provider is paid for traffic | LessOTP is paid when auth creates value |
| Billing Audit | Harder to separate useful from failed requests | CreditLedger links account_id, app_id, and request_id |
The Product Reasoning Behind This Model
- Fairer for B2B clients: cost appears only when a user is actually verified.
- Incentivizes LessOTP to optimize completion, not just request traffic.
- Reduces anxiety when engineering teams test flows in staging.
- Makes cost reports easier to read because every debit maps to a successful result.
There Are Still Guardrails Before Requests Are Created
Pay per success does not mean the endpoint is uncontrolled. LessOTP still uses App-level API keys, API key/IP rate limits, short expirations, staging/production isolation, idempotency, and signed webhooks to keep integrations safe.
Pay for outcomes, not just requests
Test LessOTP in staging, validate your webhook, then switch to production when your flow is ready to receive verification.success events.
Open Billing Documentation