Your client says the payment was sent. Your balance says otherwise.

At that point, “my payment is missing” is not enough information to investigate anything. A useful payment support escalation needs to answer a more precise set of questions: What was supposed to happen? What actually happened? Which payment route was used? What reference identifies the transaction? Where was it last confirmed? Who can take the next action?

The goal is not to send support more screenshots. It is to turn one missing payment into one traceable case.

If your payment is showing as pending, under review, held, or delayed rather than genuinely missing, first identify what that payment status may actually mean. If the payment was an international wire, use the wire-tracing workflow for MT103 and UETR. If an ACH payment was returned rather than simply delayed, the ACH return code may tell you more than another support message.

Those are different problems. Treating them as one generic “payment missing” issue wastes information you may already have.

First, classify what “missing” actually means

“Sent,” “processing,” “completed,” “returned,” and “received” are not interchangeable.

The exact labels vary by bank, platform, and payment provider, so do not assume a status means the same thing everywhere. Instead, document what each side can actually prove.

A status label is a clue. It is not the investigation.

Build a payment timeline before you build the ticket

Support should not have to reconstruct your payment history from six screenshots and a chat transcript.

Write the timeline first.

For each meaningful event, record:

• exact date;

• exact time;

• timezone;

• who took the action;

• payment status shown at that moment;

• reference or case number, if one existed;

• what changed next.

A clean timeline might look like this:

24 August, 14:05 WAT — Client initiated USD payment.
24 August, 14:09 WAT — Client sent bank confirmation and payment reference.
25 August, 10:20 WAT — No incoming credit visible in receiving account.
25 August, 16:40 WAT — Receiving provider checked account; payment still not credited.
26 August, 09:15 WAT — Client requested a trace from sending bank.
26 August, 13:30 WAT — UETR received and added to case.

That is much more useful than “it has been three days and I still haven’t received anything.”

Do not round dates or rely on memory. If the sender, bank, provider, and recipient are in different countries, include the timezone.

What belongs in a missing-payment evidence pack?

A strong pack connects the commercial reason for the payment to the actual transaction.

Think of it as an evidence chain:

invoice or payment request → payer → amount and currency → payment route → transaction reference → current status → actions already taken

The minimum useful pack usually contains the following.

1. Invoice or payment request

Include the document that explains what was supposed to be paid.

Useful fields include:

• invoice number;

• payer or client name;

• recipient name;

• amount;

• currency;

• invoice date;

• due date;

• payment details you originally gave the client.

If the payment came from an employer, platform, or another arrangement without an invoice, use the relevant payout statement, remittance record, payment notice, or other document that connects the sender to the expected payment.

You usually do not need to send an entire client contract unless support specifically needs it.

2. Exact amount and currency

Do not write “about $1,000.”

Write:

USD 1,000.00

If the sender paid one amount but you expected another amount after fees or FX conversion, record both separately.

For example:

• Amount initiated: USD 1,000

• Amount expected to reach receiving account: unknown

• Currency expected at destination: USD

• Amount actually credited: USD 0

Do not silently treat fees, FX deductions, intermediary-bank charges, and a genuinely missing payment as the same issue.

3. Payer confirmation

Ask for evidence generated by the bank or payment provider, not only a WhatsApp message saying “sent.”

Useful payer-side proof may contain:

• sender name;

• recipient name or account details;

• amount;

• currency;

• initiation date;

• transfer status;

• transaction/reference ID;

• payment rail;

• bank or provider name.

A sender screenshot can help. It is rarely the whole case.

4. The transaction or payment reference

This is often the most useful field in the pack.

The right identifier depends on the route:

Do not replace a machine-searchable reference with a screenshot if you have the actual reference string.

5. Receiving details used for the payment

Record the details the payer actually used, not the details you think they used.

Depending on the route, that may include:

• account holder name;

• account number or IBAN;

• routing details;

• bank name;

• wallet address;

• token;

• blockchain network;

• provider-specific recipient identifier.

Compare them with the details you originally supplied.

Do this before asking anyone to resend money.

6. Current status on both sides

Write down what the sender sees and what the recipient sees.

For example:

This prevents one of the most common communication problems: both sides using the word “completed” to describe different stages.

7. Actions already taken

Tell support what has already happened.

Examples:

• sender confirmed beneficiary details;

• recipient checked transaction history;

• sending bank contacted;

• receiving bank contacted;

• trace requested;

• return code received;

• previous ticket opened;

• requested document supplied;

• no resend attempted.

