How to handle unpaid, late and expired crypto invoices

An unpaid crypto invoice should remain open only until its displayed expiry time. After expiry, stop accepting payment on that invoice and issue a new one if the sale should continue. If the buyer says they paid before or after expiry, do not decide from a screenshot: obtain the transaction hash, verify the actual transfer on the correct network and resolve the case separately from the normal invoice flow.

“Unpaid,” “pending,” “expired” and “paid late” are not interchangeable. They describe different evidence and require different actions.

Quick decision table

Situation	What the merchant should do	Should the order be fulfilled?
No transaction, invoice still open	Remind the buyer and keep the original invoice	No
Transaction broadcast before expiry but still pending	Verify the hash and wait for the required network confirmation	Not yet
No transaction and invoice expired	Close the payment attempt; create a new invoice if the buyer still wants to pay	No
Confirmed transfer after expiry	Verify network, token, recipient and amount; then apply the merchant’s late-payment policy	Manual decision
Transfer cannot be matched to the invoice	Collect evidence and investigate before fulfilment or refund	No
New invoice issued after the old one expired	Tell the buyer to use only the new invoice	Only after the new invoice is paid

If the transfer has the wrong amount, use the underpaid and overpaid invoice workflow. If it used the wrong blockchain, follow the wrong-network investigation and recovery guide. Do not reduce either case to a generic “late payment.”

The same separation appears in mature invoice systems. BTCPay Server documents different states for expired, partially paid and late-paid invoices, while Coinbase Business distinguishes open, paid, void and overdue invoices. The labels vary by product, but the operational rule is consistent: expiry and payment evidence must be evaluated independently.

What an invoice expiry actually means

Expiry is the end of the payment window defined by the invoice. It does not erase a blockchain transfer and it cannot prevent someone from sending tokens directly to a public wallet address later. It tells the checkout and the merchant’s order system that the original payment request should no longer accept a new payment automatically.

That boundary matters because:

• the order, inventory or service availability may have changed;
• a quoted fiat-to-crypto amount may no longer be current;
• the buyer may already have received a replacement invoice;
• a late transfer can otherwise be confused with a different order;
• automatic fulfilment after an unlimited delay creates reconciliation risk.

Use the expiry shown on the checkout as the source of truth. Do not invent a second deadline in chat, and do not tell the buyer that an expired checkout is still safe to pay.

How GramPayBot treats expired invoices

GramPayBot matches a payment against the invoice’s configured network, token, recipient, exact amount and payment window. An invoice that has expired no longer presents active payment options. The normal automatic matcher considers confirmed transfers inside the invoice window; a transfer arriving outside that window does not silently turn the expired invoice into a paid order.

This is intentional. A late transfer may still reach the merchant-controlled wallet, but “funds reached an address” and “the original invoice was paid under its terms” are different facts. The merchant should verify the late transfer and make a documented business decision.

For the broader lifecycle, see the crypto invoicing workflow for small business.

Workflow for an unpaid invoice before expiry

If no transaction has been sent and the invoice remains open:

1. Send the buyer the original checkout link again.
2. Ask them to use the token, network and exact amount displayed there.
3. Warn them not to pay after the visible expiry time.
4. Keep the order in a waiting state.
5. Fulfil only after GramPayBot reports a matching confirmed payment.

Do not create several active invoices for the same order just because the buyer has not responded. Multiple live payment requests increase the chance of a duplicate payment.

Workflow when the buyer says “I paid”

Ask for the raw transaction hash or signature, not a screenshot. Then check:

1. Network: is it the network named by the invoice?
2. Status: did the transfer succeed and reach the required confirmation level?
3. Token: does the contract or mint match the supported USDT or USDC asset?
4. Recipient: is it the exact wallet address from the invoice?
5. Amount: is it the exact invoice amount, including any displayed identifying suffix?
6. Time: when was the transfer included relative to the invoice expiry?
7. Reuse: has this transaction already been assigned to another order?

A submitted transaction can be pending before it is included and successful on-chain. Ethereum’s official documentation describes the path from a submitted transaction through inclusion and finality in its transaction lifecycle. Keep fulfilment waiting while the result is still uncertain.

Use the full crypto payment verification checklist when any field is unclear.

