Skip to main content
Flow2FAFlow2FA

Buyer’s guide

How to evaluate an OTP provider or 2FA API

A credible OTP provider should be able to prove completed-verification performance, explain its routing and fallback model, expose the evidence needed to diagnose failures, support the security controls appropriate to the use case, and price the complete verification journey rather than only the first message attempt.

This guide is written to help buyers compare Flow2FA and other providers using the same evidence.

Maintained by Flowstates Inc · Last reviewed 7 August 2026

Five-minute executive summary

Read this before the guide itself if you only have a few minutes. Each stage links to the full section for the evidence behind it.

  1. 01

    Decide whether OTP is appropriate

    Decision
    Confirm a one-time passcode is the right control for each flow, or whether some flows need a phishing-resistant authenticator instead.
    Evidence
    The assurance each flow actually needs, and the NIST and OWASP guidance on out-of-band authentication and email as a factor.
    Red flag
    A provider conversation that starts with channel comparisons before this question has skipped the decision that matters most.
    Go to section
  2. 02

    Choose architecture, channels and provider model

    Decision
    Settle REST vs SMPP v3.4, which party supplies delivery, and which channels are actually in scope for your markets.
    Evidence
    A written integration decision, per-channel preconditions and current Flow2FA channel status for the markets you serve.
    Red flag
    Treating channels as interchangeable, or assuming a channel is available before confirming it against documentation.
    Go to section
  3. 03

    Define evidence and outcome metrics

    Decision
    Agree the metrics and evidence pack you will use to compare providers, tied to completed verification rather than delivery receipts.
    Evidence
    Attempt-level samples, a field dictionary, and completion, latency, resend and fallback figures with defined denominators.
    Red flag
    Accepting a delivery receipt, a blended global average or an adjective ("excellent delivery") as if it were proof.
    Go to section
  4. 04

    Run a controlled pilot

    Decision
    Design a pilot with a baseline, defined segments, written success and rollback criteria, and a like-for-like comparison.
    Evidence
    A signed-off criteria document, live attempt-level data on the new path, and a comparison using the same definitions as the baseline.
    Red flag
    A pilot with no rollback criteria in writing, or one that starts with the highest-risk recovery or privileged-access flow.
    Go to section
  5. 05

    Evaluate security, operations, contract and total cost

    Decision
    Check the controls around the code itself, the operating model, the data and contract terms, and the full verification cost.
    Evidence
    The security-control table evidence column, a named escalation path, the data-processing agreement, and a worked cost-per-completed-verification example.
    Red flag
    A headline per-message price that excludes retries, fallback and pass-through charges, or a security claim with no supporting document.
    Go to section

Use this guide when…

  • You are comparing more than one OTP or 2FA provider and need the same evidence from each.
  • You are deciding whether to build a new OTP integration or migrate an existing one.
  • You need to justify a provider or architecture decision to security, procurement or engineering stakeholders.
  • You are designing a pilot and want criteria that can actually produce a decision.
  • You are reviewing an existing provider relationship before renewal.

Unfamiliar with a term? See the OTP and 2FA glossary.

Go directly to…

Start with the outcome you are protecting

Login, signup, transaction approval, account recovery and privileged access are not one requirement. They differ in the assurance the business needs, in what an attacker gains by defeating them, and in what a sensible fallback policy looks like when the primary channel fails.

A one-time passcode shows that someone had access to a phone number or mailbox at the moment the code was entered. It does not prove real-world identity, and it does not prove that a transaction is legitimate. Decide what each flow actually needs before you compare vendors.

Login authentication

What the OTP can demonstrate
That the person completing sign-in currently controls the registered number or mailbox.
Main failure or abuse concern
Real-time relay of the code to an attacker, credential stuffing paired with SIM swap, and abandoned logins when delivery is slow.
When stronger controls may be needed
For administrator accounts, high-value accounts or repeated risk signals, consider a phishing-resistant authenticator instead of, or in addition to, the code.

User onboarding / destination confirmation

What the OTP can demonstrate
That the number or address supplied at signup is reachable and controlled at that moment.
Main failure or abuse concern
Disposable numbers and mailboxes, bulk fake-account creation, and artificially inflated traffic sent to premium destinations.
When stronger controls may be needed
Where the account grants financial or data access, pair confirmation with identity proofing carried out by a separate service.

Transaction verification

What the OTP can demonstrate
That the code-holder approved a specific action, if the challenge is bound to that action in your application.
Main failure or abuse concern
Approval of an action the user did not understand, replay of an unbound code against a different transaction, and social-engineered read-back of the code.
When stronger controls may be needed
For payment flows, use the scheme-mandated control (for example 3-D Secure) and bind the challenge to transaction details shown to the user.

