A virtual USD account can look perfect on a product page and still be the wrong account for your next invoice.

The phrase “USD account” does not tell you whether your client can pay it by ACH, whether it accepts domestic wire, whether an overseas client can send a SWIFT transfer, whether a marketplace accepts the details, whether the account is actually in your name, or how much money will be usable after receiving, conversion and withdrawal costs.

For a Nigerian freelancer or remote worker, those details matter more than the account-opening screen.

If you are still comparing providers, start with the 11 things that matter when choosing a dollar account in Nigeria. This guide solves a different problem: you already have ,or are considering, a specific virtual USD account, and you want to know whether it is safe to build a real payment workflow around it.

Before you add new bank details to an invoice, payroll portal or client vendor system, run these 12 checks.

The useful question is:

Can this exact account accept money from this exact payer through the route they intend to use, and can I turn the received balance into usable money afterward?

If your clients are spread across different regions, the guide to receiving payments from US, UK and EU clients in Nigeria explains why the sender’s location often determines the rail you need. If PayPal is the reason you are looking for another route, compare the practical options in How to Receive USD in Nigeria Without PayPal in 2026 before assuming that every USD account solves the same problem.

1. Is the account actually in your name?

Start with the beneficiary name.

When your client opens their payment form, what exact name are they supposed to enter?

Ideally, the provider should make this unambiguous. You should be able to identify:

• the beneficiary or account-holder name;

• whether it uses your personal legal name or registered business name;

• whether the name must match your KYC record exactly;

• whether you can obtain formal proof that the account or receiving details belong to you.

This matters for more than appearance.

A client’s finance team may compare the beneficiary against your invoice, vendor record or contract. A marketplace may apply its own rules about whether payout details must match the account holder. A receiving institution may also need enough information to associate a payment with the correct recipient.

Do not “clean up” or abbreviate the beneficiary name yourself. Copy the current name shown in the provider’s payment instructions.

Also distinguish “details in my name” from “I personally hold a conventional bank account directly with the underlying bank.” Those are not necessarily the same legal structure. Fintech products can provide dedicated receiving details through partner institutions.

The practical test is simple: can you identify the beneficiary, provider relationship and supporting documentation without guessing?

2. What country and institution sit behind the account details?

A USD balance does not tell you where the receiving account is located. For a client paying through US banking, you may receive details such as:

Beneficiary name → bank/provider name → routing number → account number → account type

Another product may instead provide an IBAN or different international instructions.

Check:

This is especially important when a client asks, “Is this a US bank account?”

Do not answer from the marketing name of the feature. Answer from the actual receiving instructions and applicable terms.

Similarly, an IBAN is an account identifier, not proof that every transfer type or currency is supported. walllet.com’s practical guide to its IBAN Account explains why beneficiary, currency, rail, payer type and account eligibility all need to be checked separately.

3. Can the virtual USD account receive ACH?

Some virtual USD accounts support ACH. Some do not. Even when ACH is available, the rules may be narrower than the phrase “ACH supported” suggests.

For freelance income, you normally care about incoming ACH credits: the sender instructs its financial institution to push money toward your receiving account.

Nacha describes an ACH credit as a chain involving the originator, the Originating Depository Financial Institution, an ACH Operator and the Receiving Depository Financial Institution. That is why ACH is a specific payment rail, not another word for “USD transfer.” 

Before giving a client ACH details, confirm:

Incoming ACH credits: explicitly supported or not?
Routing number: is this the routing number for ACH?
Payer type: business only, or can an individual pay too?
Third-party payments: permitted or restricted?
ACH debits: supported separately, or not at all?
Returns: what evidence will you see if an ACH payment is returned?

Do not infer ACH support merely because you see a US routing number.

And do not reuse a routing number from an old screenshot. Payment details can change.

If an ACH payment later comes back to the sender, the ACH return-code guide for freelancers explains what codes such as R01, R02, R03 and R04 mean and who normally needs to fix the underlying problem.

4. Can it receive a US domestic wire?

ACH and domestic wire are separate questions.

A provider can support one without supporting the other. It can also give different routing instructions for each.

The Federal Reserve describes the Fedwire Funds Service as an electronic funds-transfer system used for mission-critical, same-day transactions, with finality at the Federal Reserve participant level. That does not mean every virtual USD account can receive Fedwire payments or that every provider will make a received wire available to you on the same day.

Before accepting a wire, check:

• whether incoming domestic wires are supported;

• whether the wire routing number differs from the ACH routing number;

• whether a bank address or other fields are required;

• whether there is an incoming-wire fee;

• whether the sender must be a business;

