Your client says the money was sent. Your account shows nothing. At this point, the most useful question is not “How do I make support respond faster?”
It is “Which part of the payment can we prove happened?”
A missing payment, rejected transfer, pending review, incorrect destination and card refund are different problems. Each needs different evidence. Identifying the last confirmed event can prevent duplicate transfers, unnecessary account changes and wasted support requests.
Start with the payment’s actual status
A payment can be described as pending, sent, processing, completed, rejected or returned.
Those labels are not always standardized across providers.
Instead of relying on one label, compare what the sender can prove with what the recipient can see.
Evidence | What to check next |
Sender has no formal receipt | Confirm that the payment was initiated |
Sender has a receipt but no delivery confirmation | Identify the payment network and reference |
Provider says “Under review” | Check whether documents or compliance information are required |
Bank says “Returned” | Get the return reason before resending |
SWIFT payment has a UETR | Request a trace through the relevant institution |
Stablecoin transfer has a hash | Verify token, address and network on-chain |
Merchant says a refund was approved | Check whether the refund was actually submitted |
A screenshot of “Payment sent” may be useful, but the transaction reference usually provides stronger information for an investigation.
Build the evidence before contacting support
Prepare one record that contains:
Payment amount and currency
Sender and recipient names
Payment method
Date and time, including timezone
Account details used
Transaction reference
Current status on both sides
Relevant invoice, agreement or payout statement
Actions already taken
Only send sensitive documents through authenticated, official support channels.
When an ACH payment fails
ACH is the US Automated Clearing House payment network. When an ACH transaction is returned, the return code helps identify the problem. Examples from Nacha’s published return-code definitions include:
ACH code | Meaning |
R01 | Insufficient funds |
R02 | Account closed |
R03 | No account or unable to locate account |
R04 | Invalid account number structure |
These definitions do not replace the bank’s actual investigation. Different ACH transaction types can have different return conditions and timing rules.
If a payment was returned because the account details were incorrect, correct them only after verifying the right account and receiving route. If the payment was rejected for another reason, changing the numbers alone may not solve it.
When an international wire is missing
For SWIFT payments, ask the sending institution for the relevant transaction details.
SWIFT’s Unique End-to-end Transaction Reference, or UETR, is a standardized 36-character identifier used to help track payment messages. A receiving bank or provider may use that reference to investigate the transaction.
Do not assume that possessing a UETR means the money has arrived. Request the current payment status, beneficiary information used and any available trace or return details.
Modern cross-border bank messaging may use ISO 20022 records, so it is more useful to request the available trace documentation than to insist that every bank supply one particular legacy document format.
When a card refund is missing
A card refund passes through a different process from a bank transfer.
Keep the original charge, merchant confirmation, refunded amount, currency and submission date. A partial refund should be reconciled against the original payment rather than assumed to cancel the entire charge. If a merchant cannot provide the refund status, ask whether the original transaction was a completed charge or an authorization hold.
Verification holds require a different response
A provider may request identity, account ownership, source-of-funds or transaction-related information under its compliance obligations. The exact requirements depend on the provider, jurisdiction and transaction.
Do not upload unrelated personal information merely because a support representative requests “more documents.”
Ask which document is needed, what it must establish and which secure upload process should be used.
Keep records of the request and submission date.
Repeatedly changing receiving details or attempting new payments during an unresolved review can make reconciliation more difficult.
The merchant may have approved a refund internally but not yet submitted it to its payment processor. Or the refund may have been initiated but not yet credited by the issuer. Check the supported payment methods and documentation before sharing new details.
Watch for payment scams
Not every payment problem is a processing error.
The FBI’s Internet Crime Complaint Center warns that business email compromise can involve fraudulent changes to payment instructions. If someone tells you that a client’s bank details have changed, verify the request through a trusted second channel.
The FTC also warns about fake overpayment and refund schemes in which a supposed customer claims to have paid too much and asks for the difference back. Never send a separate refund merely because someone shows you a screenshot of a payment.
Check your own provider’s transaction record and follow an authorized refund or reversal procedure. For account access, use unique credentials and available multifactor authentication. Never disclose one-time codes, private keys, seed phrases or passkeys to someone claiming to be support.
Do not turn one failure into two payments
Resending is appropriate only after establishing what happened to the original attempt.
If the payment was returned or definitively failed, the sender may be able to initiate a corrected transfer.
If the payment remains pending or under investigation, a second transfer could create a duplicate.
Keep the original payment reference until the case is resolved.
Start here
Find guides to delayed payments, verification issues, fraud attempts and transfer investigations.
Detailed guides
Microdeposit verification: what those small bank entries actually prove
Client Overpaid Your Invoice? How to Avoid a Refund Scam
Virtual Card Refund Not Received? How to Trace Your Money
Bank Statement vs Account Letter vs Transaction Receipt: Which One Should You Send?
walllet.com Verification Guide: Why KYC Fails and What “Under Review” Means
Payment Missing? Build This Evidence Pack Before You Contact Support
Proof of Income vs Proof of Funds vs Source of Funds in Nigeria: A Freelancer’s Evidence Pack
ACH Payment Returned? What R01, R02, R03, R04 and Other ACH Return Codes Mean
Identify the stage of failure
A pending payout, a returned bank transfer, a KYC review and a card refund are different investigations. Collect timeline, reference IDs and status messages before making changes.
Is the problem a failed payment or an identity-verification error?
A payment failure and a KYC error require different checks.
If the problem involves an international transfer, collect the transaction reference, payer details, receiving route and payment status.
If the problem involves a rejected identity document, a pending verification application or a BVN conflict, investigate the verification record instead. Do not attempt to correct an identity-verification error by resending a payment or creating another account.
Use the walllet.com identity-verification troubleshooting guide for the relevant recovery steps.
Build a useful evidence pack
Keep account details in a secure place, export transaction receipts and capture support case numbers. Share only the minimum necessary personal information through official support channels.
Protect yourself from impersonation
Never send passwords, passkeys, seed phrases or verification codes to someone claiming they can speed up an investigation. Verify support contacts from the provider’s official product.
Find the last confirmed payment event
A sender’s screenshot is not the same as recipient credit. Ask for the network-specific reference, transaction date, recipient details and current status before resending.
Handle evidence through official channels
Keep invoices, receipts, bank transfer references or on-chain transaction hashes. Never provide recovery phrases, private keys, passwords or one-time codes to someone offering to speed up support.
Keep one traceable record
When a payment fails, separate the commercial transaction from the technical payment attempt, identify the last confirmed event and collect the evidence needed by the institution responsible for the next step.
