Skip to content

Payments basics

Underpaid, overpaid and late crypto payments: what happens and what to do

What CryptoLike does when a customer pays too little, too much or too late, or not at all before the deadline — statuses, webhooks and the next step for each case.

Key takeaways

  • Underpaid: the payment stays open for a top-up to the same address until the deadline; remaining_amount says how much is missing.
  • Overpaid: the payment is paid, the whole sum is credited to you and overpaid_amount shows the surplus.
  • Late: funds that arrive after the payment closed are still credited, with late_payment: true and an invoice.late_payment event; the status does not change.
  • Expired: the deadline passed with nothing confirmed. Create a new payment.

A crypto transfer is sent by the payer, not pulled by the merchant, so the amount that arrives is not always the amount on the invoice, and it does not always arrive on time. CryptoLike handles these cases inside the same six payment statuses and reports each one by a signed webhook. This article goes through underpaid, overpaid, late and expired payments: what the payer sees, what your server receives and what to do next.

Underpaid, overpaid, late and expired at a glance

CryptoLike treats each deviation differently: an underpayment keeps the payment open, an overpayment still completes it, a late transfer is credited without changing the status, and an expiry closes the payment. The same status strings appear in the API, on the checkout page and in webhooks, so your order logic can branch on one field.

Case Status Field to read Webhook The payer sees Your next step
Less than the amount, before the deadline underpaid remaining_amount invoice.underpaid "Partial payment received … Send the remaining amount to the same address." Wait for the top-up
Less than the amount, deadline passed underpaid (final) paid_amount, remaining_amount invoice.expired "Payment expired with a partial amount … Contact the merchant to settle." Ship for the partial amount, ask for the rest, or refund
More than the amount paid overpaid_amount invoice.paid "Payment confirmed. The surplus was credited to the merchant." Ship; settle the surplus with the customer
Funds after the payment closed unchanged late_payment: true invoice.late_payment — Fulfil or refund
Nothing confirmed by the deadline expired expired_at invoice.expired "Payment expired. Create a new payment." Create a new payment if the customer still wants to pay

Source: the CryptoLike status model and the webhook contract, as of 2026-09-24.

What happens when a customer underpays?

When the confirmed amount is less than the amount due, the CryptoLike payment becomes underpaid and you receive invoice.underpaid. The payment stays open: the payer can send the missing part to the same address until ttl_expires_at, and a top-up that covers it turns the payment into paid. The field remaining_amount always says how much is missing.

The checkout page shows the payer exactly what is left: "Partial payment received: 40 of 50 USDT. Send the remaining 10 USDT to the same address." The "open in wallet" link of an underpaid payment already carries the remaining amount, not the original one, and so does the QR code on Bitcoin and Litecoin. Even before confirmations the page shows the detected amount next to the amount due, so a shortfall is visible as soon as the transfer appears in the network.

A small shortfall does not always make a payment underpaid: if it is within the underpayment tolerance of your account — 0.5 % of the amount by default — the payment counts as paid. See underpaid payment in the glossary for the short definition.

What if the deadline passes with a partial payment?

When the deadline passes, an underpaid CryptoLike payment becomes final: the status stays underpaid, expired_at is set, and you receive invoice.expired with the status underpaid in its data. The partial amount is already credited to your balance. The payer sees "Payment expired with a partial amount" and is asked to contact you to settle.

You have three options, and the choice is yours:

  • Ship for the partial amount, if the difference is acceptable to you.
  • Ask for the rest with a separate payment for the missing amount — for example, a crypto invoice created in the cabinet. A shop plugin will not open a second payment for an order that already received funds; such orders go to a review status for a person to decide.
  • Refund the received amount by sending a payout from your balance to an address the customer gives you.

What happens when a customer overpays?

An overpayment does not create a separate status in CryptoLike. The payment becomes paid, the whole amount received is credited to your balance, and invoice.paid carries overpaid_amount above zero. If a further transfer to the same address raises the surplus, invoice.paid is sent again with the new overpaid_amount. The payer sees "Payment confirmed. The surplus was credited to the merchant."

What to do: ship the order as usual, then settle the surplus with the customer — refund it by payout, or count it towards a next order if you both agree. Shop plugins add a note about the overpayment to the order. The glossary entry on overpaid payment has the short definition.

What happens when a payment arrives late?

