fix: add quickpay daily spend limit

[ovitrif]

Stacked on #1158.

iOS port: synonymdev/bitkit-ios#670.

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); spend resets on the local calendar day
• Record QuickPay USD spend on Success/Pending only
• Over the daily cap → Confirm (payment PIN only if that setting is on)
• Unlock/lock scan deferral unchanged 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)

flowchart TD
  incoming[Payment request]
  locked{App unlocked?}
  qpOn{QuickPay on and amount at or under per-tx threshold?}
  daily{spentTodayUsd plus amountUsd at or under dailyCapUsd?}
  quickpay[QuickPay auto-pay no PIN]
  confirm[Confirm then payment PIN if enabled]
  queue[Defer until unlock]

  incoming --> locked
  locked -->|no| queue
  queue --> locked
  locked -->|yes| qpOn
  qpOn -->|no| confirm
  qpOn -->|yes| daily
  daily -->|yes| quickpay
  daily -->|no| confirm

Loading

Preview

QA Notes

• 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)
• Unit: AppViewModelSendFlowTest.kt, CacheStoreTest.kt

[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}