Account recovery

What the OTP can demonstrate
That the recovery destination on file is reachable — nothing more.
Main failure or abuse concern
Recovery becoming the weakest path into the account, especially after a number change or mailbox compromise.
When stronger controls may be needed
Recovery should be at least as strong as normal sign-in. Add cool-off periods, notification to the previous destination, or manual review for high-value accounts.

Enterprise or privileged access

What the OTP can demonstrate
A second factor at the point of access for staff, administrators or partner systems.
Main failure or abuse concern
Targeted phishing and MFA-fatigue techniques against a small, high-value population.
When stronger controls may be needed
Prefer phishing-resistant authentication for privileged roles, and treat OTP as a backup path with its own approval and audit rules.

Decide whether OTP is appropriate before choosing a provider

Choosing a provider before deciding whether a one-time passcode is the right control produces a well-integrated version of the wrong answer. Work through the following before shortlisting anyone.

  • A code that the user reads and types is not phishing-resistant. Anything a person can be persuaded to repeat can be relayed to an attacker in real time.
  • NIST treats out-of-band authentication delivered over the public telephone network as restricted, and recommends that relying parties consider signals such as SIM change, device swap and number porting.
  • Where access is high-risk or privileged, prefer phishing-resistant authentication where it is practical for the population you serve.
  • NIST SP 800-63B does not permit email as an out-of-band authenticator. Email can still be used for address confirmation and selected recovery or notification purposes, but buyers should not treat an emailed code as equivalent to a phishing-resistant authenticator.
  • Account recovery and factor replacement must not be weaker than the normal authentication flow, or they simply become the route an attacker takes.

Primary sources

The points above are paraphrases. Read the sources for the current normative text before writing policy against them.

Define the architecture before you shortlist providers

Three architectural decisions shape every later conversation. Settle them first, because they determine which providers can even be compared fairly.

A

REST or SMPP v3.4

Decide whether your application will call an HTTP interface directly, or whether authentication traffic will continue to leave through an existing messaging platform over SMPP. This decision usually follows what already sits in front of your traffic rather than a preference for either protocol.

B

Who supplies delivery

Decide whether the provider supplies routes, whether you keep your own providers and binds, or whether you mix the two by market or channel. Each option moves commercial leverage, operational load and troubleshooting responsibility to a different party.

C

Who owns policy, correlation and the decision

Decide which system holds authentication policy, which system correlates a challenge with a user and action, and which system makes the final allow-or-deny decision. In a Flow2FA REST integration that final decision stays in your application.

Where traffic originates

REST API
Your backend calls the OTP service directly over HTTPS.
SMPP v3.4
Your existing messaging platform, gateway or aggregator binds and submits messages.

Generate/validate model

REST API
POST /otp/generate creates the challenge; POST /otp/validate checks the submitted code and returns the result to your application.
SMPP v3.4
The bind carries message submission. Generation and validation semantics depend on how the integration is designed with your platform.

Correlation model

REST API
Flow2FA returns otpId at generation. You store it against your own login, transaction, registration or recovery record and present it again at validation.
SMPP v3.4
Existing identifiers and correlation remain in your messaging platform, subject to the integration design. Do not assume automatic pairing with REST validation.

Migration impact

REST API
A new outbound integration in the application layer; the existing submit path may be retired or left in place.
SMPP v3.4
The existing submit path is preserved, so existing downstream messaging tooling, queues and reporting can often remain in place, subject to the agreed integration design.

Best suited to

REST API
Teams that want the validation result inside the application flow with the smallest integration surface.
SMPP v3.4
Teams with an established messaging platform, carrier relationships or operational tooling they do not want to replace.

Important limitation

REST API
Your application must store and protect otpId, and must enforce its own session, action and attempt binding.
SMPP v3.4
Verification outcome reporting depends on where validation happens in the design; confirm this explicitly during scoping.

SMPP onboarding with Flow2FA

  • SMPP connections are provisioned during account setup rather than self-served.
  • Customers request the SMPP connection form from devs@flow2fa.com.
  • A VPN form may also be required depending on the connection design.
  • A VPN may involve a setup charge and implementation lead times.
  • Exact details are confirmed during account setup.

See SMPP v3.4 connection setup in the API documentation.

Choose the provider model that fits your constraints

The provider model decides where commercial leverage, operational load and troubleshooting responsibility end up. All three options below are legitimate; they suit different constraints.

Provider-managed delivery