A late payment is a transfer confirmed after the CryptoLike payment was closed — expired, cancelled or finally underpaid. The funds are still credited to your balance, the payment gets late_payment: true, and you receive invoice.late_payment. The status does not change: an expired payment stays expired, so nothing ships automatically.

A common source of late payments is a transfer sent close to the deadline: the payment closes as expired while the transfer is still collecting confirmations, and the funds arrive as a late payment once it reaches the threshold. The article on crypto payment confirmations explains why that wait differs by network.

What to do: check whether the customer still wants the order. If yes, fulfil it; if not, refund by payout. Shop plugins never mark such orders paid on their own — they move them to a review status for your decision.

What does an expired payment mean, and how do you recover?

An expired CryptoLike payment is one whose deadline passed with nothing confirmed. expired closes the payment: the payer can no longer pay it from the checkout page, and you receive invoice.expired. The payer sees "Payment expired. Create a new payment." Recovery is a new payment — from your shop's checkout, a new invoice or a new payment link.

The deadline is set per payment with ttl_seconds, from 60 seconds to 30 days, or taken from your account setting. Right after the deadline the payment may show seconds_left = 0 for up to 30 s before it closes; the page shows it as expiring. If money still arrives for an expired payment, it is not lost: it is credited as a late payment. The glossary entry on expired payment gives the short definition.

How do you refund a customer?

CryptoLike refunds are payouts: you send the amount from your available balance to an address the customer gives you, through the cabinet or POST /v1/withdrawals. Ask for an estimate first — it shows the platform fee, the reserved network fee and the total debit before you confirm. The current fee schedule is on the pricing page.

Before sending:

  1. Confirm the address and network with the customer. The refund goes to the network of the asset you send; a wrong address cannot be reversed.
  2. Add the address to your whitelist if your account enforces a payout whitelist; otherwise the payout is refused. A newly added address becomes usable 24 hours after it is added, so add it early.
  3. Send your own payout_id, for example the order number, so a retried request can never pay twice.

Payouts require a verified account. Through the API they also need a key with the withdraw permission; in the cabinet, a fresh 2FA code.

How can you reduce underpaid and late payments?

Most CryptoLike underpayments come from the payer sending a different amount than the page shows, and most late payments from a deadline that is too short for the network. A few settings and habits reduce both without changing your integration.

  • Show the exact amount and network. The checkout page does this; if you display the amount elsewhere, use payer_amount, which already includes the platform fee when the payer bears it.
  • Remind payers about exchange withdrawal fees. When paying from an exchange account, the amount that arrives must still equal the amount on the page after the exchange's own fee.
  • Give the network enough time. Choose ttl_seconds with the asset's confirmation time in mind; the coins catalogue lists the assets and their thresholds.
  • Subscribe to all invoice.* events. invoice.underpaid, invoice.late_payment and invoice.reverted are the ones that need a person; the webhooks documentation lists them. A paid payment can also fall back to underpaid when a block reorganisation drops one of its confirmed transfers — see why "detected" is not "paid".

More answers on statuses and payouts are on the FAQ page.

FAQ

Can the customer top up an underpaid payment?

Yes, until the deadline. The customer sends the missing amount to the same address; the checkout page shows the remaining amount. When the top-up is confirmed, the payment becomes paid and you receive invoice.paid.

Is an overpayment credited to my balance?

Yes, the whole amount received is credited. The payment is paid, and overpaid_amount in invoice.paid and in GET /v1/invoices/{id} shows the surplus, so you can settle it with the customer.

What happens to money sent after the payment expired?

It is credited to your balance as a late payment: the payment gets late_payment: true, you receive invoice.late_payment, and the status stays expired. Decide with the customer whether to fulfil the order or refund.

Does an underpaid payment ever become expired?

No. After the deadline an underpaid payment stays underpaid and becomes final; you receive invoice.expired with the status underpaid. expired is reserved for payments with nothing confirmed.

How do I refund a customer in crypto?

Send a payout from your balance to the address the customer gives you, in the cabinet or with POST /v1/withdrawals. Check the estimate first, whitelist the address in advance if your account requires it (a new address becomes usable after 24 hours), and pass a payout_id so a retry cannot pay twice.

Terms used here

Read next

Start with a test payment

Create an account, ask support for the test environment and see a payment go from pending to paid on a test network.