Which banks accept a VOIP number for verification codes
One of the three US banks we read rules VOIP and Wi-Fi numbers out in writing; the other two do not address the question on the pages we could reach.
Checked against official pages on September 27, 2026. Rules move; when this one does, it goes on the changelog.
Do banks accept Google Voice numbers for verification? Forums answer from anecdote; banks answer, when they answer at all, in one sentence buried in a troubleshooting list. Three banks publish something about the kind of number a code can be sent to, and the three positions differ in a way worth knowing before a trip rather than during one.
What the three banks publish
Capital One answers it directly, and negatively. Its one-time PIN support page states the requirement and then the exclusion in consecutive sentences: "in order to receive a code, you will need to have a US mobile phone number registered to your name on file. VOIP- or Wi-Fi- based services are not eligible to receive a code."
That is the clearest published position we found, and it is worth quoting exactly because it is a rule rather than a report: the service type is not eligible, which means no message is attempted.
Bank of America addresses the number's origin rather than its technology. Its Security Center requires "a U.S. based mobile number" for Secured Transfer and states "we do not support international phone numbers at this time". Its one-time authorization codes go out "by text or email" with no mention of the underlying line type. A VOIP service with a US number is not addressed on that page either way.
Chase publishes two verification settings, an email option and app notifications, on its Security Center page, and that page we read says nothing about VOIP numbers.
What that adds up to
Of the three banks, one publishes a rule about VOIP numbers, and it is a refusal. The other two leave the question alone on the pages we read, and "the page we read does not say" is the whole of what can be reported about them: a bank's silence in a troubleshooting article is not a policy, in either direction.
This is why forum threads on the subject disagree so much. A report that a bank accepted a Google Voice number is a report about one account, one date and one review process; a report that it refused is the same shape. Neither is a policy statement, and the bank is under no obligation to keep answering the same way.
The structural reason behind the refusals
A VOIP or Wi-Fi number is not a SIM in a handset, and the checks that matter to a bank can see the difference. A sending platform can look up what kind of number a message is addressed to before deciding to send, which means a refusal at this layer produces no trace: nothing appears in a message log, because nothing was sent.
That is the same mechanism as the first layer in why OTP SMS fails abroad, and it is the reason the eligibility question is worth settling before a trip rather than during one. It also explains why the alternative channels the banks publish avoid the question entirely: an app notification or an email code does not care what kind of telephony the account's number belongs to.
What to do with this
- If your account's number is a VOIP or Wi-Fi service and your bank is Capital One, the published answer is that codes will not be sent to it. The bank publishes app-based verification as a path that does not use the number at all; it is described on its card.
- If your bank is one of the two that do not address the question, treat the answer as unknown rather than as permission, and test it while you can still reach support easily.
- A carrier-issued mobile number is the type all three banks accept for code delivery, which puts the question back with the number itself: what happens to it while you are away is on hold, park, port or let go.