What the provider supplies
Routing, provider relationships, sender configuration and day-to-day delivery operations for the agreed markets and channels.
What the customer retains
Authentication policy, correlation, the final application decision, and acceptance of the routes proposed.
Why a buyer might choose it
Can reduce the customer's delivery-operations burden and consolidate commercial and escalation paths.
Shared-responsibility risk
Route composition and change control sit with the provider, so the buyer sees less of what actually carried each attempt.
Evidence to request
Per-country, per-operator and per-route breakdowns, change-notification terms and a named escalation path.

Bring your own providers or SMPP binds

What the provider supplies
Generation, validation, attempt tracking and orchestration across the routes you already hold.
What the customer retains
Carrier contracts, pricing, sender registrations and first-line route troubleshooting.
Why a buyer might choose it
Existing commercial terms and coverage are preserved, and pricing leverage stays with the buyer.
Shared-responsibility risk
When delivery fails, responsibility can bounce between the platform and your own carriers unless ownership is written down.
Evidence to request
A written demarcation of who diagnoses what, plus attempt-level records that identify the bind or provider used.

Hybrid by market or channel

What the provider supplies
Orchestration across a mix of provider-supplied and customer-owned paths, per market or per channel.
What the customer retains
The subset of markets, channels and providers the buyer chooses to keep.
Why a buyer might choose it
Keeps strong routes where the buyer already has them and fills gaps without a full migration.
Shared-responsibility risk
The most configuration to get wrong; assurance and cost can differ silently between markets.
Evidence to request
A per-market map of which path is primary, which is fallback, and how each is reported.
A second provider is not resilience by itself. If both providers ultimately depend on the same underlying route, sender registration or operator path, a failure at that shared point removes both at once. Ask each provider to show where the paths actually diverge.

Evaluate each channel separately

Channels are not interchangeable. Each has its own preconditions, its own security ceiling and its own failure modes, so evaluate them one at a time rather than as a single “multi-channel” feature.

SMS

Where it can fit
Broad consumer reach where users may not have a smartphone app or a reliable data connection.
Preconditions
Sender registration and template rules vary by market; some countries require registration before traffic is accepted.
Security limitations
Not phishing-resistant, exposed to SIM swap and number porting, and readable on a locked screen on many devices.
Delivery and operational risks
Operator filtering, route changes, silent truncation of long content and cost spikes from artificially generated traffic.
Evidence to request
Per-country and per-operator completion and latency samples, the sender IDs in use and the registration status for your markets.
Current Flow2FA status
A documented public REST channel value.

Email

Where it can fit
Address validation, onboarding confirmation and selected lower-risk flows, or as an alternate path where a number is unavailable.
Preconditions
Sending-domain authentication and a sender reputation that will not push authentication mail into spam.
Security limitations
Assurance depends entirely on mailbox security; a compromised mailbox defeats the factor, and it should not be presented as equivalent to a phishing-resistant authenticator.
Delivery and operational risks
Spam placement, greylisting delays, aggressive link and content scanning, and inconsistent time-to-inbox.
Evidence to request
Authentication alignment for the sending domain, placement and latency samples, and bounce and complaint handling.
Current Flow2FA status
A documented public REST channel value.

WhatsApp

Where it can fit
Markets where the app is the default messaging habit and a recognisable business profile may give the recipient more sender context.
Preconditions
A business account, approved message templates and an accepted opt-in position for the traffic in question.
Security limitations
Still a manually entered code, so it is not phishing-resistant; account takeover of the messaging app defeats it.
Delivery and operational risks
Template approval delays, policy changes, and users who have the app installed but not actively reachable.
Evidence to request
Template approval status, the account under which traffic is sent, and completion data for the same markets on SMS.
Current Flow2FA status
May be included in configured deployments, but is not currently a documented public REST channel value.
Fallback between channels can reduce assurance. If a flow can silently move from one channel to another, the lower-assurance path must be approved for the action being protected, and each attempt must record which channel actually carried it.

Ask for proof, not adjectives

Most provider claims are unfalsifiable as stated. Convert each one into a request for something a buyer can inspect.

“We have excellent delivery.”

Useful evidence
Completion and latency data broken down by country, operator, channel and route for a stated period, with the denominator defined.

“We have automatic failover.”

Useful evidence
Written trigger rules, who can invoke them, duplicate and stale-code controls, an audit history of past changes, and the completion outcome of fallback attempts.

“We support global traffic.”

Useful evidence
The specific markets, routes, sender registrations and regulatory restrictions relevant to the countries you actually serve.

“We have detailed reporting.”

Useful evidence
A sample event schema, a field dictionary, an export in the format you would consume, and confirmation of which fields exist for your account type.

“We offer 24/7 support.”

