Use case
OTP for high-risk e-commerce actions
Add step-up verification to selected checkout and account events without challenging every customer or replacing payment-network controls.
What the flow must protect
What the OTP shows
- The shopper completing the action currently controls the destination held on the account.
- The otpId your application stored on that order or account change was validated once.
- The result can be written into the order and fraud history for later review.
What it does not show
- That the payment is authorised. Issuer authentication, 3-D Secure and scheme rules are separate and still apply.
- That the order is not fraudulent. A possession check is one signal alongside your fraud screening.
- That PCI DSS obligations are met. Flow2FA delivers and verifies codes; it does not handle your card data scope.
Where the flow breaks
Challenging every order
Blanket step-up adds friction to the majority of legitimate checkouts and costs conversion for very little fraud reduction.
Codes arriving after abandonment
Checkout is measured in seconds. A code that lands after the shopper has closed the tab produces an abandoned order, not a verification.
Generic challenges not tied to the order
A code that is valid for anything on the account can be harvested in one place and used in another, including a payout or address change.
Fraud engine and messaging data disconnected
When challenge outcomes never reach the fraud system, rules are tuned blind and false-positive challenges go unnoticed.
Expensive international SMS as the only path
One channel priced for a domestic base becomes a poor fit the moment cross-border orders grow.
Checkout risk responsibility map
A step-up code is one control among several that already sit around a checkout. This is what each layer owns, and what Flow2FA does not do.
Flow2FA
- Generating, delivering and verifying the OTP
- Routing across enabled channels and configured fallback
- Attempt and outcome history for the challenge itself
Your application
- Deciding which order or account events trigger a challenge
- Binding the otpId to the specific order or change request
- Committing the order only after the code is verified
Fraud screening
- Risk scoring the order or account event
- Deciding whether step-up, review or block applies
- Tuning rules using challenge outcome data
Payment provider / acquirer
- Payment authorisation and settlement
- Card data handling and PCI DSS scope
3-D Secure / card scheme
- Issuer authentication of the cardholder
- Liability shift rules under scheme mandates
Flow2FA is not a payment-network control and does not replace 3-D Secure, issuer authentication or your fraud screening. It carries and verifies a possession check alongside them.
A production flow
A checkout or account risk event fires
A high-value order, stored-payment change, delivery-address change, gift-card redemption, loyalty transfer or seller payout is flagged.
The merchant decides to step up
Your fraud rules or risk score decide whether this specific event warrants a challenge.
The challenge is bound to the order or action
The otpId is stored against that order or change request in your systems, rather than treated as valid for the account in general.
An approved channel and route are chosen
Channel choice reflects the market, the value at risk and your cost policy.
The action is verified before it commits
The order is placed, or the account change is applied, only after the code is redeemed.
The result is recorded
Outcome, channel and attempts are written into the order and fraud history for tuning and dispute handling.
How Flow2FA fits
Sits beside your existing payment stack
Flow2FA carries and verifies the code. 3-D Secure, issuer authentication, fraud screening and PCI controls stay where they are.
Channel choice per market and per value
Lead with the channel that performs and costs less in a given market, and reserve stricter channel sets for higher-value events.
Controls to define, and what to measure
Controls to define
These are your decisions. Flow2FA carries and verifies the code; the policy stays yours.
- Which events trigger a challenge, and the risk thresholds behind them
- Binding of each code to a specific order or account change
- Code lifetime tuned to checkout timing
- Retry, resend and attempt-limit rules at the checkout step
- Channels permitted per market and per order value
- Whether fallback is allowed mid-checkout, and to which channel
- Cancellation of stale challenges when a basket or order changes
- Retention of challenge evidence for chargeback and dispute windows
What to measure
Measure completed verification, not accepted API calls. Acceptance and delivery receipts are progress indicators, not outcomes.
- Challenge completion rate on issued challenges
- Checkout conversion for sessions that were challenged
- Time from challenge to verification
- Abandonment at the challenge step
- False-positive challenge rate, judged against confirmed fraud outcomes
- Cost per completed verification by route and channel
Integration options
Storefronts and order services usually call REST from the checkout backend. Retail groups running their own messaging platform often prefer to keep SMPP and reuse existing sender identities.
Shared integration detail
REST vs SMPP, the provider model, routing and fallback, and full channel detail are covered once, in full, on the OTP API overview. For how to weigh those choices against your own requirements, see the buyer guide.
Channel availability depends on the setup configured for each account. The current public REST reference documents SMS and email channel values, while configured Flow2FA setups may also include WhatsApp.
Challenge the orders that deserve it
Bring your step-up rules and the markets you sell into. We will look at channel mix, binding and the data you would get back for fraud tuning.