What to do after an invoice expires without payment

If there is no verified transfer:

1. Mark the original attempt as closed in your operational records.
2. Confirm that the buyer still wants the product or service.
3. Recheck price, availability and commercial terms.
4. Create a replacement invoice with a new payment window.
5. Send one clear message stating that only the new link should be used.
6. Retain the old invoice ID for support and audit history.

Never edit your records so that the new request looks like the old invoice. A replacement invoice should have its own identifier and status. That preserves a clean answer to the question “which payment settled which order?”

Suggested buyer message:

The previous invoice has expired and should not be paid. I have created a replacement invoice with the current amount and payment window. Please use only the new link. If you already sent a transaction, stop and send us the transaction hash before making another payment.

What to do with a confirmed late payment

First, verify the transfer completely. GramPayBot does not provide a control that changes an already expired invoice to paid. If the correct token reached the correct merchant wallet after expiry, choose one of these documented business outcomes:

• Fulfil as a documented exception outside the expired invoice: appropriate when price and availability have not changed and your policy permits late acceptance. Keep the GramPayBot invoice expired; do not describe it as automatically or manually settled in the product.
• Apply it to a replacement order: create a clear link in your records rather than pretending the expired invoice auto-settled.
• Refund it: appropriate when you cannot fulfil or your policy rejects late payments.
• Hold for review: appropriate when the token, amount, ownership or customer identity is uncertain.

Do not automatically accept a late payment merely because the amount looks correct. Also do not automatically refund to the sending address: exchange withdrawals often originate from shared operational wallets, so the sending address may not be a valid refund destination.

Safe refund procedure

A confirmed blockchain transaction cannot be edited or reversed by GramPayBot. A refund is a new outgoing transaction authorized by the merchant.

Before sending it:

1. Verify the original transaction on-chain.
2. Confirm the network, genuine token contract, amount and wallet that received it.
3. Authenticate the customer through the original order or support channel.
4. Ask for a refund address on the same supported network and have the customer confirm it.
5. State how network fees or exchange fees will be handled.
6. Use a second-person approval for higher-value refunds.
7. Record the refund hash against the invoice and order.

Never ask the customer for a seed phrase or private key. Never use a “recovery service” introduced through an unsolicited message.

Prevent duplicate payment after a replacement invoice

The highest-risk moment is when the buyer has the old and new invoice links at the same time. Reduce that risk by:

• making the expired state unambiguous;
• sending the replacement in the same authenticated conversation;
• writing “do not pay the previous invoice” in the message;
• telling the buyer to stop if a first transfer is already pending;
• checking both invoice records before fulfilment;
• recording every accepted transaction hash exactly once.

The buyer-facing steps are covered in how to pay an invoice with USDT or USDC.

Support record template

Keep these fields together for every exception:

• order ID and customer contact;
• original invoice ID and expiry time with timezone;
• replacement invoice ID, if any;
• expected network, token, recipient and exact amount;
• claimed transaction hash and actual block time;
• on-chain status and verification notes;
• decision: rejected, fulfilled as an exception, applied to a replacement order or refunded;
• approver, customer communication and refund hash.

This record is more useful than a folder of screenshots because it preserves the evidence used to make the decision.

Frequently asked questions

Can a buyer pay an expired crypto invoice?

They may still be technically able to send tokens to a public wallet address, but they should not pay the expired request. The checkout no longer accepts payment, and a later transfer requires manual investigation rather than normal automatic matching.

What if the transaction was sent before expiry but confirmed later?

Do not judge from the buyer’s send time alone. Verify the transaction’s actual on-chain inclusion, status and the payment system’s matching result. Keep the order waiting until the transfer is confirmed and matched.

Should I extend the old invoice?

Use a replacement invoice unless your system has an explicit, auditable extension feature. A new invoice keeps the revised payment window and order decision clear.

Can GramPayBot reverse a late transfer?

No. Funds are sent directly to the merchant’s configured wallet. Any refund is a separate merchant-authorized blockchain transaction.

Should I create a new invoice if the buyer may already have paid?

Not yet. Ask for the transaction hash and investigate first. Creating and paying a second invoice before checking the first transfer can cause a duplicate payment.