Useful evidence
The contractual support coverage, the escalation path with named ownership, and the definition of a response — acknowledgement is not resolution.

Evidence pack to request

  • An attempt-level event sample covering generation, delivery attempts, resends and validation outcomes.
  • A field dictionary defining every field, status and enumeration in that sample.
  • A breakdown by country, operator, channel and route for the markets you serve.
  • A p50 and p95 latency sample for request-to-delivery and request-to-verification.
  • Resend and fallback outcomes, including whether fallback attempts completed.
  • The delivery-to-verification gap for a representative period.
  • A redacted incident or postmortem example where one is available.
  • A reporting and export sample in the format your team would actually consume.
  • A data map and retention schedule for every element stored.
  • A worked commercial example calculated against your own volumes and markets.
  • A named escalation path and a written ownership model for degraded routes.

Use metrics tied to completed verification

Accepted requests and delivery receipts describe the messaging layer. The business outcome is a completed verification, so define the metrics against that and use the same definitions for every provider.

Verification completion rate

Formula or definition
successful validations ÷ valid generated challenges
What it reveals
Whether users actually finish the flow the business depends on.
Common interpretation mistake
Substituting delivery receipts for completions; a delivered message is not a completed verification.

First-attempt completion rate

Formula or definition
successful validations completed without a resend or fallback ÷ valid generated challenges
What it reveals
How well the primary path works before any recovery mechanism hides the problem.
Common interpretation mistake
Reading a healthy overall rate as a healthy primary path when resends are carrying it.

Request-to-delivery latency (p50, p95)

Formula or definition
Time from the generation request to the delivery event, at the 50th and 95th percentiles.
What it reveals
Whether the message arrives inside the code lifetime for most users, and how bad the tail is.
Common interpretation mistake
Quoting an average, which hides the tail where abandonment actually happens.

Request-to-verification latency (p50, p95)

Formula or definition
Time from the generation request to a successful validation, at the 50th and 95th percentiles.
What it reveals
The real user-perceived duration of the whole verification journey.
Common interpretation mistake
Assuming it tracks delivery latency; user behaviour and interface friction sit inside this number.

Resend rate

Formula or definition
resend requests ÷ valid generated challenges
What it reveals
How often the first attempt fails the user, by delivery or by usability.
Common interpretation mistake
Treating a low resend rate as success when users abandon instead of resending.

Fallback rate

Formula or definition
challenges that used an alternate channel or route ÷ valid generated challenges
What it reveals
How often the primary path is not sufficient.
Common interpretation mistake
Not noticing that fallback is masking a persistent primary-route problem.

Fallback completion rate

Formula or definition
successful validations after fallback ÷ challenges that used fallback
What it reveals
Whether the alternate path actually rescues the journey or merely spends money.
Common interpretation mistake
Assuming fallback works because it fires; firing and completing are different events.

Delivery-to-verification gap

Formula or definition
delivered attempts − successful validations, expressed against delivered attempts
What it reveals
Where the loss sits: messages arriving but codes not being entered.
Common interpretation mistake
Blaming routing for a gap that is caused by code lifetime, interface design or message content.

Cost per completed verification

Formula or definition
total primary, retry and fallback delivery cost ÷ successful validations
What it reveals
A more outcome-aligned unit measure than price per submitted message.
Common interpretation mistake
Comparing headline per-message prices, which ignores retries, fallback and pass-through charges.
Confirm which fields, dimensions, reports and exports are actually available for the configured account before contracting. Do not assume every provider exposes every metric in a dashboard.

Run a pilot that can produce a decision

A pilot that cannot end in a decision is a demo with extra steps. Design it so each stage produces evidence and a defensible exit.

1. Baseline

Action
Measure the current flow over a representative period that includes normal peaks, not a quiet week.
Evidence produced
Existing completion, latency, resend, fallback and cost figures with defined denominators.
Exit decision
Proceed only when the baseline is agreed by both the business and engineering owners.

2. Segment

Action
Split traffic by use case, country, operator, channel and provider before comparing anything.
Evidence produced
A segment map showing where the volume and the current losses actually sit.
Exit decision
Choose the segments the pilot will cover and the segments it deliberately will not.

3. Define criteria

Action
Write success, safety and rollback criteria — and who may invoke rollback — before any traffic moves.
Evidence produced
A signed-off criteria document with named owners and a rollback procedure.
Exit decision
No traffic moves until the criteria and the rollback path exist in writing.

4. Controlled exposure

Action
Move a controlled, appropriate traffic segment rather than starting with the highest-risk recovery or privileged-access flows.
Evidence produced
Live attempt-level data on the new path alongside the untouched baseline segments.
Exit decision
Continue, pause or roll back against the criteria — not against impressions.

