Handling Litecoin payment refunds and underpayments

Research checked 22 September 2026. Methods and reproducible files are documented below. The hero is an AI-generated editorial illustration.

A customer owes $120. The checkout quotes 1.5 LTC, but only 1.49 LTC arrives. The missing 0.01 LTC may have been deducted by the customer's exchange as a withdrawal charge. The order is still short unless your published tolerance permits it. A screenshot showing “1.5 LTC sent” does not change the amount credited to the invoice.

This guide follows that invoice through underpayment, overpayment, expiry and refunds after a price change. It includes a six-case refund sensitivity table, a partial-refund example and an acceptance checklist for testing your own checkout. Prices, fees and invoice identifiers below are illustrative.

Separate the invoice, the payment and the refund

The invoice records the commercial amount, payment quote, expiry and order reference. The payment records what arrived, on which network, when and with what confirmation state. A refund is a new outgoing payment with its own authorization, destination, fee and transaction ID. None of those records replaces the others.

A processor can see an incoming transaction before your required confirmation threshold is reached. Conversely, an invoice timer can expire before an already-sent payment is noticed. Keep “observed,” “sufficient amount,” “sufficient confirmations” and “eligible for fulfillment” as separate facts rather than compressing everything into one green “paid” label.

BTCPay Server documents partial, late, overpaid, processing and settled invoice states. Its status names are useful examples, not universal names used by every processor. Its altcoin documentation also makes clear that supported alternative coins depend on the deployment and maintenance setup. Check that the actual instance supports your intended Litecoin workflow before copying a Bitcoin-oriented example. Invoice states; altcoin support.

Record the quote before accepting payment

For our example, invoice LW-120 is denominated in USD: $120 at an illustrative quote of $80 per LTC, payable as 1.50000000 LTC. The quote expires after a chosen checkout window. The duration is a merchant setting, not a Litecoin protocol rule.

Store the quote and its timestamp, not just a link to a live price page. A changing market feed cannot recreate what the buyer agreed to at checkout. State whether the quote includes a conversion spread and how rounding works. For an amount denominated in LTC, retain all eight decimals even if the customer's currency display uses two.

Underpayment: reconcile the actual credited amount

Suppose 1.49000000 LTC arrives before expiry. The shortfall is 0.01000000 LTC, worth $0.80 at the invoice's $80 quote. A buyer may have requested a 1.5 LTC withdrawal while their exchange deducted a 0.01 LTC charge. That example is not a statement about any provider's current fee schedule.

If the original quote remains valid and your processor supports top-ups, request the exact remaining credited amount. Explain that the buyer must account for their sending service's fee so the full top-up reaches the invoice. If the quote has expired, decide explicitly whether to honor it, agree a new amount or refund the received payment. Do not silently combine the first payment's old quote with a new live conversion.

An underpayment tolerance can prevent tiny rounding differences from blocking an order. Set it deliberately in currency or percentage terms, disclose the policy and test the boundary. A tolerance of $1 has a different business effect on a $5 order than a $5,000 order. It should not expand automatically merely because the incoming payment would otherwise fail.

Overpayment and late payment

If 1.55 LTC arrives against the 1.5 LTC invoice, the excess is 0.05 LTC. Keep the original sale and the excess separate in your records. Depending on the agreed terms and applicable obligations, resolve the excess by an authorized refund or another agreed treatment. Do not relabel the additional coins as revenue without establishing why you are entitled to keep them.

A payment arriving after expiry can still be a real payment to an address you control. Expiry of a checkout quote does not erase the on-chain receipt. Do not automatically create a replacement invoice and collect again without first checking the original one. Use a manual review state when the amount, timing or fulfillment decision is unresolved.

BTCPay's documentation distinguishes late or partial payment from settled payment and notes that archived invoices can still detect later receipts. That is why archiving an old invoice should not be treated as evidence that no funds can ever arrive. The status table is a source for workflow design; it is not a guarantee that your integration processes every event correctly.

Choose the refund unit before the price changes

A full refund of “the original 1.5 LTC” and a refund of “the original $120 converted to LTC at refund time” produce different outcomes. The choice should follow the contract, applicable consumer rules and the refund basis disclosed to the buyer. The arithmetic alone does not determine which policy is permissible.

Here are the two policies at three hypothetical refund-time prices. Network fees are excluded from this table and considered separately below.

At $60 per LTC, returning the original coins gives the customer $90 of market value; returning $120 requires 2 LTC. At $100, the original coins are worth $150, while a $120 refund requires 1.2 LTC. Neither difference is a blockchain fee. It is the consequence of the refund denomination and the price change.

