Crypto Invoice Statuses: Paid, Underpaid, Overpaid and Expired

A crypto checkout is reliable only when the merchant backend understands payment status. A customer can pay the exact amount, pay too little, pay too much, pay after expiration or trigger a risk review.

For merchants, these statuses are not cosmetic labels. They decide whether the order should be fulfilled, paused, credited, refunded or reviewed by support.

Why invoice statuses matter

Blockchain payments are final from the network perspective, but merchant orders still need business logic. The checkout system must map a transaction to an order and decide what to do next.

A payment status gives the backend a stable rule instead of forcing operators to inspect every transaction manually.

Paid invoices

A paid invoice means the customer sent the expected payment and the merchant can continue fulfillment according to its policy. For digital products, this might unlock content. For e-commerce, it may move the order to processing.

Use webhooks so the order updates automatically when the invoice becomes paid.

Underpaid invoices

An underpaid invoice means the received amount is lower than expected. This can happen because of wallet fees, exchange-rate confusion, manual entry mistakes or customer misunderstanding.

Merchants should decide whether to request a top-up, accept a small tolerance, keep the order pending or cancel the order. The right policy depends on product margin and support expectations.

Overpaid invoices

An overpaid invoice means the customer sent more than required. This may be harmless, but the merchant still needs a clear accounting path. Common options include internal credit, manual refund, bonus credit or support review.

The important point is visibility. If the backend knows the invoice is overpaid, operators can resolve it consistently.

Expired and late payments

Invoices often expire so the merchant is not locked to an old rate or checkout session forever. A customer can still send funds after expiration, so late payments need explicit handling.

Do not treat late payments as normal paid orders unless that is your policy. Separate them so support and accounting can decide the next step.

Webhook reconciliation

The safest integration pattern is webhook-first reconciliation. Create the invoice, show payment details, then update the order only after your backend receives and verifies the payment status event.

Start with the Crypto Invoice API and connect it to your order state machine before launching production checkout.