5. Compare

Action
Compare completion, latency, resend, fallback, incidents and cost per completed verification across the same segments.
Evidence produced
A like-for-like comparison with the same definitions applied to both providers.
Exit decision
Expand, re-scope or stop, with the reasoning recorded for the next review.
There is no universal pilot percentage, duration or traffic share. Thresholds depend on your risk appetite, volumes, seasonality and the quality of your baseline. Set them deliberately and write them down before the first message moves.

Check the controls around the code — not only delivery

Delivery is the visible part of an OTP flow, but most real weaknesses sit around the code: lifetime, reuse, attempt limits, binding and recovery. Each control has a provider side and an application side, and gaps appear where neither party has written down which is which.

Cryptographically secure code generation

Provider responsibility
Generate codes from a cryptographically secure source with a configurable length.
Customer / application responsibility
Choose a length appropriate to the risk and the attempt limits applied.
Evidence to request
A written statement of the generation method and the configurable length range.

Short time-to-live

Provider responsibility
Enforce the configured expiry and reject expired codes.
Customer / application responsibility
Set a lifetime short enough to limit exposure but long enough for real delivery latency.
Evidence to request
The configurable expiry range and the behaviour when an expired code is submitted.

Single use

Provider responsibility
Invalidate a code once it has been successfully validated.
Customer / application responsibility
Never accept the same challenge twice in the application flow.
Evidence to request
The documented behaviour on a repeat validation of the same challenge.

Attempt limits

Provider responsibility
Cap validation attempts against a single challenge and report the outcome.
Customer / application responsibility
Decide what the application does when the cap is hit: lock, step up or re-challenge.
Evidence to request
The default and configurable attempt limits, and the response returned at the limit.

Resend invalidation and behaviour

Provider responsibility
Define whether a resend re-sends the existing code or issues a new one, and what happens to the previous code.
Customer / application responsibility
Surface resend clearly in the interface and avoid presenting two live codes to a user.
Evidence to request
The written resend rule and how each resend appears in attempt-level records.

Rate limits by account, destination and source

Provider responsibility
Apply platform limits and expose the rejection reason.
Customer / application responsibility
Apply application-level limits per user, session and IP where appropriate.
Evidence to request
The documented limits, the rejection responses and how limits can be tuned.

Artificial traffic and SMS pumping controls

Provider responsibility
Detect abnormal destination patterns and unusual traffic concentration, and explain what action follows.
Customer / application responsibility
Protect the endpoint that triggers a code so it cannot be called freely from the internet.
Evidence to request
A description of the detection approach and how affected traffic is handled and reported.

API-key protection and rotation

Provider responsibility
Support key rotation and scoping without downtime.
Customer / application responsibility
Keep keys server-side, never in a browser or mobile bundle, and rotate on a schedule.
Evidence to request
The rotation procedure and whether overlapping keys are supported.

No OTP logging

Provider responsibility
Keep code values out of application, access and support logs.
Customer / application responsibility
Keep code values out of your own logs, analytics and error reporting.
Evidence to request
A written statement on log content and how support diagnoses issues without the code value.

No long-term plaintext OTP storage

Provider responsibility
Avoid retaining code values in long-term plaintext storage.
Customer / application responsibility
Never store the submitted code in your own database beyond the validation call.
Evidence to request
The retention treatment of the code value specifically, separate from the attempt record.

Request, session and action binding

Provider responsibility
Return an identifier at generation that must be presented at validation.
Customer / application responsibility
Bind that identifier to your own user, session and action record, and reject mismatches.
Evidence to request
The identifier semantics and what happens when validation is attempted with a mismatched context.

Destination and factor-change protection

Provider responsibility
Report the destination used on each attempt so changes are visible.
Customer / application responsibility
Re-verify when a user changes number or address, and notify the previous destination.
Evidence to request
How destination changes appear in attempt-level records.

Recovery controls

Provider responsibility
Provide the same controls on recovery challenges as on sign-in challenges.
Customer / application responsibility
Ensure recovery is not weaker than normal authentication; add cool-off or review where warranted.
Evidence to request
Confirmation that no control is relaxed on recovery traffic.

SIM-swap and number-porting signals

Provider responsibility
State plainly whether such signals are available, and for which markets.
Customer / application responsibility
Decide how a positive signal changes the flow — step up, delay or refuse.
Evidence to request
A direct answer on availability by market; treat a vague answer as a no.

Audit trail

