just send the amount as bigint

[n13]

use big int for wire transport, no need for parsing and formatting

this is less error prone too

❯ xcrun simctl openurl booted "https://www.quantus.com/pay?to<ADDRESS>&amount=126147900000000&ref=TEST123"

[n13]

Maybe it's better to have human readable numbers?!

[n13]

Here's my review of PR #497 — "just send the amount as bigint".

Summary

The PR replaces locale-aware wire-amount formatting (1.5 QUAN, or legacy 1,5) with the raw planck integer (1500000000000) in POS payment URLs. Net change: +11 / −97, removing formatWireAmount / parseWireAmount and their tolerance for mixed locale separators. Sender uses BigInt.toString(), receiver uses BigInt.tryParse().

Verdict: LGTM with a couple of notes

This is a clean, well-motivated simplification — the rationale ("less error prone, no parsing/formatting") is sound. Machine-to-machine wire transport of a fixed-precision integer has no business going through a decimal/locale codec. Strong DRY win, removes a whole class of locale ambiguity (comma vs dot decimal mark), and the tests stay coherent with the new shape.

Things I'd flag before merging

1. Breaking change for any legacy QR codes. Old POS QRs encoded amount=1.5. With the new receiver, BigInt.tryParse('1.5') returns null and falls back to BigInt.zero — a silent zero-amount parse, not an error. If POS is not yet shipped to users this is fine; if any legacy QRs exist in the wild they will silently round-trip to 0.

2. Silent fallback to BigInt.zero on parse failure (in input_amount_screen.dart):

BigInt.tryParse(widget.initialAmount!) ?? BigInt.zero

Pre-existing behavior, not a regression, but worth surfacing: a malformed amount= query param is silently treated as 0 rather than raising or showing an error to the user. The planck > BigInt.zero guard prevents acting on it, so it's safe — just opaque to the user.

3. URL human-readability regression. amount=126147900000000 is opaque to anyone eyeballing a deep-link vs the previous amount=1.5. Acceptable for QR/POS (machine-only), worth a thought if these URLs are ever shared by humans (e.g. SMS, chat).

4. Test coverage shrinks meaningfully. The 37-line formatWireAmount / parseWireAmount group is gone — correctly, since the methods are gone. The remaining pos_service_test.dart only asserts amount=1500000000000 appears in the URL. Consider one extra round-trip test on the receiver side (BigInt.tryParse of the URL value equals the planck the sender used), so the wire contract is pinned end-to-end.

5. PosPaymentRequest.amount field removed. Quick grep for any UI reference to request.amount would be worth doing — the visible diff in pos_qr_screen.dart doesn't use it, but worth a final sweep.

6. Negative amounts. BigInt.tryParse('-1000') succeeds. The downstream planck > BigInt.zero check already filters it, so no exploit, just noting it.

Suggested follow-ups (non-blocking)

• Add an explicit end-to-end test: PosService produces URL → extract amount query param → BigInt.tryParse equals the original planck.
• Consider making the receiver loud about parse failures (throw / show error toast) instead of ?? BigInt.zero, per the team's fail-early principle — but that's a separate PR.

Overall: ship it. The simplification is the right call for a machine-readable wire format.