LAAFFIC Flashcall Implementation Guide

LAAFFIC documents a standard Flashcall, not a reverse call or a Voice OTP flow.

The service places a one-to-three-second call, disconnects automatically, and uses the final four to six caller-ID digits as the code. The user does not answer. A supported Android app can read the call log and fill the code. LAAFFIC says most checks finish within five seconds, but the target countries and carriers should be tested before launch.

Standard Flashcall

• the service calls the user;
• the call rings for one to three seconds and ends automatically;
• the user does not answer;
• the final four to six caller-ID digits carry the code;
• a supported Android app can read the call log and fill the code.

Reverse flash call

• the user calls a service number;
• the system identifies the incoming number;
• this may suit flows that need to avoid reading incoming call logs;
• do not assume LAAFFIC supports this model unless it confirms so.

Voice OTP

• the service calls the user;
• the user answers;
• a recorded or generated voice reads the code;
• the user normally enters it manually.

Client-side flow

1. The user enters a phone number

2. The client validates the country code and number format

3. The user requests verification

4. The screen shows that Flashcall is in progress and says not to answer

5. On a supported Android device, the app reads the call log and fills the code

6. If auto-detection is unavailable, the flow moves to manual entry or a backup channel

7. After success, the app creates the session, completes sign-up, or continues the original action

Server-side flow

1. Create a verification session

2. Generate a unique business request ID

3. Send the Flashcall request to LAAFFIC

4. Store session state, a masked number, expiry, and channel data

5. Receive call status through the FlashCall webhook

6. Bind the result to the right user, device, and business session

7. Handle success, failure, timeout, and fallback consistently

8. Write audit and risk events

The API section below lists LAAFFIC’s official request and callback fields. The following are suggested fields for your own verification-session model; they are not LAAFFIC request parameters:

verification_session_id
masked_phone_number
channel
status
expires_at
retry_count
fallback_channel
risk_result

A useful state model should include at least:

CREATED
REQUESTED
RINGING
AUTO_DETECTED
MANUAL_INPUT_REQUIRED
VERIFIED
TIMEOUT
BLOCKED_OR_UNDELIVERED
FALLBACK_TRIGGERED
FAILED
EXPIRED

• CREATED: the user submitted a number, but no provider request has succeeded yet. Run format, block-list, and rate-limit checks here.
• REQUESTED: the provider accepted the request, but no final result has arrived. Use a server-side timeout so sessions do not remain open indefinitely.
• RINGING: LAAFFIC’s webhook includes ringingTime; a non-null value indicates ringing. The public callback exposes final flashCallStatus values of 0 or 1, so intermediate states remain your responsibility.
• AUTO_DETECTED: the Android app found a call-log entry and extracted the final digits that match the active session.
• MANUAL_INPUT_REQUIRED: the app cannot read the log, the device does not support it, or the flow requires a manual step. Do not record this as a provider failure.
• VERIFIED: the code or caller number matches an unexpired, unused session.
• TIMEOUT: verification did not finish within the chosen window. This can trigger SMS or Voice OTP, subject to fallback limits.
• BLOCKED_OR_UNDELIVERED: the call appears to have been blocked, missed, or left unmatched. This needs provider events or a carefully defined internal timeout rule.

A conservative default

1. Place one Flashcall.
2. Wait briefly for automatic detection or a verification result.
3. Allow one controlled retry after timeout.
4. If the check still fails, offer SMS or Voice OTP.
5. Send repeated failures, bursts, and high-risk behavior into the risk workflow.

Do not retry without a limit

Unlimited retries can lead to:

• several unfamiliar calls reaching the user;
• stronger carrier or device blocking;
• higher provider charges;
• resource-exhaustion abuse;
• users believing their account is being targeted.

Rate-limit by phone number, device, IP, account, and business action, and distinguish a normal retry from suspicious repetition.

Fallback is a policy, not just a switch

Build a channel policy for each market:

Do not promise that Flashcall “bypasses all SMS filtering.” It uses the voice route and avoids some SMS-specific problems, but local carriers, regulation, device settings, and call blocking still matter.

LAAFFIC says an Android app can read the call log, fill the code, and complete verification. Engineering still needs to settle:

• the exact app permissions;
• supported Android versions;
• manufacturer-specific call-log restrictions;
• fallback when the user denies permission;
• matching logic on dual-SIM devices;
• caller-number normalization and country-code handling;
• matching when several calls arrive close together;
• behavior in the background, on the lock screen, and in battery-saving modes.

LAAFFIC is explicit about the iOS limitation: the app cannot read the call log as it can on Android. The user must check recent calls. Design iOS around manual entry and a clear fallback rather than presenting it as zero-tap verification.

