Payment statuses explained: pending, processing, completed, failed, and returned

A payment status is a label for an event or stage in a payment process. “Pending” generally means something is unfinished, but it does not tell you what. “Completed” may describe a provider’s action without proving that every later stage is complete.

This distinction matters when a client believes they have paid, a seller sees a payout marked as sent, or a business needs to know whether it can use incoming funds. The same payment can have different statuses in the sender’s bank, a provider’s workspace, and the recipient’s account.

There is no universal status dictionary for every bank and platform. The guide below provides a way to interpret the labels and ask a useful follow-up question.

Identify which transaction the status belongs to

An invoice, a customer payment, a currency conversion, and a payout can each have separate records. “Paid” on an invoice might mean somebody marked it as paid manually. “Completed” on a conversion might mean the conversion finished, while a bank payout remains in progress.

Before responding, identify the object: what action was requested, by whom, for what amount, and through which service? Then find the transaction reference and the time of the latest update.

This prevents an internal bookkeeping label from being mistaken for confirmation from a payment institution. It also helps avoid chasing the wrong support team.

Use a status as a starting point

Common label	Possible meaning	Useful question
Scheduled	Instructions are saved for a later date	Has the payment actually been submitted?
Pending	A required step remains incomplete	Is it waiting for funding, approval, or processing?
In review	Information or activity is being checked	Is there a specific request I should answer?
Processing or in transit	A provider has begun or passed on an action	Which stage is confirmed and what remains?
Completed or paid	A defined action succeeded	Does this include recipient credit and availability?
Failed or rejected	An attempt could not proceed or finish	Why, and where are the funds now?
Returned	Funds are being or have been sent back	Has the sender been credited, or only the return initiated?

These are interpretation prompts, not guarantees about any provider’s terminology. Use the definitions supplied for your actual account and rail.

Separate pending from overdue

A payment can be pending within its expected window. An invoice can be overdue before any payment has even been attempted. Those are different problems.

Ask whether the payer has submitted the transfer, whether the provider has accepted it, and when the expected window begins. Some estimates begin after funding, verification, or a banking cutoff rather than when the payment form was first completed.

If there is no submitted transfer, follow the late client payment process. If there is a confirmed transfer beyond its expected window, collect the evidence needed to trace the payment.

Read review notices carefully

A review may concern identity, business information, the payment purpose, destination, source of funds, or other compliance requirements. The label alone does not identify the reason and should not be used to speculate about wrongdoing.

Look for a specific request in the verified account or official support channel. Supply accurate, relevant documents, and explain any mismatch rather than editing records to conceal it. Repeatedly starting new transactions does not resolve a review of the original one.

Account approval and transaction approval are separate concepts. An already verified customer can still be asked about a later payment. See KYC, KYB, and source of funds for that distinction.

Understand completed versus available

A provider can complete its own action before another institution has finished crediting the customer. A balance can also include amounts that cannot yet be paid out. Read the availability information and any hold separately from the status label.

Provider-specific behaviour illustrates why this matters. Stripe’s payout object documentation distinguishes pending, in-transit, paid, canceled, and failed payouts, and notes that some payouts initially marked paid can later show failed. That is a Stripe example, not a definition of every bank or Ostro status.

For business decisions, reconcile the latest provider information with the actual destination record. Do not promise a supplier usable funds solely because another interface has turned a label green.

Work through a multi-stage example

Imagine a fictional consultant invoices a client for USD 2,000. The client schedules an ACH payment on Monday. The payment later appears as received in a payment service, then enters review. Once available, the consultant requests an eligible EUR bank payout.

The invoice, incoming USD payment, review, conversion, and EUR payout can all have different timestamps. A completed incoming payment does not mean the later payout has finished. The EUR amount also needs the applicable quote and fees, not just a copy of the USD invoice total.

Keep one business record linking these stages. That lets the consultant tell the client “your payment has been received” without confusing it with a separate payout the consultant requested afterward.

Treat failure as a reason to investigate before retrying

A failure can result from invalid details, an unsupported route, a closed account, a limit, or other circumstances. Read the reason provided instead of assuming a typo.

Check whether the original attempt debited funds, whether a return is required, and whether the provider recommends retrying. If the outcome is uncertain, sending again can create a duplicate. A failed request is not always the same as a returned completed debit.

Correct the underlying issue, confirm the destination again, and retain both references if a new attempt is authorised. Never retry through a different identity or misleading payment purpose to get around a restriction.

Distinguish rejected, canceled, and returned

A request rejected before submission may never enter the payment rail. A cancellation may be possible only during a particular stage. A return concerns funds moving back after an earlier step.

Each outcome has its own evidence. Ask for the final status, the amount and currency involved, and where any funds are now. If money is coming back, ask for the return reference and expected credit window.

Charges or conversions can make the returned amount differ from the original expectation. Record the actual outcome rather than automatically restoring the invoice as though nothing happened. Refunds, chargebacks, and bank returns explains the different processes.

Keep customer communication precise

Use language that matches the confirmed stage: “scheduled by the payer,” “received and under review,” or “payout submitted; recipient credit not yet confirmed.” Avoid upgrading an estimate into a promise.

For a delayed supplier payment, include the reference, confirmed submission time, current stage, and next update. If you do not know the cause, say that the provider is investigating rather than inventing an explanation about an intermediary bank.

This can be concise. Accuracy matters more than copying every internal status change into an email to the customer.

Save events rather than replacing history

An operational record should preserve when important changes happened. Store the original submission, later status changes, requests for information, return events, and final reconciliation.

If one screen says “completed” and another says “returned,” compare timestamps and transaction identifiers. They may describe different stages or separate transactions. Replacing the first record with the second erases the evidence needed to understand the discrepancy.

For a small business, a simple timeline alongside secure source documents is often enough. See organising cross-border payment records for a practical structure.

Frequently asked questions

Does pending mean the payment failed?

No. It means the process has not reached the provider’s defined next or final stage. Check what it is waiting for and whether the expected window has passed.

Can a completed payment still cause a problem?

Yes. The label may describe only one stage, and some rails or provider processes allow later returns or other adjustments. Use the provider’s definition and the latest evidence.

Should I keep refreshing or create another payment?

Refreshing does not resolve missing information or a processing restriction. A second payment can create duplication. Follow the stated window and support process before retrying.

Is this the exact status flow in Ostro?

No. These are general educational examples. For an Ostro payment, use the current status, instructions, and available options in your workspace, or contact the Ostro Help Center.