You approve a Litecoin payment, return to the shop and find an expired invoice. The checkout offers a new one. Paying it immediately can turn one unresolved purchase into two payments.
First establish whether the original payment exists, what reached the intended destination and how the receiver recorded it. The invoice deadline, your wallet’s send time and the service’s acceptance decision are different facts.
This guide gives you a short decision procedure and ten reproducible teaching cases. Their times, prices, amounts and service outcomes are fictional. We did not pay a real invoice, test a processor or measure support performance. The examples cover ordinary transparent Litecoin, with BitPay’s published policy explained separately.
The invoice timer belongs to the checkout
An invoice usually preserves a price, an amount of LTC, a destination, a payment window and an order reference. Expiry ends the checkout’s offer to accept payment under those terms. It does not, by itself, invalidate an ordinary receiving address or erase an output already recorded on Litecoin.
Your wallet may reject an expired payment-protocol request. That is different from undoing a transaction it already broadcast. An old QR screenshot can still contain a technically usable destination; it is not permission to pay an old order. The payment-QR guide explains the request layer, while our cancellation guide covers what can change after sending.
For a self-custody recipient, an offline device does not have to acknowledge a payment for it to confirm. Our controlled offline-receiving test demonstrates the distinction between confirmed outputs and an out-of-date wallet display. A merchant order can also have a separate inventory or reservation deadline. Record the invoice ID and the order ID independently. A paid processor invoice does not itself establish that a merchant has dispatched the item.
Pause the retry and answer four questions
- Did you authorize anything? If you never signed, approved or submitted a withdrawal, return to the trusted checkout for current instructions. If you did, retain the original payment record before retrying.
- Is there a network transaction ID? Obtain it from the sending wallet or withdrawal history. A service request number is not necessarily a Litecoin transaction ID.
- Does the relevant output match? Compare the full destination, native Litecoin network and delivered LTC amount with the saved invoice. Look at that recipient output, not total transaction value.
- What does the receiving service say? Ask whether it credited, rejected, refunded or is reviewing the original payment. Use its official invoice or authenticated support channel.
If the lookup is unavailable, retain “unknown.” An expired checkout and an unavailable explorer do not prove that nothing was sent. Our transaction checker retrieves public records through Blockchair; it cannot establish a merchant’s internal order status. An ordinary public lookup needs no wallet connection or recovery words.
For a payment already attempted, do not infer permission to top up or pay a replacement invoice from the timer alone. First have the receiver reconcile the old payment and state the next instruction. If nothing was ever authorized, a fresh verified invoice is a different situation.
Put the clocks on one timeline
“I sent before expiry” is incomplete until you identify which clock produced the time. Keep the original timestamp and its offset, then normalize it to UTC for comparison.
| Time | Who records it | What it establishes |
|---|---|---|
| Invoice deadline | Checkout or processor | The stated acceptance cutoff; retain its timezone and terms. |
| Send or broadcast time | Your wallet or sending service | A local action or service record; identify which stage it represents. |
| First observation | A named node, explorer or processor | When that observer recorded the transaction, not when everyone received it. |
| Confirmation observation | A wallet, node or explorer | When that observer saw inclusion; distinct from the block header’s timestamp. |
| Invoice credit or settlement time | Receiving service | Its internal state transition; an explorer cannot supply it. |
In our fictional example, 2026-10-12T12:15:00+02:00 is the same deadline as 2026-10-12T10:15:00Z. The explicit +02:00 offset is part of the record; do not subtract two hours from every future local timestamp. A time with no timezone is incomplete for this comparison.
The wallet reports a broadcast at 10:14:40 UTC: 20 seconds before the cutoff. The processor records its first observation at 10:15:08 UTC: eight seconds after it. Both statements can be true. Neither the wallet’s clock nor a different explorer’s earlier observation proves that this processor accepted the payment before its deadline.
A block header time is also not an exact wall-clock receipt. Litecoin Core stores it as a header field and applies timestamp validity checks; it does not certify when you clicked Send or when a merchant’s server saw the payment. Record an observer’s check time separately. The header structure identifies the field.
What BitPay documents for its own invoices
BitPay’s supported-payment page includes Litecoin and says availability varies by shopper or merchant location. Check the actual checkout’s available asset and network. The following rules describe BitPay, not every shop that accepts LTC.
Its expiry help page describes a 15-minute window and says payments submitted to an expired invoice are declined, with a refund notification. The invoice API reference also exposes an acceptance-window setting and explicit expiration time. Use the actual invoice’s cutoff rather than treating 15 minutes as a Litecoin protocol rule.
Its state documentation distinguishes a payment received for evaluation from merchant-account settlement. It defines expired for an unpaid invoice whose window elapsed, and separate partial or excess-payment exceptions. A late-payment rejection concerns commercial acceptance; it does not mean the Litecoin transaction vanished.
Do not translate a word such as confirmed directly into a universal blockchain threshold. BitPay’s status mapping depends on configuration, and its documentation contains Bitcoin-specific confirmation examples. This guide does not assign those counts or timings to Litecoin. Ask for the current invoice’s state and applicable acceptance rule.
BitPay’s exception-refund instructions describe a notification, sign-in and collection of a refund destination. The reviewed instructions give that claim link a three-day validity; official support can issue another when it expires. This claim deadline is separate from the invoice deadline. A refund offered, a destination submitted and a refund executed are also separate stages.
Start with the verified invoice or official support if a notification is missing or questionable. A displayed sender address alone does not authenticate an email. Confirm the refund amount, denomination and any applicable deductions in the actual workflow; an automated notification is not proof that funds are back in your wallet.
Ten fictional cases that change the next question
All ten cases use a declared deadline of 12 October 2026, 12:15:00 at offset +02:00, or 10:15:00 UTC. The quoted amount is 0.40000000 LTC. Service outcomes below are supplied fictional snapshots, not outcomes predicted from time alone, and their labels are not a copy of BitPay’s API states.
| Case | Evidence time, UTC | Supplied service outcome | Next question or action |
|---|---|---|---|
| 1 · Never authorized | No send, signature or withdrawal request. | Expired; no payment associated. | Return to the trusted checkout for fresh instructions. |
| 2 · Seen before, confirmed later | Receiver saw it at 10:14:40; confirmation observed at 10:16:30. | Complete at 10:17:00. | Confirm order fulfillment; do not pay again because confirmation was later. |
| 3 · Broadcast before, receiver saw it later | Sender: 10:14:40; receiver: 10:15:08. | Declined; refund offered. | Ask which acceptance event was recorded and how to claim the original payment. |
| 4 · Different timezone displays | 12:14:30+02:00 equals 10:14:30Z. | Complete. | Preserve both original times; their display difference is not a late payment. |
| 5 · Exactly at the cutoff | Receiver observation: 10:15:00. | Manual review. | Ask how the receiver treats the boundary and what its full-resolution record shows. |
Case 5 deliberately receives an “at deadline” arithmetic label, not “accepted” or “rejected.” A timestamp rounded to whole seconds can conceal finer detail. The classroom comparison does not define the provider’s inclusive or exclusive boundary, clock accuracy or processing order.
| Case | Payment evidence | Supplied service outcome | Next question or action |
|---|---|---|---|
| 6 · Partial amount | 0.39800000 LTC; receiver observation at 10:14:30. | Partial payment; refund offered. | Ask about the 0.00200000 LTC shortfall and supported resolution; do not assume top-ups work. |
| 7 · Excess amount | 0.40200000 LTC; receiver observation at 10:14:30. | Order complete; excess refund offered. | Keep the order and the 0.00200000 LTC excess separate. |
| 8 · Lookup unavailable | Sending request exists; broadcast and output remain unknown. | Expired display; receipt unresolved. | Obtain the actual transaction ID and reconcile before retrying. |
| 9 · Different destination | Confirmed output differs from the saved invoice. | No matching invoice payment. | Investigate the destination mismatch; expiry does not explain it. |
| 10 · Different network | An LTC-labelled asset was sent on another network. | Unsupported-network review. | Ask for that service’s exact asset/network policy; recovery is not assured. |
Download the case CSV or complete JSON. Each record retains the deadline, original offsets, observed time basis, amount, destination/network comparison and supplied service snapshot. No usable address or transaction ID appears in the fixtures.
Keep the agreed LTC beside the new quote
A new live price does not rewrite an earlier payment agreement. In this fictional invoice, €24 at a declared quote of €60 per LTC requires exactly 0.40000000 LTC, or 40,000,000 litoshis. One litoshi is 0.00000001 LTC.
| Declared quote | Value of original 0.4 LTC | LTC for a fresh €24 quote | What changed? |
|---|---|---|---|
| €48 / LTC | €19.20 | 0.50000000 LTC | The illustrative price fell. |
| €60 / LTC | €24.00 | 0.40000000 LTC | Same illustrative price. |
| €80 / LTC | €32.00 | 0.30000000 LTC | The illustrative price rose. |
At €48, the 0.1 LTC difference is a fresh-quote comparison, not a payment you have been told to send. Whether a late 0.4 LTC payment is honored, refunded or handled another way requires the receiver’s policy and an explicit resolution. Do not silently combine an old receipt with a new quote.
Keep the invoiced recipient amount separate from your wallet’s network fee and any service withdrawal charge. An output of 0.398 LTC remains short of a 0.4 LTC requirement even when your sending service debited 0.4. Our refund and underpayment guide covers those accounting choices in detail; this worksheet helps decide what must be resolved before another payment.
Send one private question with the relevant evidence
Use the original order’s authenticated channel. Supply the invoice reference, stated deadline with timezone, actual transaction ID, relevant output destination and amount, observation source/time, and the receiver’s latest status. Keep account references and transaction-to-identity links out of public posts.
A useful message is: “Invoice [reference] expired at [timestamp with offset]. I attempted payment at [time and stage]. The matching output is [amount] LTC; [source] observed [status] at [time]. Please reconcile the original payment and confirm whether it is credited, awaiting review or eligible for refund before I pay a replacement invoice.” The editable private template includes unknown fields.
No seed phrase, private key, wallet backup or password belongs in this request. If a refund needs a destination, obtain and verify it through your trusted receiving wallet or service and submit it through the authenticated refund process. An input address in an explorer may belong to a sending exchange’s shared wallet. Do not treat it as your refund destination. See our payment-support guide.
Use the worksheet and preserve the receiver’s answer
Print the expiry checklist. Our payment tool can reconcile supplied invoice and receipt records; it does not independently verify chain delivery or dictate a processor’s late-payment policy. The receiving-payment learning path explains the receiver’s checks.
When support resolves the case, retain its instruction, the original payment record and any separate refund transaction ID. A request for a refund, a refund processing notice and the returned output are different evidence. Preserve later updates rather than overwriting the earlier observation.
Source review: 12 October 2026. The method record, primary sources and offline Python reproducer document the constructed cases. The script uses explicit timezone offsets and integer litoshis; it checks arithmetic and selected next questions, not provider behavior. Verify downloads against the release checksums.
There were no real transactions, merchant integration tests or measured customer outcomes. Private MWEB receipt reconstruction and wrong-network recovery are outside this guide’s scope. Research and drafting used AI assistance; no independent external review is claimed. Send corrections through our corrections page.
The artwork record identifies the generated conceptual hero and original explanatory diagram.
