feat: add quickpay daily spend limit

[ovitrif]

Closes #1168

iOS port:

• Issue: Port QuickPay daily spend limit from Android bitkit-ios#670
• PR: feat: add quickpay daily spend limit bitkit-ios#672

QuickPay stays PIN-free under limits (the point of QuickPay). A hard payment-PIN skip would remove that behavior, so this PR bounds auto-pay with a daily spend multiplier instead. Payments above the daily cap open Confirm, where PIN for payments still applies. Lock-time deferral remains in #1158.

Description

• Keep QuickPay confirmation-free and PIN-free while under the per-tx threshold and daily cap
• Add a daily limit multiplier on QuickPay settings (1, 3, 5, 10, 50; default 5)
• Daily cap is threshold × multiplier in USD cents; spend rolls forward on the local calendar day
• Bind spend to the invoice payment hash before send; settle only through signalCompletion; keep spend on success; release matching-day failure only
• Over the daily cap, or if reserve fails at pay time → Confirm (replaces QuickPay; payment PIN only if that setting is on)
• QuickPay success shows the amount with routing fee; Confirm keeps the invoice amount
• Unlock/lock scan deferral from fix: secure shop payments and locked links #1158
• Slider: labels included in layout bounds; tap settles from the current value (no jump back to the first on-screen value)
• Internal architecture: QuickPayRepo owns sessions, in-flight ops, dispatch, and the daily-cap ledger. QuickPaySpendStore is an internal class in the same file.

Out of scope

• RTL slider thumb offset: same on master, not a new regression
• Clock or timezone jumps: rollback keeps spend; only a later local date opens a new bucket
• In-flight spend after process death past midnight: at most one under-count on the new day, no over-count
• Scanning an invoice that already paid: success shows the invoice amount, without the routing fee. The daily cap still counted it
• Compose test for the QuickPay fallback snapshot: covered in QuickPayViewModelTest

Preview

Updated screenshot, integrating designer's feedback.

Screenshot

QuickPay Settings	Over Cap → Confirm + PIN
slider.mp4	1159-over-daily-cap-confirm-pin.mp4

QA Notes

Manual Tests

• 1. Settings → QuickPay: both sliders visible; tap a different stop snaps there without jumping to the first step; page scrolls when dragging vertically from a thumb; resolved daily $ copy updates
• 2. Unlocked, under per-tx and daily cap, PIN for payments on → scan / paste a small LN invoice: QuickPay then success (no Confirm / payment PIN); success amount includes routing fee
• 3. After the daily cap is filled → scan another under-threshold invoice: Confirm; swipe can ask for PIN
• 4. Pay-time reserve miss / overlapping pay: Confirm replaces QuickPay; back does not return to an idle QuickPay loader
• 5. Hold-invoice QuickPay that later fails: failure UI; a following under-cap invoice still QuickPays
• 6. Hold-invoice QuickPay that later succeeds: success amount includes fee; spend counts toward the cap
• 7. Confirm Lightning send (over threshold or QuickPay off) that settles immediately: success amount is the invoice amount
• 8. Confirm Lightning send through Pending, then success: success amount is still the invoice amount
• 9. regression: Cold start / locked with PIN → scan stays deferred until unlock (fix: secure shop payments and locked links #1158), then follows the rules above

Automated Checks

• Unit tests added in QuickPayRepoTest.kt:
  • daily-cap reserveBound
  • matching-day release
  • conversion failure
  • signalCompletion success keeps spend
  • signalCompletion failure rolls back
  • signalCompletion is idempotent
  • dual-alias settle
  • inlined iOS/Android ledger decode
  • dispatch-error classification
  • duplicate payment with pending LDK does not refund
  • recovered hash after reload
  • concurrent same-hash pay does not fall back to Confirm
  • live dispatched ops stay out of reconcile
  • re-pay of a settled hash does not double-count
  • reservation persists before dispatch
  • detach before dispatch aborts and releases
  • pre-dispatch rejection refunds
  • null payment rows mutate nothing
  • rescan of a live Pending invoice replays Pending
  • live records survive day prune
  • lookup throw leaves spend unchanged
  • zombie rescan after detach timeout replays Pending
  • detachAll does not sweep a session attached after snapshot
• Unit tests added in QuickPayViewModelTest.kt:
  • session success mapping
  • session pending mapping
  • session error mapping
  • pay forwards to the repo
  • stale-session detach
  • pay re-entry is guarded until attach resets
• Unit tests modified in AppViewModelSendFlowTest.kt:
  • under-cap QuickPay vs over-cap Confirm
  • pending settlement through signalCompletion
  • open hash routes to QuickPay when cap would skip
  • null-hash PaymentFailed still resolves Pending
  • contact flow wins over an open hash
  • open-hash routing intentionally bypasses the QuickPay-enabled setting
• Unit tests modified in PendingPaymentRepoTest.kt:
  • late collector does not receive a buffered resolution
• Unit tests modified in SendPendingViewModelTest.kt
• Instrumented tests modified: daily-limit slider tags in QuickPaySettingsScreenTest.kt
• CI: standard compile, unit test, and detekt checks run by the PR bot.

[greptile-apps]

Greptile Summary

This PR adds a persistent daily spending cap to QuickPay and coordinates reservation, dispatch, pending, and completion state across payment lifecycles.

• Adds configurable QuickPay daily-limit multipliers and settings UI.
• Introduces a persistent payment-hash-bound QuickPay ledger with reconciliation.
• Routes over-cap or failed reservations to the normal confirmation flow.
• Updates pending-payment resolution and success amount handling.

Confidence Score: 5/5

The PR appears safe to merge because no blocking failure remains within the eligible follow-up review scope.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/repositories/QuickPayRepo.kt	Introduces QuickPay sessions, payment dispatch coordination, persistent daily-cap reservations, completion settlement, and LDK reconciliation.
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Integrates daily-cap eligibility and QuickPay completion outcomes into Lightning request routing and settlement.
app/src/main/java/to/bitkit/repositories/PendingPaymentRepo.kt	Replaces buffered resolution delivery with hash-addressable resolution storage and explicit consumption.
app/src/main/java/to/bitkit/viewmodels/QuickPayViewModel.kt	Delegates QuickPay payment lifecycle management to QuickPayRepo and maps session events into UI state.
app/src/main/java/to/bitkit/ui/settings/quickPay/QuickPaySettingsScreen.kt	Adds the configurable daily-limit multiplier and resolved daily-limit presentation.
app/src/main/java/to/bitkit/ui/components/Slider.kt	Updates slider gesture handling, tap selection, and label-aware layout behavior.
app/src/main/java/to/bitkit/repositories/LightningRepo.kt	Adds a pre-dispatch callback and payment lookup support needed by QuickPay reservation and reconciliation.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Decoded Lightning request] --> B{QuickPay enabled and per-tx eligible?}
  B -- No --> C[Confirm payment]
  B -- Yes --> D{Daily-cap reservation succeeds?}
  D -- No --> C
  D -- Yes --> E[Persist hash-bound reservation]
  E --> F[Dispatch Lightning payment]
  F --> G{Completion before timeout?}
  G -- Success --> H[Keep daily spend and show success]
  G -- Failure --> I[Release matching-day spend and show error]
  G -- No --> J[Show pending]
  J --> K[Later completion signal]
  K --> H
  K --> I

Loading

_{Reviews (4): Last reviewed commit: "fix: keep quickpay data during fallback ..." | Re-trigger Greptile}