• whether cut-off times or reviews affect availability.

This is one of the easiest places to make an expensive assumption.

A client saying “we’ll send a wire” is not enough. You need the wire instructions for your account, not the ACH instructions with the word “wire” added above them.

5. Can someone outside the US send an international wire or SWIFT payment?

A virtual USD account that works beautifully for a New York client may be useless for a company whose bank can only send international SWIFT transfers. US domestic wire support and international wire support are not interchangeable.

If you expect payments from outside the US, find out whether the account has:

• an international incoming-payment route;

• SWIFT/BIC instructions where required;

• an intermediary or correspondent-bank instruction where required;

• restrictions on originating countries;

• a different fee for international transfers;

• rules about who pays intermediary charges.

If the provider publishes only ACH or domestic-wire instructions, do not invent the missing international fields.

That includes SWIFT codes.

Your client's accounts-payable team should use an explicitly supported route, not reverse-engineer one from the bank name.

6. Who is allowed to send money to the account?

This question is routinely missed.

“Can receive ACH” does not mean “can receive ACH from anyone.”

A provider may distinguish between:

The cleanest account is not necessarily the one that accepts the most sender types. What matters is whether it accepts your sender type.

If your three recurring clients all pay from business bank accounts, that is the route to verify first.

If one client pays you personally from an individual account, check that separately.

If your income comes mainly through a marketplace, you have another layer of rules to check.

Check which USD, EUR and GBP receiving routes are available to your walllet.com account before you send new payment instructions to a client.

7. Will the platform or payer actually accept these details?

Technical compatibility and payer acceptance are different things. Suppose your account accepts ACH. That proves the receiving side can handle a supported ACH payment.

It does not prove that:

• Upwork will let you save those account details;

• a payroll platform supports that account country;

• PayPal will permit withdrawal to that account;

• a client's vendor portal accepts the institution;

• the payer accepts fintech-issued receiving details;

• the payer accepts accounts belonging to individuals rather than businesses.

The sender controls its own payout rules.

For platform income, start inside the platform. Check which payout methods are available to your account, country and profile, then check whether the receiving details meet that method's requirements.

If you are deciding whether the whole payment route should start with PayPal, Payoneer, Wise, a bank-style receiving account or stablecoins, the PayPal vs Payoneer vs Wise vs stablecoins comparison for freelancers gives that broader decision context.

For direct clients, ask the finance team one useful question before invoicing:

Can you pay these exact details through this exact payment method?

That is much better than asking, “Can you pay me in dollars?”

8. What do you actually hold after the payment arrives?

“Client sent $1,000” and “I now have $1,000 I can use as USD” are not automatically the same statement. Check what happens after settlement. Does the product:

• credit a USD-denominated balance?

• automatically convert the incoming money?

• require another transfer before the balance becomes usable?

• convert bank-received funds into a different supported balance?

• allow you to keep the value in USD until you choose otherwise?

Then ask what you can do with that balance. Can you:

hold it in USD?
send USD elsewhere?
spend from it?
fund a card?
convert only part of it?
cash out the rest to naira?

This distinction matters for freelancers with dollar-denominated expenses.

If you receive $2,000, need ₦-denominated money for rent and also need $200 for software subscriptions, automatically converting everything to naira may create another conversion later when you need dollars again.

The useful unit is not just “money received.”

It is money received in a form you can actually use for the next step.

9. What does the complete route cost?

A virtual account advertised as “free” can still be an expensive payment route. Separate the costs instead of putting everything under one vague word: “fee.”

A useful comparison is:

Invoice amount
− receiving costs
− applicable conversion/FX costs
− withdrawal or spending costs
= final usable money

Do not mix one-time setup fees with fees charged on every payment.

A current walllet.com example

walllet.com's Bank Account pricing lists a $5 issuance fee and a 1% fee on incoming USD through the supported bank route. Its published off-ramp fee is 0.5% as a separate later step. 

For an illustrative $1,000 payment:

Incoming USD: $1,000
1% receiving fee: −$10
Balance after receiving fee: $990

If the full $990 is subsequently off-ramped:

0.5% of $990: −$4.95
Amount before the effect of the USD/NGN exchange rate: $985.05 equivalent

The $5 issuance charge is a separate one-time account cost; it should not be deducted from every future $1,000 payment.

This example is not an industry average and does not establish walllet.com as the cheapest route. Its purpose is to show why fees must be assigned to the stage where they actually occur.

10. Do the limits fit your real income?

An account can work perfectly for a $50 test and still be unsuitable for a $4,000 monthly contract.

Before moving recurring income, check the limits that apply to your own verified account.

