What a Litecoin payment QR code actually tells your wallet

For a Litecoin payment, the useful information is usually a destination address, an optional amount and an optional note. The square pattern does not add a signature or make those fields authoritative. A scanner can read the pattern perfectly while the wallet rejects the destination—or while an application still needs to reject an invalid amount.

Study release 2026-09-30.1. This is a parser and digital QR round-trip study, not a phone-camera or full wallet-app compatibility test. The hero is an AI-generated abstract illustration and is not a functional payment code.

Read the text inside the square

litecoin:EXAMPLE-NOT-A-PAYMENT?amount=0.125&label=Invoice%2017

This deliberately invalid destination makes the example safe to inspect without creating a payable request. In a real invoice, replace it with a receiving address obtained from the intended wallet. The amount is expressed in LTC: 0.125 means one eighth of a Litecoin. It does not mean €0.125, $0.125 or 0.125 litoshis.

The long-used BIP21-style format supplies the background for these fields. BIP21 is a Bitcoin specification and has been superseded there by BIP321; that status does not imply every Litecoin wallet implements the replacement. We checked Litecoin-specific source and pinned versions rather than assuming support from a standard’s name.

Two scan examples with different payloads

Both SVGs below contain the same invalid destination. The first carries only the address placeholder; the second adds an amount and label. A generic QR reader should be able to reveal the text, while a wallet must reject the destination. These are educational fixtures, not donation requests.

The first symbol uses a 25-by-25 module grid and the second 33-by-33, excluding the four-module quiet zone. More data increased the symbol size in this controlled encoding. Both use error-correction level M. We decoded the generated module rasters with zxing-cpp and matched every character. That check does not measure how either code behaves on a damaged printout or a particular phone camera.

What the two parsers returned

We tested Electrum-LTC 4.2.2.1’s unchanged URI and address-validation functions in an isolated source harness, and the published bip21 3.0.0 JavaScript library configured for the Litecoin scheme. Electrum’s full application and GUI were not launched. The JavaScript library is a decoder, not a wallet; its README explicitly requires callers to check the address.

“Accepted” below means only that the tested function returned data. It does not mean a wallet would display, sign or broadcast the corresponding payment. The test corpus uses synthetic address hashes with no known private keys; they must never be funded.

The ninth decimal is a useful example of why a successful decode is not sufficient validation. One implementation reduced the precision; the other preserved a value that still needs conversion to Litecoin’s indivisible unit. Applications should reject an unsupported precision deliberately rather than silently turn a customer’s instruction into a different value.

The negative-amount observation is also confined to the parsing stage. It does not demonstrate that Electrum-LTC can send a negative payment. A wallet has later checks when constructing and approving a transaction. We include the returned value because developers need to know where validation actually occurs, not because a parser result proves an exploitable wallet defect.

An unfamiliar field can be lost or ignored

An ordinary optional query parameter may be ignored by software that does not understand it. The historical BIP21 convention gives fields beginning req- a different meaning: an implementation that does not understand them should reject the request. Both tested parsing functions returned our synthetic req-invoice field. That result leaves any enforcement to another layer and is not evidence that the invoice requirement was honored.

We separately read Litecoin Core 0.21.5.8’s GUI URI parser: its unknown-required-field branch returns failure. This is a source inspection, not a Core GUI scan test, and therefore is not presented as another measured wallet result.

A merchant should keep their invoice requirements in the checkout system and verify the actual payment against them. Adding invoice=17 to a URI does not guarantee that every wallet preserves it or writes it into the blockchain. Standard address-and-amount outputs do not carry the URI’s label as an on-chain message.

Spaces, ampersands and decimal separators

URI query strings use & to separate fields. In our malformed-label case, the unescaped text label=Cafe & invoice 17 was not recovered as one complete label by either implementation. Encoding the intended ampersand as %26 and the space as %20 preserved the text. UTF-8 percent encoding also preserved the accented character in Café.

For a request generator, build the query with an encoding library rather than concatenating raw customer text. Use a plain decimal point for LTC amounts, up to eight decimal places, and integer litoshis internally where practical. Our test parsers accepted scientific notation, but that observation is not a reason to emit it: ordinary decimal notation avoids relying on permissive behavior outside the basic amount grammar.

The Litecoin.watch payment request tool checks supported Litecoin addresses and uses a strict amount input before constructing the URI. Its fields are deliberately narrower than every possible extension. It is a request generator, not a universal URI importer or a substitute for the receiving wallet’s own review.

An expired invoice can still receive coins

A QR code does not control the blockchain. In our fixture with time=1&exp=1, both parsers returned metadata; neither parsing call proved or enforced a business deadline. A checkout can stop displaying an expired request, but an old screenshot can still contain a valid destination.

Handle late payments as invoice exceptions. Record the amount, observation time, transaction ID and agreed exchange-rate policy, then decide whether to honor, supplement or refund the payment. The refund and underpayment guide gives a practical record to keep. A label or expiry field is not an on-chain cancellation mechanism.

Before approving a scanned payment

1. Check the destination through the trusted checkout or recipient. A valid checksum catches certain transcription errors, not a malicious replacement with another valid address.
2. Read the amount and unit. Confirm LTC and the decimal placement. If the request supplied no amount, enter it from the agreed invoice rather than guessing.
3. Review the fee and total separately. The requested recipient amount and the wallet’s miner fee are different parts of the transaction.
4. Treat the label as unverified text. Avoid personal or confidential information in a request that can be photographed or logged.
5. After sending, verify the output and confirmation status. Use your wallet record and, if appropriate, the transaction checker. A QR image is never the receipt.

Download the corpus and reproduce the observations

Study ZIP · 20-input corpus · Electrum function results · CSV · JavaScript library results · QR round-trip checks · Exact scope and commands · SHA-256 checksums

The Python harness extracts selected function definitions without changing their bodies, uses the upstream Base58Check and SegWit validators, records source hashes, and omits unrelated wallet startup and cryptographic signing dependencies. It is a reproducible source-function experiment, not execution of the complete Electrum release. The JavaScript run uses a pinned package and lockfile. The package also explains how to regenerate the two safe QR symbols.

No seed phrase, wallet file, real payment, operating-system URI handler, mobile app, camera, printed code, signed payment request or MWEB address was tested. These boundaries matter: the useful finding is that each layer—QR decoding, URI parsing, destination validation and payment approval—must be checked on its own.