Provider responsibility
Retain an attempt-level record of generation, delivery, resend, fallback and validation events.
Customer / application responsibility
Retain the corresponding application-side decision record.
Evidence to request
A sample audit record and the retention period that applies to it.
Flow2FA is a delivery and verification layer, not a fraud engine. Risk scoring, velocity decisions, step-up policy and the decision to allow or refuse an action stay in the customer's own risk and application systems. Use the NIST and OWASP references above as the primary-source context for the control set.

Test the operating model before the first incident

Resilience is not a second supplier on a slide. It is detection that fires early, an alternate path that has already been approved for the action being protected, traceability that survives the switch, prevention of duplicate and stale codes, an escalation path with a name on it, and a controlled, audited restoration.

Questions to put to each provider

  1. 01What exactly triggers a route or channel change — which metric, over which window, at which threshold?
  2. 02Is fallback automatic, manual or configuration-dependent, and can we see the current setting?
  3. 03Who is permitted to change routing, and is that change logged and notified?
  4. 04How are duplicate and stale codes prevented when a challenge moves to another path?
  5. 05How is each attempt tied back to the original request?
  6. 06How is a single affected market or operator isolated without disturbing everything else?
  7. 07Who owns escalation to the underlying provider, and what is the path out of hours?
  8. 08How is restoration approved, executed and audited after an incident?
  9. 09Which fallback paths lower assurance, and who approved them for each protected action?
  10. 10What happens if the backup provider shares the same underlying route as the primary?

Include data and contract terms in the technical decision

Data-protection and contract terms decide what you can actually do with the service, and they are far harder to change after signature than any technical setting. Bring them into the technical evaluation rather than after it.

Controller and processor roles

Question to ask
Which party is controller and which is processor for each data element in the flow?
Evidence to request
The roles as written in the contract and the data-processing agreement, not as described in a call.

Data elements stored

Question to ask
Exactly which fields are stored — destination, message content, attempt metadata, code value?
Evidence to request
A field-level data map covering every element retained.

Retention and deletion

Question to ask
How long is each element retained, and what triggers deletion?
Evidence to request
A retention schedule per element, with the deletion mechanism described.

Subprocessors

Question to ask
Which subprocessors are involved, for what purpose, and how are changes notified?
Evidence to request
A current subprocessor list and the change-notification term.

Processing regions

Question to ask
Where is data processed and stored, and can that be constrained?
Evidence to request
A written statement of processing locations for your configuration. Ask; do not assume.

Security incident notification

Question to ask
What triggers notification, to whom, and within what period?
Evidence to request
The notification clause and the contact route it uses.

Access control

Question to ask
Who inside the provider can see destination data or attempt records, and under what controls?
Evidence to request
The internal access-control description and how privileged access is logged.

Encryption in transit and at rest

Question to ask
What is encrypted, with what, and where are the gaps?
Evidence to request
A written statement covering both states. Request evidence rather than accepting a summary claim.

Data-processing agreement

Question to ask
Is a DPA available, and does it match the roles described in the contract?
Evidence to request
The DPA document itself, reviewed alongside the main agreement.

Audit and security evidence

Question to ask
What independent or internal security evidence can be shared, and how current is it?
Evidence to request
The actual documents or a summary with dates, rather than a logo on a website.

Data export and termination assistance

Question to ask
What can be exported, in what format, and what help is provided on exit?
Evidence to request
A sample export and the termination-assistance clause.

Backup deletion treatment

Question to ask
How is deleted data handled in backups, and over what period does it age out?
Evidence to request
The backup retention period and the deletion approach applied to it.

Compare the full verification cost, not the first message price

Ask each provider whether the following are included in the quoted rate or charged separately. A proposal that only prices the first attempt is not comparable with one that prices the journey.

  • Primary delivery attempts
  • Retries of the same challenge
  • Fallback attempts on another channel or route
  • Carrier or provider pass-through charges
  • Sender ID, template or registration costs
  • SMPP setup
  • VPN setup where a VPN is required
  • Support tiers and anything beyond the default tier
  • Monthly minimums or volume commitments
  • Currency, taxes and the mechanism for price changes
  • Data, reporting or export charges
  • Termination or migration costs
These are questions to put to every provider, including Flow2FA. They are not statements about Flow2FA's current charging model, which is confirmed during scoping.
Total monthly delivery cost = primary attempts + retries + fallback attempts + fixed/setup/operational chargesCost per completed verification = total monthly delivery cost ÷ successful validations

Primary attempts × unit price

Your figure
—
Notes
Per country and channel; do not average across markets.

Retries × unit price

Your figure
—
Notes
Include resends triggered by the user and by the platform.

Fallback attempts × unit price

Your figure
—
Notes
Fallback often carries a different unit price.

