"No OTP was sent at payment" has become one of the most-discussed questions arising from the recent Apple pre-order incident.
For an IT team, the question genuinely worth asking is not whether every single transaction should carry an additional verification step. It is this:
- － When the system does not request an OTP, what control is still judging whether this transaction is trustworthy?
- － When a business lowers one security control for the sake of a smoother experience, which control takes over?
What Does the Apple Incident Reveal?
Following the opening of iPhone 18 pre-orders, Hong Kong Police stated that as of 5pm on 14 September, 1,209 reports had been received concerning suspected unauthorised credit card transactions related to iPhone purchases, involving approximately HK$25 million. Police said the online pre-order transactions in question did not require a one-time SMS verification code (OTP) or any other authentication method, and the payment process could be completed without cardholder confirmation. This means that if fraudsters already hold leaked credit card details, they may be able to attempt the transaction directly.
Source: RTHK News, 14 September 2026
The Hong Kong Monetary Authority has also pointed out that individual merchants may, for operational reasons, choose not to use or to suspend additional authentication arrangements such as app-based authentication and one-time passwords. In such cases, the merchant bears liability for unauthorised transactions and the associated financial losses.
Source: Now News
We also had a recent client case. The client disabled CAPTCHA in order to make online registration smoother, and the result was a large volume of automated BOT requests and order submissions. After the problem was resolved, the team again became concerned that verification was affecting the user experience, so CAPTCHA was disabled once more, and the same kind of BOT activity reappeared.
The two cases involve different controls, but they reflect the same management blind spot:
Businesses treat a security control as having only two settings, on or off.
First, Separate What Each Control Actually Does
Below are the more common protective measures. Each addresses a different problem, and they are not interchangeable. If an event involves login, registration, limited quota and payment at the same time, several layers of control may need to operate together.
CDN / DDoS protection
- － Problem it addresses: absorbing, filtering or distributing large volumes of traffic at the network edge.
- － Risk when disabled or insufficient: sudden traffic surges may reach the website and application servers directly, causing instability or outage.
CAPTCHA
- － Problem it addresses: requiring the user to complete an additional challenge, raising the cost of automated BOT operations.
- － Risk when disabled or insufficient: BOTs can more easily register, log in, sign up or place orders in bulk, seizing quota and inventory ahead of real customers, while also increasing back-end processing load.
Behavioural BOT detection
- － Problem it addresses: identifying suspicious activity from request patterns, browsing paths, devices and operational behaviour.
- － Risk when disabled or insufficient: slower BOTs, or those imitating real users, may continue to pass through, concentrating automated abuse on high-value flows such as registration, inventory, promotion codes or payment.
Rate limiting
- － Problem it addresses: restricting the request frequency of a single IP, account or device.
- － Risk when disabled or insufficient: large or repeated requests can flood in within a short period, consuming application, API, database and third-party service resources, increasing latency, errors and the risk of service abuse.
Queueing mechanism / virtual waiting room
- － Problem it addresses: controlling the simultaneous entry of large numbers of real users.
- － Risk when disabled or insufficient: many users triggering login, queries or writes at once may push applications and databases beyond capacity, causing latency, errors, failed transactions or service interruption.
OTP / 3-D Secure / app authentication
- － Problem it addresses: verifying payments or high-risk account operations.
- － Risk when disabled or insufficient: stolen credit cards, accounts or payment details may be used to complete operations without immediate cardholder confirmation, increasing unauthorised transactions, chargebacks and financial liability.
High-Traffic Events Need Traffic Triage First
Learning from the incident, when handling high traffic we should not only ask "how much traffic is there", but first determine the type of traffic:
- － Large numbers of real users entering normally within a short period.
- － Repeated bulk requests from the same group of devices or IP addresses.
- － Requests whose speed and flow are highly uniform, clearly driven by automated software.
- － BOTs deliberately slowing down to imitate real users, but concentrating on registration, quota, inventory or order-submission steps.
The first is mainly a capacity and queueing problem. The remaining cases are closer to BOT activity or process abuse, and cannot be handled by adding server capacity alone.
Rate limiting can restrict, for example, "how many submissions each IP may make per minute", but it is not complete BOT protection. BOTs can spread across a large number of IP addresses, deliberately slow down, or concentrate on a single high-value step such as grabbing quota, validating a promotion code or submitting an order.
Rate limiting should therefore be used together with account, device, session and behavioural signals, rather than serving as the sole replacement after CAPTCHA has been disabled.
If large numbers of real users arrive at once, the following are worth considering:
- － A virtual waiting room, combined with queueing and batched release.
- － Batched release with a defined number of users per batch.
- － Server-side locking on inventory, quota or submission buttons.
- － Deferring non-essential functions so that not every request triggers a database write at the same time.
- － Dedicated monitoring metrics for the event, such as request rate, error rate, login failure rate and successful submissions per minute.
Quota, inventory, discount codes and payment conditions cannot rely on hiding a front-end button or displaying a CAPTCHA. Front-end controls can only improve the interface flow; they do not constitute genuine access control, and the server side must still re-verify.
Concentrate the Challenge on High-Risk Users
The better approach is not to show CAPTCHA to everybody, but to assess risk in the background. Signals worth watching include:
- － New devices or new accounts.
- － Repeated account creation or form submission within a short period.
- － One device switching rapidly between multiple accounts.
- － Large volumes of requests concentrated on quota, inventory or payment steps.
- － Unusual combinations of geolocation or usage patterns across IP, device and account.
- － Payment details, delivery details or transaction behaviour that suddenly depart from past patterns.
Low-risk users can proceed through the normal flow. Only higher-risk users need CAPTCHA, OTP, 3-D Secure, app authentication, delayed processing or manual review.
This does not mean every security control must be enabled for every user. It means the system should automatically add defence as risk rises, so that the team is not left choosing between "everything on" and "everything off".
Five Questions to Ask Before Disabling a Control
The next time somebody proposes "let us disable CAPTCHA first" or "let us not trigger OTP for now", the IT team can confirm the following:
1. Which risk are we handling this time?
Is it BOTs, DDoS, excessive traffic, account abuse or unauthorised transactions? Different risks cannot be handled by the same control.
2. Which control takes over once this one is disabled?
Is it behavioural BOT detection, device risk scoring, a queueing mechanism or some other transaction risk analysis? If there is no substitute measure, an existing control should not be disabled purely for the sake of a smoother experience.
3. Which behaviours will trigger an additional challenge?
For example repeated submission within a short period, one device switching between multiple accounts, concentrated attacks on a specific flow, or payment patterns that suddenly become abnormal.
4. How do we confirm the control is actually working?
Do we have data such as BOT hit rate, false positive rate, request origin, successful order rate, OTP trigger rate, OTP exemption rate, verification failure rate and abnormal error rate?
5. Who can approve the change, and when is it restored?
Does the suspension have a defined end date? Will it be re-enabled automatically when the event finishes, traffic drops or the anomaly rate rises? Does it require joint approval from IT, business, risk or the system owner?
If these questions have no answers, the team is not optimising the user experience. It is accepting an unassessed risk.
A mature design is not simply about adding more verification. It is about placing fewer obstacles in front of low-risk users, while high-risk behaviour is delayed, verified or blocked, with sufficient monitoring and recovery capability retained throughout.
Before the Next High-Traffic Event
Before the next high-traffic event begins, the IT team may wish to ask:
If we switch this control off, which control takes over?
If there is no immediate answer, it is worth running a Security Health Check or a pre-event technical review first, covering BOT protection, traffic control, OTP and 3-D Secure trigger logic, monitoring metrics and change-rollback arrangements, to confirm whether the system can genuinely withstand both high traffic and high-risk behaviour at the same time.
CAPTCHA handles BOTs, OTP handles high-risk transactions, rate limiting controls request speed, and a virtual waiting room controls peaks of real users. If one of these controls is dialled down, the IT team must know which control takes over.
Security and a smooth experience were never an either-or choice. They are a design problem, and one worth having someone work through with you layer by layer. We understand AI. UD stands with you.
If you cannot yet answer "which control takes over once this one is switched off", that is precisely the moment a review is worth doing. UD has stood with Hong Kong businesses for 28 years, and we will walk you through every step, from BOT protection, traffic control and OTP or 3-D Secure trigger logic to monitoring metrics and change-rollback arrangements, confirming item by item whether your system can hold up at the next peak.
Reviewed by the UD cybersecurity team, Hong Kong. Published 15 September 2026.