This stops the next person from starting the investigation at step one.

If international client payments are a recurring part of your income, walllet.com currently supports USD, EUR and GBP receiving details, holding income in USD, and conversion to naira when needed.

See the full freelancer money flow →

A screenshot is context. A reference is traceable data.

A screenshot can show that:

• a sender saw a particular status;

• a payment appeared in an app;

• an amount was debited;

• an error appeared;

• the payment details shown on-screen matched what you expected.

But a screenshot may still omit the field another institution needs to search for the transaction.

This is why “my client sent me a screenshot” is not the end of the evidence process.

If the screenshot does not show a transaction reference, ask for the underlying payment confirmation or receipt.

If it does show the reference, copy the reference as text as well. Do not make an agent manually transcribe a long identifier from an image.

For a SWIFT payment in 2026, prioritize the UETR

A UETR is the end-to-end identifier used to track a payment through the Swift chain. Swift describes it as the reference that allows institutions to locate a payment and follow status changes across the payment chain.

There is also an important 2026 update to older “just ask for the MT103” advice.

Swift's coexistence period between traditional MT payment instructions and ISO 20022 for cross-border payments ended on 22 November 2025. Current cross-border bank-to-bank payment instructions are now delivered in ISO 20022 format; Swift retains limited contingency conversion for certain MT instructions during the transition.

That means you should not make the document name the whole request.

For a missing SWIFT payment, ask for:

• the UETR;

• the bank's current payment confirmation or remittance record;

• any current trace or investigation reference;

• the payment date;

• amount and currency;

• beneficiary details used.

A bank may still use the term “MT103” in a customer-facing workflow, or provide an MT-style representation. Another may give documentation tied to the ISO 20022 payment record. The traceable identifier matters more than insisting on one PDF format.

Also remember: possessing a UETR does not, by itself, prove the money has been credited to your account. It gives the institutions a common identifier with which to trace the payment.

For ACH, a return is different from a delay

If a client paid through ACH and the payment was returned, do not treat the case as “still on the way.”

Find the return information first.

A return code can identify problems such as account details, account status, authorization, or another route-specific issue. The right next action depends on that code.

Do not ask the client to resend blindly before the original failure has been understood. Otherwise, the second payment can reproduce the first failure or create a duplicate-payment problem.

For stablecoins, build the evidence from the blockchain record

A stablecoin payment has a different evidence trail.

You usually want to record:

• token, such as USDT or USDC;

• blockchain network;

• transaction hash;

• sending address;

• destination address;

• amount;

• transaction timestamp;

• on-chain status.

The transaction hash is much more useful than “my client says the USDT left their wallet.”

If you regularly accept client payments this way, use the stablecoin payment checklist for freelancers before sharing an address. It is easier to prevent a token-network-address mismatch than to investigate one after the payment is sent.

If a transaction is confirmed on-chain to the correct address but a custodial platform has not credited your internal balance, the blockchain evidence and the platform-credit issue are two separate layers. Give the receiving platform the transaction hash and the exact network details through its secure support channel.

Who should contact the sending bank first?

Start with whoever controls the sending relationship.

If your client initiated the bank transfer from their bank or payment provider, they are usually in the best position to request the origin-side payment confirmation or trace.

You, as the recipient, can then give your bank or receiving provider the traceable information.

A practical handoff looks like this:

Payer:
“I initiated this payment. Please provide its current status and trace identifier.”

Recipient:
“Here is the payment identifier, amount, date, currency, sender, and beneficiary information. Can you confirm whether this payment reached your side or requires further investigation?”

This is much more productive than asking two institutions, “Can you find my missing money?” without giving either side a common reference.

If the sending institution confirms that the payment reached the beneficiary bank, the evidence pack can move to the receiving side with that status attached.

If the sending institution says the payment was returned, rejected, cancelled, or never released, the next action stays on the origin side.

Create two versions of every sensitive screenshot

Do not use the same screenshot for an authenticated support portal and a public Telegram group, Reddit thread, or social post.

Create two versions.

Support-safe version

Use only through the provider's official, authenticated support channel.

Keep the information the investigator actually needs, which may include:

• transaction reference;

• amount and currency;

• relevant account details;

• payer and recipient names;

• payment date;

• status;

• requested supporting documents.

Redact unrelated information.

Public-safe version

Ideally, do not post financial documents publicly at all.

If you need general advice in a community, remove:

• full bank account numbers;

• IBANs where unnecessary;

• full card numbers;

• CVV;