Look for:

per-transaction limit — can one normal invoice fit?
daily incoming limit — can two clients pay on the same day?
monthly limit — does it fit your normal revenue?
withdrawal/cash-out limit — can you move the amount you actually need?
card limit — if spending is part of the route, is it adequate?
verification tier — do higher volumes require additional verification?

Also separate a limit from a review.

A payment below the stated limit may still require compliance or source-of-funds checks. A larger or unusual payment may need supporting evidence even if the account technically permits the amount.

For freelance income, keep documents that explain the transaction naturally:

• invoice;

• client or employer name;

• contract or project record;

• payment reference;

• currency and amount;

• date;

• relevant platform or payroll record.

The point is not to create a folder full of documents nobody asked for. It is to be able to explain why the payment exists if a legitimate review occurs.

11. What is your exit path?

Do not choose a receiving account before deciding what you want to do after the money arrives. For one freelancer, the route may be:

US client → virtual USD account → hold USD → spend online

For another:

US client → virtual USD account → convert only what is needed → Nigerian bank

For another:

Client → USD account → send USD elsewhere

Those are different products, even if the receiving screen looks identical. Before depending on an account, confirm at least one practical route from receipt to final use. Ask:

Can I hold the balance? If yes, in what form?
Can I convert to naira? What rate and fee are shown before confirmation?
Can I withdraw to my Nigerian bank? Which banks/accounts are supported, and what limits apply?
Can I spend the USD? Is there a card, and is card eligibility separate from receiving-account eligibility?
Can I transfer USD out? If that matters to you, is it actually supported?
What happens if the receiving feature is discontinued?
What is the process for moving the remaining balance?

A payment route is incomplete until there is a usable exit.

12. What proof and support will you have when something goes wrong?

The real quality of a receiving account often becomes visible after the payment does not go as expected. Before you need support, check what evidence the product gives you. Useful evidence may include:

• account confirmation or proof of account details;

• downloadable statements;

• incoming transaction records;

• payer or sender information where available;

• payment reference;

• transaction or transfer identifier;

• status history;

• fee record;

• return or rejection information;

• a documented support channel.

Then check whether support can answer route-specific questions. “Payment missing” is not enough information. A useful support case looks more like:

Expected amount: $1,250
Currency: USD
Payer: ABC Company
Method: ACH credit
Date sent: August 31
Reference: INV-1042
Current status: Not credited
Sender evidence: Available
Current account details checked: Yes

That gives support something to investigate.

The five-minute virtual USD account test

Before routing a meaningful invoice to a new account, you should be able to fill this out without guessing:

If several answers are “I assume so,” the account is not ready to receive your main income yet.

A small test payment can verify part of the operational route when the payer is willing and the transfer cost makes sense. It cannot prove that every future amount, payer or transaction will receive identical treatment.

How the checklist applies to walllet.com today

walllet.com says eligible users can receive USD, GBP and EUR account details in their own name, with clients, employers and supported platforms paying through the receiving route shown in the app. The site also says supported users can retain income in USD and use available spending and naira-conversion routes.

There is an important legal/product distinction: walllet.com is a financial technology company, not a bank. Accounts, cards and payments are provided through licensed partners.

That means the same 12-check discipline still applies.

Do not infer that a walllet.com USD account supports ACH, domestic wire, SWIFT or a particular platform merely from the words “USD account.” Use the exact currency, beneficiary, receiving rail and payer instructions currently shown for your account. The company's own current IBAN guidance also states that exact currency, rail, eligibility, fees, limits and review rules can depend on the account.

That is the right standard for any provider: the current payment instructions beat an old screenshot, launch announcement or another user's account.

Red flags to notice before your client pays

A virtual dollar account deserves another look if:

• the product says “receive dollars from anywhere” but never explains the supported rails;

• you cannot identify the exact beneficiary name;

• ACH and wire are used interchangeably;

• international wire is implied without actual SWIFT instructions;

• the headline fee is clear but conversion and withdrawal costs are not;

• payer restrictions are missing or vague;

• you cannot find your limits;

• platform compatibility is based only on an old social post or somebody else's experience;

• there is no clear statement or transaction record;

• the only support instruction is effectively “contact us” with no way to provide a payment reference;

• you cannot explain how to get the money out after receiving it.

None of those points automatically proves a provider is unsafe. They mean you are still missing information required to use the route confidently.

A payment product should reduce uncertainty before the client sends money, not require you to discover its rules after the transfer has already left the sender's account.

Build your income route around what you actually need: receive supported global income, hold USD, spend online and cash out to naira with walllet.com.