• tell the user not to answer and to check the recent-call number;
• provide a clear field for the final four to six digits and useful error messages;
• move to SMS or Voice OTP after the business-defined timeout;
• do not apply LAAFFIC’s app auto-read description to a browser-only flow;
• test across iOS versions, Focus modes, Silence Unknown Callers, and blocking settings;
• define what happens if the user answers, ignores, or blocks the call;
• measure manual success, timeout, fallback, and iOS conversion separately.

Clear copy reduces accidental answers, rejected calls, and confusion.

A useful prompt

Wording to avoid

• “Answer the call to get your code.”
• “Flashcall can never be blocked.”
• “Verification is automatic on every phone.”
• “The app reads call logs without any permission.”
• “Flashcall is more reliable than SMS in every country.”

If a device cannot detect the call automatically, show a manual-entry action and explain the fallback instead of leaving the user on an endless loading screen.

Flashcall checks control of a phone number; it does not complete the entire identity decision. At minimum, the server should implement:

• Session binding: bind the code to the phone number, business session, device, or login request. Never validate a bare digit string in isolation.
• Expiry: give both the code and session a short lifetime and invalidate them immediately after success.
• Idempotency: network retries, repeated taps, and duplicate webhooks can process the same event more than once. Use a business request ID and idempotent handlers.
• Rate limits: apply limits by number, account, device, IP, country/carrier, business action, and time window.
• Risk signals: combine the result with IP reputation, device intelligence, proxy and emulator detection, number history, behavioral speed, and account risk.

Flashcall can support payment confirmation and sensitive profile changes, but it should be treated as proof of phone-number control—not the only strong authentication factor.

• Known low-risk device: continue after a successful Flashcall.
• New device or suspicious IP: add push approval, another factor, or manual review.
• High-value payment: require a transaction password, device confirmation, or stronger authentication.
• Repeated failure: pause retries and send the case to risk review.
• Recently changed number: delay sensitive actions or require an additional check.

The exact assurance level should follow the business risk assessment.

Functional tests

• a valid number can start verification;
• an invalid country code is rejected;
• the final caller-ID digits match correctly;
• a wrong code never passes;
• an expired session cannot be reused;
• repeated taps do not create several active sessions;
• the code becomes invalid immediately after success.

Device tests

• different Android versions and manufacturers;
• dual-SIM, lock-screen, and background states;
• call blocking enabled and call-log permission denied;
• iOS manual entry and fallback.

Network and carrier tests

• different countries, carriers, and times of day;
• roaming, low signal, and delayed calls;
• undelivered calls and calls answered by mistake.

Security tests

• high-frequency and concurrent requests;
• code replay and duplicate webhooks;
• session hijacking and phone-number enumeration;
• forced SMS fallback and rotating device/IP attacks.

Break metrics down by country, carrier, device, operating system, and business journey:

• Flashcall requests and observed ringing/delivery;
• automatic and manual verification success rates;
• average and P95 verification time;
• timeout, fallback, retry, and answer rates;
• risk-block rate and total cost per successful verification;
• registration or login completion rate.

The public send endpoint is POST https://api.laaffic.com/v3/voice/flashcall. Request headers include Content-Type: application/json;charset=UTF-8, Sign, Timestamp, and Api-Key.

{
  "appId": "rtnrc",
  "callee": "639191700000",
  "maxRingingTime": 15,
  "flashCallValidDuration": 30
}

• appId: required; the voice application ID.
• callee: required; country code plus mobile number, 7–18 digits.
• maxRingingTime: optional; maximum ringing time, default 60 seconds, range 1–120.
• flashCallValidDuration: optional; validity window, default 60 seconds, range 30–600. The call is abandoned if it has not been placed before this expires.

A successful response contains status: "0", reason: "success", and data.voiceId. Published error codes cover authentication (-1), IP restriction (-2), expired timestamp (-16), system error (-18), duplicate data (-20), invalid parameters (-22), data limits (-23), workspace mismatch (-63), and account-manager intervention (-75).

Once the Voice - FlashCall Callback URL is configured, LAAFFIC sends an HTTP POST array with voiceId, callee, displayNum, submitTime, callTime, ringingTime, and flashCallStatus (0 for success, 1 for failure). Return HTTP 200, and implement your own source validation, deduplication, replay protection, and idempotent handling.

The product deck’s POST /v1/misscall/verify is an orchestration example, not the current public endpoint. Use /v3/voice/flashcall from the API center. Flashcall is invoked explicitly by your business logic; SMS and Voice OTP can switch at the platform layer, while the point at which Flashcall falls back is set by your rules.

Before production, confirm account-level details with LAAFFIC:

• signature generation, key rotation, IP allow-listing, and webhook source validation;
• rate limits, concurrency, idempotency, retryable errors, and retry caps;
• sandbox access, test numbers, test credit, and billing/usage APIs;
• market-specific Flashcall-to-SMS/Voice timeout; the deck’s eight seconds is a suggested example;
• logging, retention, masking, deletion, and local compliance.

Before launch, product, engineering, security, operations, and procurement should agree that: