Crypto Payment Status

Overview

A status is a business interpretation of evidence

Payment statuses are labels such as waiting, confirming, paid or expired that help software and people know what to do next. A blockchain does not publish a universal “invoice paid” flag. It publishes transactions and other state changes. The payment provider compares those observations with an invoice's rules and assigns a business status. Some providers distinguish an incoming transfer from a confirmed payment; others mark underpayment or require manual review. The available labels and their transitions must be read from the provider's actual documentation.

How the underlying system works

A good status model defines transitions, event timestamps, idempotent updates and terminal or reversible states. At OxaPay, the published merchant payment status table includes <code>new</code>, <code>waiting</code>, <code>paying</code>, <code>paid</code>, <code>manual_accept</code>, <code>underpaid</code>, <code>refunding</code>, <code>refunded</code> and <code>expired</code>. These are documented provider values, not universal labels for all blockchains.

The consumer application must decide how a status affects its own order. For example, receiving <code>paying</code> should not cause delivery; <code>paid</code> can authorize fulfillment according to the merchant's policy after verifying event authenticity. An expired invoice may still require attention if funds arrive unexpectedly. Keep the original provider event and the resulting internal state change so repeated callbacks cannot repeatedly ship goods.

Read one payment over time

A $50 invoice begins as waiting because no matching transfer has been seen. A customer broadcasts a transaction; the provider may label it as paying or confirming after detection, depending on its state model. Once the right asset, amount and required network evidence satisfy the policy, it can become paid. If the transfer is short, the status may be underpaid rather than successful. If the invoice expires before acceptable payment is completed, the system may report expired. Importantly, expiry does not erase a blockchain transfer that arrives later; it means the invoice workflow needs an exception decision.

Design safe reactions to status changes

Use statuses to decide which back-office action is appropriate. Waiting means do not fulfill. Confirming usually means continue observing. Paid may authorize fulfillment under the merchant's chosen risk policy. A manual-accept state signals an explicit operational decision rather than automatic success. Status updates can arrive late or out of order, so a delayed waiting callback must not overwrite a newer accepted state. Keep the provider tracking ID, the event history and a way to retrieve the current authoritative status when notifications are missed.

Further reading and related concepts

Reference documents: OxaPay — Payment Status Table.

Related glossary topics: Confirmation, Transaction Finality, Webhook.