• passwords;

• PINs;

• one-time codes;

• passport or ID images;

• BVN or NIN;

• full statements;

• unrelated transactions;

• email addresses and phone numbers;

• payment references that do not need to be public;

• API credentials;

• wallet private keys;

• seed or recovery phrases.

A seed phrase or private key should never be sent to support.

Redaction should remove what the recipient does not need, not destroy the evidence they do need.

Do not scatter one investigation across five tickets

Opening several tickets can split your evidence, timeline, and updates across separate conversations.

For your own records, keep one primary case unless the provider asks you to create another.

Record:

• ticket number;

• date opened;

• channel;

• last response;

• requested documents;

• documents supplied;

• next promised action, if the provider gave one.

When something changes, update the existing case with the new evidence.

This does not guarantee faster resolution. It simply keeps one coherent version of the case.

If a case is closed while the issue remains unresolved, reference the original case number when you reopen or escalate it.

Do not resend a payment just because the first one is difficult to find

A missing transfer creates pressure to “try again.”

That can create a second problem.

Before a resend, establish what happened to the first attempt.

A resend is easier to justify when the original payment is clearly:

• rejected;

• returned;

• cancelled;

• failed before settlement;

• otherwise confirmed by the responsible provider as no longer capable of reaching the recipient.

If the first payment is still processing, under investigation, or somewhere in the route, sending a second payment may create a duplicate.

The same rule applies to small “test” retries after a problem starts. A test payment is useful before a large transfer when the route is uncertain; it is not automatically the right troubleshooting action once an unresolved payment is already in flight.

Copyable missing-payment support ticket

Use one message that gives the investigator enough structure to start.

Subject: Missing payment — [amount + currency] — [payment date] — [reference]

Hello,

I am reporting a payment that has not been credited to my account.

Expected payment

Amount: [amount]
Currency: [currency]
Payer: [name/company]
Recipient: [name]
Payment route: [SWIFT / ACH / platform / local transfer / stablecoin / other]
Payment initiated: [date, time, timezone]

Current status

Sender-side status: [status]
Recipient-side status: [status]

Payment identifiers

Provider/bank reference: [reference]
UETR / ACH trace / transaction hash, if relevant: [identifier]

Timeline

[date/time] — [event]
[date/time] — [event]
[date/time] — [event]

Evidence attached

[invoice/payment request]
[payer confirmation]
[payment receipt/remittance record]
[redacted screenshot]
[trace or return document, if available]

Actions already taken

[action] — [result]
[action] — [result]

Please confirm:

1. the current status of this payment;

2. whether the reference above is sufficient to trace it;

3. whether another bank, provider, or party currently owns the next action;

4. what additional evidence you need from me.

If you require more sensitive account or identity information, please tell me which secure channel to use.

Thank you.

Notice what the ticket does not say:

“Urgent!!! My money is missing. Please fix ASAP.”

Urgency may be real. It still does not identify the payment.

Use a simple folder structure for the case

If the investigation lasts more than one conversation, save the evidence outside your chat history.

For example:

missing-payment-2026-08/

├── 00-case-summary.txt

├── 01-invoice.pdf

├── 02-payer-confirmation.pdf

├── 03-payment-reference.txt

├── 04-timeline.txt

├── 05-trace-document.pdf

├── 06-support-safe-screenshots/

└── 07-support-correspondence/

Use dates in filenames when documents change.

Do not overwrite the original evidence with a heavily redacted copy. Keep the original privately, then create a separate version for sharing.

The best evidence pack starts before the payment goes missing

The easiest missing payment to investigate is one whose records already exist.

Before the next international client payment:

1. send payment details in a written, reusable format;

2. confirm the payer has the correct beneficiary details;

3. agree on the currency and route;

4. keep the invoice;

5. save the payment confirmation;

6. record the transaction reference as soon as it exists;

7. keep the final receiving record once the money arrives.

If you are deciding how clients in different markets should pay you, the US, UK, and EU client payment workflow explains how the available rails differ before a payment is initiated.

The point is not to create paperwork for its own sake.

It is to make every payment answerable later.

Make the case searchable, not louder

A missing payment investigation becomes much easier to hand off when one packet contains the amount, currency, payer, recipient, route, dates, status, payment reference, supporting documents, and actions already taken.

You cannot control every bank, intermediary, platform, review, or support queue.

You can control whether the next person receives a vague complaint or a case they can actually identify.

Get paid globally, hold in USD, and cash out in naira with walllet.com