fix: add quickpay daily spend limit

[ovitrif]

Closes #1168

Builds on merged #1158 (base is master).

iOS port:

• Issue: Port QuickPay daily spend limit from Android bitkit-ios#670
• PR: fix: 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 (USD threshold, sat accounting); spend rolls forward on the local calendar day
• Reserve QuickPay sat spend before payInvoice; keep on Success/Pending, release on confirmed failure
• Over the daily cap → Confirm (payment PIN only if that setting is on)
• 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)

Preview

Under daily cap → QuickPay settings	Over daily cap → Confirm + PIN
1159-happy-quickpay-under-cap.mp4	1159-over-daily-cap-confirm-pin.mp4

QA Notes

• Unit: AppViewModelSendFlowTest.kt, CacheStoreTest.kt
• Settings → QuickPay: enable QuickPay, set threshold and daily multiplier; confirm the resolved daily $ copy updates
• Unlocked, under per-tx and daily cap, with PIN for payments on → QuickPay (no payment PIN)
• Exhaust or exceed the daily cap → Confirm; payment PIN if enabled
• Cold start / locked with PIN → scan stays deferred until unlock (fix: secure shop payments and locked links #1158), then follows the rules above
• Slider tap between steps: knob animates from the current value to the closest step (no flash to the value from first open)

[greptile-apps]

Greptile Summary

The PR restores payment authentication for QuickPay-eligible payments when both the app PIN and PIN-for-payments setting are enabled.

• Centralizes QuickPay eligibility in canApplyQuickPay.
• Routes protected payments through the existing Confirm flow instead of QuickPay.
• Adds tests for protected, unprotected, and deferred locked-scan behavior.
• Adds a security changelog entry.

Confidence Score: 5/5

The PR appears safe to merge, with protected QuickPay-eligible payments correctly redirected into the existing authenticated confirmation flow.

The new eligibility condition is consistent with the confirmation screen’s authentication gate, and the changed tests cover both protected and unprotected settings as well as deferred processing after unlock.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Adds a centralized eligibility guard that prevents QuickPay when payment authentication is enabled and falls through to the existing authenticated Confirm flow.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Updates send-flow coverage to verify protected payments skip QuickPay while preserving QuickPay when payment authentication is disabled.
changelog.d/next/require-payment-pin.security.md	Accurately documents that QuickPay now honors the payment-PIN setting.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[QuickPay-eligible payment] --> B{QuickPay enabled and amount nonzero?}
    B -- No --> C[Open Confirm]
    B -- Yes --> D{PIN and PIN for payments enabled?}
    D -- Yes --> C
    D -- No --> E{Amount within QuickPay threshold?}
    E -- Yes --> F[Open QuickPay]
    E -- No --> C
    C --> G[Swipe to pay]
    G --> H[PIN or biometric authentication]
    H --> I[Submit payment]

Loading

_{Reviews (1): Last reviewed commit: "fix: require payment pin for quickpay" | Re-trigger Greptile}

[ben-kaufman]

Review findings are inline.

[ben-kaufman]

Re-audit findings are inline.