Do not promise a fiat-denominated refund while retaining too little liquidity to make it at a lower LTC price. Conversely, if a valid agreed policy denominates the obligation in LTC, converting all received coins to fiat leaves the merchant exposed to the cost of repurchasing LTC if its price rises. Inventory and refund policy should be considered together.

Partial refunds need an explicit basis

Suppose the customer returns a $30 item from the original $120 order. Under an original-USD policy, the refund is $30 converted at the chosen refund quote: 0.5 LTC at $60 or 0.3 LTC at $100. Under a proportional original-LTC policy, 25% of 1.5 LTC is 0.375 LTC, worth $22.50 or $37.50 at those prices.

Record the item-level amount, any shipping or discount allocation, prior refunds and the remaining refundable balance. Avoid independently rounding every line in a way that makes several partial refunds exceed the original obligation. Keep an exact base-unit total and apply a documented final-rounding rule.

Account for the outgoing fee once

Assume a USD-based $120 refund at a $100 LTC quote, giving the customer 1.2 LTC. If the merchant pays an illustrative 0.0001 LTC network fee in addition, the wallet debit is 1.2001 LTC and the recipient receives 1.2 LTC. At that quote the merchant's total outlay is $120.01.

If instead the wallet subtracts that fee from the recipient amount, the customer receives 1.1999 LTC, worth $119.99 at the same quote. That does not fulfill an unqualified $120 refund promise. Check the wallet's “subtract fee from amount” behavior and any legally permitted, disclosed charge before sending. Our example does not endorse deducting return fees from a consumer refund.

Use the fee dashboard to understand network conditions and the sending wallet's actual transaction estimate for the payment you are constructing. A public average does not determine the fee for a particular transaction. The calculator can check conversions, but retain the refund quote you actually approved.

Get a refund destination from the authenticated customer

Do not automatically refund an input address found in a blockchain explorer. An exchange withdrawal can originate from a shared wallet the buyer does not control individually. A copied address from a recent transaction can also be unrelated to the customer's intended deposit route.

Collect the destination through an authenticated order or refund process. Confirm native Litecoin network support, address compatibility and any restrictions of the receiving service. Use our address-format guide for the technical distinctions, but check the recipient's actual service documentation. Do not assume an exchange accepts an MWEB route because it accepts other LTC deposits.

BTCPay's documented refund workflow asks the customer to claim a refund through a link, after which the merchant processes the payout. That separates destination collection from payout authorization. Confirm that your chosen deployment and payment method implement the corresponding Litecoin flow. BTCPay refund workflow.

Prevent a retry from becoming a second refund

Assign each refund a stable ID linked to the invoice and the specific partial-refund request. Repeated webhook delivery, a browser refresh or a support agent clicking twice should refer to that same refund record. Record approval before sending, then persist the outgoing transaction ID and settlement state.

If a network request times out after broadcast, first inspect the wallet and existing transaction record. A timeout does not prove the transaction was never sent. Retrying the same broadcast and creating another payment are different operations. The latter can pay the customer twice.

These are acceptance scenarios for your integration, not results from a live merchant deployment. We checked the example arithmetic and state distinctions against the cited documentation; we did not process real customer payments. Run the cases in your processor's supported test environment, then use a small-value live rehearsal before relying on automation.

A refund record support staff can actually use

Keep the original invoice amount and currency, quoted LTC amount, credited receipts, confirmation evidence, refund reason, approved basis, refund quote and timestamp, destination confirmation, gross recipient amount, fee payer, outgoing transaction ID and final status. Separate who requested the refund from who approved and sent it.

A customer-facing confirmation can be short: “Refund for order LW-120: USD 120, converted at USD 100 per LTC, recipient amount 1.20000000 LTC. Merchant pays the network fee. Destination confirmed through your order account. Transaction: [actual transaction link].” Use real approved values and send it only after the corresponding action is recorded.

Downloads and related guides

Download the six refund calculations, acceptance scenarios, blank refund-record template and calculation script. Continue with our merchant payment guide and transaction-verification guide for the original checkout and confirmation process.

Frequently asked questions

Does an expired invoice mean the customer has not paid?

No. The quote can expire while funds are still sent or later detected. Check the actual receipts and resolve a late payment before requesting another payment.

Should a refund return the same LTC amount?

It depends on the valid agreed refund basis and applicable obligations. Returning the original coin amount and returning the original fiat value are different policies, especially after a price change.

Sources and method

Example calculations and workflow scenarios were prepared and checked on 22 September 2026. They use synthetic quotes and fees, decimal arithmetic and the BTCPay invoice, refund and altcoin documents linked above. They are not a legal determination of a merchant's refund obligations. For EU consumer context, consult the official Your Europe returns guidance and assess the rules applicable to the actual customer and sale.