Pass-through and registration charges

Your figure
—
Notes
Carrier surcharges, sender registration, template fees.

Fixed, setup and operational charges

Your figure
—
Notes
SMPP setup, VPN setup, support tier, minimums.

Total monthly delivery cost

Your figure
—
Notes
Sum of the rows above.

Successful validations

Your figure
—
Notes
Completed verifications, not delivered messages.

Cost per completed verification

Your figure
—
Notes
Total monthly delivery cost ÷ successful validations.

Read the definitions behind the SLA

Two providers can quote the same number against entirely different measurements. Read the definitions before comparing the figures.

API availability

What it actually measures
Whether the interface accepted requests and responded within a stated period.
What it does not cover
Whether any message reached a user or any verification completed.

Provider acceptance

What it actually measures
That a downstream provider accepted the message for delivery.
What it does not cover
Operator filtering, handset state or mailbox placement after acceptance.

Delivery receipt

What it actually measures
A network event reported back for a message.
What it does not cover
Whether a person saw the message, and whether the receipt is accurate for that route.

Verification completion

What it actually measures
That a user submitted a valid code and validation succeeded.
What it does not cover
Nothing about identity; only that the code reached someone who entered it correctly.

Support response time

What it actually measures
Time to a first human acknowledgement of a ticket.
What it does not cover
Any commitment to diagnosis, workaround or resolution.

Incident resolution

What it actually measures
Time to restore normal service under the contract's own definition.
What it does not cover
Whatever the exclusions remove — often third-party routes and maintenance windows.

Contract questions

  • Which exclusions apply, and how much of the real failure surface do they remove?
  • How is planned maintenance defined, notified and counted?
  • Whose measurement source is authoritative when the parties disagree?
  • What service credits exist, how are they claimed, and what is the cap?
  • Are specific routes or downstream providers excluded from the commitment?
  • How are material changes to routing, providers or terms notified?
  • What is the support escalation path, and who owns it out of hours?
These are the questions to ask any provider. Flow2FA's own service-level and support terms are confirmed during scoping and contracting.

Use a weighted score rather than a feature count

Feature counts reward the longest datasheet. A weighted score forces you to state what matters for your own flows and to attach each score to a piece of evidence.

Illustrative 100-point starting weights

  • Outcome evidence and observability20
  • Security and abuse controls20
  • Routing and resilience15
  • Integration and provider-model fit15
  • Operations and support10
  • Data protection and contract10
  • Commercial model10
This is an illustrative starting framework, not a universal weighting. Adjust the weights to the risk profile of the flows you are protecting: a recovery-heavy consumer product and an internal privileged-access system should not score the same categories equally.
weighted result = category weight × provider score (0–5) ÷ 5

Outcome evidence and observability

Weight
20
Provider score 0–5
—
Evidence reference
—
Weighted result
—

Security and abuse controls

Weight
20
Provider score 0–5
—
Evidence reference
—
Weighted result
—

Routing and resilience

Weight
15
Provider score 0–5
—
Evidence reference
—
Weighted result
—

Integration and provider-model fit

Weight
15
Provider score 0–5
—
Evidence reference
—
Weighted result
—

Operations and support

Weight
10
Provider score 0–5
—
Evidence reference
—
Weighted result
—

Data protection and contract

Weight
10
Provider score 0–5
—
Evidence reference
—
Weighted result
—

Commercial model

Weight
10
Provider score 0–5
—
Evidence reference
—
Weighted result
—

Total

Weight
100
Provider score 0–5
—
Evidence reference
—
Weighted result
—

Twenty questions to send before a demo

Send these before the first call. The answers, or the gaps in them, will shorten the shortlist faster than any demo.

  1. Which integration interfaces are documented today, and can we see the public reference rather than a summary?
  2. Which countries and operators are in scope for our specific markets?
  3. Which routes carry our traffic in those markets, and how are route changes notified?
  4. Which channel values are documented publicly, and which are configuration-dependent for our account?
  5. Can we use your routes, our own providers and SMPP binds, or a mix of both?
  6. What triggers fallback, is it automatic or manual, and does it change assurance?
  7. Can we see a sample attempt-level export and the field dictionary that defines it?
  8. How is verification completion calculated, and which denominator is used?
  9. What are the defaults and configurable ranges for code length, lifetime, single use and attempt limits?
  10. What controls exist for artificial traffic, destination abuse and rate limiting?
  11. Which data elements are retained, for how long, and how is deletion carried out?
  12. Who are the subprocessors, and how are changes to that list notified?
  13. What is the contractual support coverage, and who owns escalation out of hours?
  14. Can you share a redacted incident report and describe how it was communicated?
  15. How would you structure a pilot for our volumes, and what evidence would it produce?
  16. What exactly does the SLA measure, and which exclusions apply?
  17. How is pricing structured across primary attempts, retries and fallback?
  18. Which pass-through, registration and template charges apply in our markets?
  19. What setup is required for SMPP or a VPN, and what charges and lead times apply?
  20. What happens on termination — what can we export, and what assistance is provided?

