## ADDED Requirements

### Requirement: Wallet recharge confirmation SHALL prevent duplicate submission
The system SHALL prevent repeated taps on the wallet recharge confirmation button from starting more than one recharge submission flow at the same time.

#### Scenario: User taps confirm recharge repeatedly during submission
- **WHEN** the user taps the wallet recharge confirmation button multiple times before the current `confirmRecharge` flow completes
- **THEN** the system SHALL execute only the first submission flow
- **AND** the system SHALL ignore subsequent taps until the current flow ends

#### Scenario: Wallet recharge confirmation enters submitting state
- **WHEN** the first valid wallet recharge confirmation tap is accepted
- **THEN** the system SHALL mark the wallet recharge confirmation flow as submitting immediately
- **AND** the system SHALL present the confirmation button as non-repeatable during that state

#### Scenario: Wallet recharge confirmation recovers after terminal outcome
- **WHEN** the wallet recharge flow ends because of success, failure, cancellation, local validation failure, or modal re-entry
- **THEN** the system SHALL clear the submitting state
- **AND** the user SHALL be able to start a new recharge attempt

### Requirement: Package payment confirmation SHALL prevent duplicate submission
The system SHALL prevent repeated taps on the package payment confirmation button from starting more than one package payment submission flow at the same time.

#### Scenario: User taps confirm payment repeatedly during submission
- **WHEN** the user taps the package payment confirmation button multiple times before the current `confirmPay` flow completes
- **THEN** the system SHALL execute only the first submission flow
- **AND** the system SHALL ignore subsequent taps until the current flow ends

#### Scenario: Package payment confirmation enters submitting state
- **WHEN** the first valid package payment confirmation tap is accepted
- **THEN** the system SHALL mark the package payment confirmation flow as submitting immediately
- **AND** the system SHALL present the confirmation button as non-repeatable during that state

#### Scenario: Package payment confirmation recovers after terminal outcome
- **WHEN** the package payment flow ends because of success, failure, cancellation, validation failure, strong recharge prompt completion, or modal re-entry
- **THEN** the system SHALL clear the submitting state
- **AND** the user SHALL be able to start a new payment attempt

### Requirement: Order list immediate payment SHALL prevent duplicate submission
The system SHALL prevent repeated taps on an order list item's immediate payment button from starting more than one payment submission flow for the current order at the same time.

#### Scenario: User taps order list immediate payment repeatedly during submission
- **WHEN** the user taps the immediate payment button multiple times before the current `handleOrderPayment` flow completes
- **THEN** the system SHALL execute only the first submission flow
- **AND** the system SHALL ignore subsequent taps until the current flow ends

#### Scenario: Order list immediate payment enters submitting state
- **WHEN** the first valid order list immediate payment tap is accepted
- **THEN** the system SHALL mark the current order payment flow as submitting immediately
- **AND** the system SHALL present the triggered immediate payment button as non-repeatable during that state

#### Scenario: Order list immediate payment recovers after terminal outcome
- **WHEN** the order list payment flow ends because of success, failure, cancellation, list refresh, or page re-entry
- **THEN** the system SHALL clear the submitting state
- **AND** the user SHALL be able to start a new payment attempt if the order remains payable

### Requirement: Wallet recharge order immediate payment SHALL prevent duplicate submission
The system SHALL prevent repeated taps on a wallet recharge order item's immediate payment button from starting more than one recharge order payment flow for the current recharge order at the same time.

#### Scenario: User taps wallet recharge order immediate payment repeatedly during submission
- **WHEN** the user taps the immediate payment button multiple times before the current `handleRechargePayment` flow completes
- **THEN** the system SHALL execute only the first submission flow
- **AND** the system SHALL ignore subsequent taps until the current flow ends

#### Scenario: Wallet recharge order immediate payment enters submitting state
- **WHEN** the first valid wallet recharge order immediate payment tap is accepted
- **THEN** the system SHALL mark the current recharge order payment flow as submitting immediately
- **AND** the system SHALL present the triggered immediate payment button as non-repeatable during that state

#### Scenario: Wallet recharge order immediate payment recovers after terminal outcome
- **WHEN** the wallet recharge order payment flow ends because of success, failure, cancellation, list refresh, or page re-entry
- **THEN** the system SHALL clear the submitting state
- **AND** the user SHALL be able to start a new payment attempt if the recharge order remains payable

### Requirement: Submit guards SHALL NOT change existing payment business rules
The system SHALL preserve the current recharge validation, recharge order payment, order list payment, order creation, strong recharge decision, wallet payment, WeChat payment, toast, modal, and balance refresh behavior while adding submit guards.

#### Scenario: Existing business validation remains unchanged
- **WHEN** the user submits with an invalid recharge amount or reaches an existing payment business rule branch
- **THEN** the system SHALL keep the current validation and messaging behavior
- **AND** the duplicate submission guard SHALL only affect repeated-trigger protection