fix: pay first onchain subscription period in one swipe

[jvsena42]

Stacked on #1421.

This PR makes accepting a subscription a single swipe when the first payment is paid on-chain, matching the Subscriptions flow in Figma and the existing Lightning behaviour.

Description

• Before, an on-chain first payment took two swipes: Swipe To Subscribe & Pay on the Review sheet only subscribed, then the send confirmation opened with a second Swipe To Subscribe & Pay to pay. Figma shows one swipe from Review & Subscribe to Subscribed, and its flow notes do not limit that to Lightning.
• SendUiState.shouldAutomaticallyPay no longer requires the Lightning pay method, so the first payment due on acceptance starts by itself for on-chain savings too.
• While that first payment is sent, the sheet keeps the Review & Subscribe layout (amount, subscription card, illustration) with the swipe in its loading state, for Lightning and on-chain. Before, the send step replaced it with a bare progress indicator.
• The swipe on the Review sheet now stays visible while the subscription is being accepted; it used to disappear once the proposal turned active.
• The Review sheet no longer shows the First billing period ends … Each period is charged in full. line, which is not in the Figma frame. It was added in ef50785 to disclose that a short first period is charged in full.
• The swipe on the Review sheet reads Swipe To Subscribe, as in Figma, whether or not a first payment is due. It used to read Swipe To Subscribe & Pay when one was.
• The clock illustration on the Review sheet is drawn at the frame's size and 15° rotation. It is the same asset as in Figma, previously shown smaller and unrotated.
• A hardware wallet still opens the send confirmation, because the device has to sign.
• PIN or biometric confirmation for payments and the existing send warnings (over 50% of balance, fee over 50% of the amount, and the others) still run before the payment is sent.
• This reverses the on-chain part of d7d7ab0 (fix: confirm initial subscription fees, feat: add Paykit subscriptions #1186): the network fee for the first on-chain payment is no longer shown before it is paid.

Out of Scope

• bitkit-ios: ported in fix: pay first onchain subscription period in one swipe bitkit-ios#881.
• SubscriptionsScreen.kt: the Figma Automatically pay this subscription switch. Follow-up: neither platform has an auto-pay setting yet, so later periods are still paid by hand from the Subscription Payment Due notification, and a working switch needs the same background payment path as the item below.
• SendConfirmScreen.kt: showing the on-chain fee somewhere in the single-swipe flow; Figma has no fee display in this section.
• AppViewModel.kt: sending the first payment in the background so the swipe only waits for the Paykit request. Follow-up: in the recorded run the Paykit request (accept, then the payee's updated payment list) took about 4 min 20 s and the payment about 50 s, and the payment still runs through the Send sheet state, its PIN/biometric check, the send warnings and the First Payment Failed screen.

Design

• Subscribe to Subscription
• Subscription Subscribed

Preview

Pixel 9 emulator, dev build on regtest, payer with on-chain savings only, proposal sent from a second emulator. After: 5,000 sats plus a 141 sat fee left the wallet with one swipe.

Recording of the single swipe. The wait between the swipe and Subscribed took about five and a half minutes on the emulator and is sped up 20x; the first and last nine seconds are real time.

subscription_single_swipe_v4.mp4

QA Notes

Journeys

• updated review-and-subscribe.xml — with the first period due on acceptance and on-chain savings only, one swipe keeps the Review and Subscribe layout with the swipe loading and ends on Subscribed with no second swipe

Manual Tests

N/A

Automated Checks

• updated AppViewModelSendFlowTest.kt — an initial on-chain subscription payment starts automatically, and a hardware wallet one still requires confirmation
• updated SendConfirmScreenTest.kt — the send confirmation shows no swipe control of its own for an initial on-chain subscription payment
• ran just compile, just test, just lint — pass locally; SendConfirmScreenTest.kt compiles but was not run on a device

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Changes when subscription payments auto-confirm without user swipe.

The PR appears safe to merge; no actionable issues were found.

What we checked:

• Payment checks remain in place: Automatic start calls onSwipeToPay. The confirmation screen still requests PIN or biometrics when payment authentication is enabled.
• Amount is ready before confirmation: The incoming on-chain payment path checks the amount and sets isAmountInputValid before opening confirmation.

Summary

First on-chain subscription payments now start after the subscription swipe, matching the existing Lightning flow.

• Hardware wallets still require confirmation and device signing.
• Payment warnings and PIN or biometric checks remain in the send flow.
• Tests and journey notes reflect the single-swipe behavior.
• jvsena42 explicitly deferred showing the first on-chain fee and porting this behavior to iOS.
• No actionable issues were found. Tests were inspected, not run.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Swipe to subscribe and pay] --> B[Prepare first payment]
  B --> C{Hardware wallet?}
  C -->|No| D[Start payment automatically]
  C -->|Yes| E[Show manual confirmation]
  D --> F[Check payment warnings]
  E --> F
  F --> G[Request PIN or biometrics if enabled]
  G --> H{Hardware wallet?}
  H -->|Yes| I[Sign on device]
  H -->|No| J[Send payment]
  I --> J
  J --> K[Show Subscribed]

Loading

_{Reviews (1) · Last reviewed commit: "chore: add subscription single swipe cha..."}

[github-actions]

Regtest APK

Built from b52685a (run).

Download bitkit-dev-debug universal APK (expires in 30 days).