What happens when remote payments rely only on passwords and one-time codes?

Remote payments become easier to abuse because the factors can be weak, interruptive, and vulnerable to device compromise. A password and an OTP may still be captured if the user’s device is infected or if the customer is socially engineered. That leaves merchants exposed to fraud while also increasing friction for legitimate customers during checkout.

Why password plus OTP checkout is still a weak remote payment pattern

A password and one-time code can improve basic account access, but they do not make remote payment flows robust on their own. The weakness is not just the factor count, it is the trust model: if the session, device, or recovery path is compromised, the checkout can still be completed by an attacker who has captured the same factors the customer uses.

That is why payment flows built around passwords and OTPs often shift fraud risk rather than remove it. They may stop only the most trivial attacks, while still leaving room for phishing, SIM swap, malware, session theft, and social engineering. In practice, the control is often strong enough to add friction, but not strong enough to prove the payer is present and uncompromised.

Current guidance increasingly treats phishing-resistant authentication as the better baseline for sensitive remote transactions. For payment teams, the real question is whether the chosen factor resists interception and replay in the customer’s actual threat environment, not whether it satisfies a minimum policy checklist. See the NIST SP 800-63 Digital Identity Guidelines for the role of phishing-resistant authenticators.

How attackers and fraud flows defeat password plus OTP

OTP-based flows fail when the attacker can influence the same human or device path the customer uses. A convincing fake checkout, login prompt, or support call can elicit both the password and the one-time code in real time. Malware on the endpoint can also read messages, intercept push approvals, or steal session cookies after authentication, which means the code authenticates the wrong party.

For remote payments, the most important failure mode is not code guessing but code capture or code reuse. OTPs are short-lived, yet they are still vulnerable to relay attacks, browser injection, device compromise, and help-desk social engineering. The merchant sees a valid authentication event, while the attacker rides the trusted session to approve a fraudulent transaction.

That is why incident patterns around credential phishing remain relevant to payment fraud analysis. The 0ktapus campaign showed how a phishing kit can collect credentials and second factors at scale, which is directly relevant to OTP-based remote payment abuse. See NHIMG’s Twilio 0ktapus breach 2022 for the abuse pattern.

What this means for customer experience, fraud controls, and checkout design

Password plus OTP is often chosen because it is easy to deploy, not because it is the best fraud control. It can raise the attack cost for opportunistic abuse, but it also adds an extra step for legitimate customers, which can increase drop-off and support burden. The security value depends on whether the control is tied to transaction context, device trust, and step-up decisions, or whether it is used as a generic gate for every checkout.

For high-value or high-risk payments, practitioners should look at whether the factor set actually binds the approval to the transaction. If the authentication happens before the payment details are finalised, an attacker may still be able to alter the destination, amount, or beneficiary after login. That is why transaction signing, risk-based step-up, and stronger device-bound authenticators usually outperform raw OTP dependence for remote payments.

When evaluating the control set, merchants should also consider recovery and exception paths. Reset workflows, fallback verification, and call-center overrides are common abuse points, and they can undo most of the protection the password and OTP were meant to provide. The control is only as strong as the easiest path around it.

Risk and Threat Considerations

Remote payments that rely only on passwords and one-time codes create a clear fraud exposure because both factors can be intercepted, relayed, or triggered from a compromised device. The security issue is less about authentication theory and more about how easily the payment flow can be hijacked once the attacker has the same live factors as the customer.

Failure mechanism: Phishing, malware, SIM swap, or social engineering captures the password and OTP, then reuses them inside an active checkout or account session before the customer can notice or revoke the transaction.

Impact: Attackers can complete fraudulent payments, merchants absorb chargebacks and operational cleanup, and legitimate customers experience extra friction, lockouts, or false declines when controls are tightened after abuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	N/A — Digital Identity Guidelines	Remote payment authentication depends on phishing-resistant authenticators and transaction assurance.
Recommendation — Prefer phishing-resistant authenticators for sensitive payment approval and bind auth to the specific transaction.
MITRE ATT&CK	T1556 — Modify Authentication Process	OTP theft and relay commonly abuse or alter the authentication flow.
Recommendation — Hunt for authentication interception, relay, and session abuse across remote checkout paths.
CIS Controls v8	CIS-6 — Access Control Management	Payment abuse is reduced when access and step-up controls are tightly governed and reviewed.
Recommendation — Tighten and review access paths that can approve or bypass remote payment actions.
OWASP API Security Top 10	API2 — Broken Authentication	Remote payment flows fail when authentication can be captured or replayed during checkout.
Recommendation — Validate that payment APIs and checkout endpoints resist credential capture and replay.

Practitioner Guidance

What to prioritise: Treat payment approval as a transaction-integrity problem, not just an authentication problem. The most important control question is whether the authentication method can be replayed or separated from the payment details.

What to verify: Confirm that any step-up factor is bound to the specific transaction amount, beneficiary, and session, and that fallback recovery paths do not bypass that binding. If the same OTP can authorise multiple outcomes, the control is too weak for high-risk checkout.

Common mistake: Using OTPs as the last line of defence while leaving recovery, support, and session handling easier to abuse than the primary login flow.

Practitioner takeaway: For remote payments, the goal is not merely to verify a customer once, but to make sure the approval cannot be stolen, replayed, or detached from the transaction it is meant to protect.