How Flow2FA maps to this guide

Applying the framework to Flow2FA itself: the left column is what the public documentation supports today, and the right column is what depends on your configuration and must be confirmed during scoping.

Publicly documented now

  • Two documented public REST endpoints: /otp/generate and /otp/validate.
  • otpId is returned at generation and presented again at validation.
  • SMS and email are documented public REST channel values.
  • The public REST generate request requires a provider value: the account-configured provider or delivery-profile value issued during onboarding for that channel. Credentials stay server-side, documentation examples are illustrative, and whether a permitted value maps to one underlying vendor or an account-specific managed routing arrangement is confirmed during setup.
  • Automatic provider switching, overriding of the submitted provider value and universal fallback are not documented behaviours; retry and fallback apply only where configured for the account.
  • SMPP v3.4 is available as an integration option for existing messaging platforms.
  • Delivery can use Flow2FA-supplied routes, customer-owned providers and binds, or a hybrid of both.
  • Flow2FA is an OTP delivery and verification layer — not an identity provider, KYC or identity-proofing service, fraud engine, passkey replacement, 3-D Secure replacement or a delivery guarantee.
  • The SMPP connection form is requested from devs@flow2fa.com.
  • A VPN form may also be required, and a VPN may involve a setup charge and implementation lead times.

Confirm during scoping

  • The exact countries, operators, routes and sender registrations for your markets.
  • Whether WhatsApp is configured for your account; it is not currently a documented public REST channel value.
  • Which reporting fields, dimensions and exports are available for your configuration.
  • Support coverage and escalation terms.
  • The commercial model, including pass-through charges.
  • Provider configuration: Flow2FA routes, your own providers and binds, or a hybrid.
  • Pilot design and the success criteria you want it to test.
  • Whether a VPN is required, and the associated charge and implementation lead time.
  • Contract terms, the data-processing agreement and the security evidence available.

Details of the documented surface are in the OTP API overview and the API documentation.

Red flags in provider conversations

None of these are automatically disqualifying, but each one should change what you ask next.

  • Guaranteed delivery

    No provider controls every operator, handset, mailbox and filter in the path. A delivery guarantee is either a redefinition of the word or a term with exclusions you have not read yet.

  • Delivery receipts presented as verification

    A receipt is a network event. It says nothing about whether a person read the message or entered the code. Ask for completion figures with a stated denominator.

  • Only global averages

    A blended figure across every market hides the countries where you actually lose users. Ask for the breakdown for your own markets before believing the headline.

  • No route or provider attribution

    If an attempt record cannot tell you which route or provider carried it, you cannot diagnose a regional failure or hold anyone to account for it.

  • Hidden fallback

    Fallback that is not recorded per attempt makes both your reporting and your assurance posture untrue. You need to know the flow moved and that the alternate path was approved.

  • A shared underlying route sold as independent resilience

    Two logos on a diagram are not two paths. If both converge on the same aggregator, sender registration or operator connection, one failure removes both.

  • No duplicate or stale-code controls

    Without clear rules on resend, expiry and single use, a busy flow will present users with several live codes and give attackers a longer window.

  • No clear recovery or factor-change policy

    Recovery is a common target because it can bypass the normal sign-in factor. A provider with no view on it has not addressed one of the highest-risk parts of the journey.

  • No sample export or field dictionary

    If you cannot see the fields before contracting, you will discover the missing dimension during your first incident.

  • A headline price excluding retries, fallback and pass-through charges

    The unit price of the first attempt is not the cost of a completed verification. Insist on a worked example against your own volumes.

  • Security or compliance claims without evidence

    A claim that cannot be supported by a document, a policy or a demonstrable control is a marketing statement, not a control.

  • No named operational owner

    When a route degrades at 02:00, an anonymous inbox is not an escalation path. Get a name, a role and a defined out-of-hours route.

Bring evidence into the buying decision

Bring your use cases, main countries and operators, current providers, monthly and peak volumes, code lifetime, resend rules, fallback policy, verification data and security requirements. Use the framework above to compare every provider — including Flow2FA — against the same evidence.

For flow-specific detail, see login authentication, transaction verification and account recovery.

Review your OTP setupTalk to salesRead the API documentation