chore(runway): cherry-pick fix(ramps): filter activity tab's transfer details for selected account -> cp-7.71.0

[runway-github]

• fix(ramps): filter activity tab's transfer details for selected account -> cp-7.71.0 (fix(ramps): filter activity tab's transfer details for selected account -> cp-7.71.0 #27830)

Description

Activity — on-ramp orders scoped to the selected account

The Activity Orders tab merges legacy fiat orders with V2
RampsController orders. Legacy rows were already limited to the
selected account group via getOrders. V2 orders were not filtered,
so purchase history from other wallets could appear.

This change adds selectRampsOrdersForSelectedAccountGroup, which keeps
only orders whose walletAddress matches any formatted address in the
selected account group (same semantics as legacy, using
areAddressesEqual for EVM vs non-EVM). Hook and modal consumers that
should reflect “current wallet context” now use this selector instead of
the raw controller list.

Transak — preserve user-entered fiat amount on Build Quote (in-app)

After additional verification, opening the KYC/payment webview
called navigateToKycWebview with quote.fiatAmount, and the stack
reset rewrote RampAmountInput params with that value. The quote
total can differ from what the user typed (e.g. fees), so Build Quote
could show 27.37 after the user entered 25, and that value
persisted after closing the sheet or going back.

Change: routeAfterAuthentication(..., amount) already carried the
typed fiat; navigateToAdditionalVerificationCallback now puts the same
amount on both RampAmountInput and RampAdditionalVerification
route params. V2 Additional Verification reads that param and passes
only it into navigateToKycWebview (no quote.fiatAmount for this
purpose).

Out of scope: Order detail screens and stored order payloads are
unchanged. The Transak payment webview URL is unchanged (no
fiatAmount override in widget params); only in-app Build Quote / stack
state matches the user’s input.

Changelog

CHANGELOG entry: Fixed Activity on-ramp (Orders) list showing V2
purchases from wallets other than the selected account group; fixed
Transak unified buy flow so the fiat amount on Build Quote after
additional verification matches the user-entered amount on the amount
screen (in-app stack), without changing Transak’s payment widget totals.

Tests

• selectRampsOrdersForSelectedAccountGroup and ramp hook consumers
  (selector + hook unit tests).
• useTransakRouting: IDPROOF / additional verification navigation with
  user amount set and omitted.
• V2 AdditionalVerification: continue passes route amount into
  navigateToKycWebview.

Related issues

Refs:
TRAM-3361

Manual testing steps

Feature: Activity on-ramp orders and Transak amount (TRAM-3361)

  Scenario: Orders tab shows only selected account group’s V2 on-ramp orders
    Given the user has two wallets (or account groups) with separate on-ramp purchase history
    And unified ramps V2 orders exist for more than one wallet address

    When the user selects account group A and opens Activity → Orders
    Then only on-ramp orders whose destination wallet belongs to account group A are listed

    When the user switches to account group B
    Then the Orders tab lists only orders for account group B

  Scenario: Custom fiat amount survives Transak additional verification on Build Quote
    Given the user is in unified Buy with Transak (native) as provider
    And the user enters a custom fiat amount (e.g. 25) on the amount screen

    When the user continues through flows that require additional verification
    And the user taps Continue on the additional verification screen
    Then Build Quote under the KYC/payment sheet still shows the entered amount (e.g. 25), not only the quote total

    When the user closes the webview or goes back from the flow
    Then the amount screen still shows the same entered amount (e.g. 25)

Screenshots/Recordings

Before

ScreenRecording_03-18-2026.21-26-36_1.MP4

After

Recording.2026-03-23.200201.mp4

Recording.2026-03-23.200613.mp4

Pre-merge author checklist

• I've followed MetaMask Contributor
  Docs and MetaMask Mobile
  Coding
  Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format
  if applicable
• I've applied the right labels on the PR (see labeling
  guidelines).
  Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the
  app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described
  in the ticket it closes and includes the necessary testing evidence such
  as recordings and or screenshots.

---

Note

Medium Risk
Moderate UX/data-scoping change: filters which on-ramp orders appear
based on multichain account selection and adjusts Transak navigation
params, which could hide expected history or affect flow state if
account/address resolution is off.

Overview
Fixes unified ramp UI to scope V2 RampsController orders to the
selected account group, preventing purchases from other wallets from
showing up in Activity-derived surfaces. This introduces
selectRampsOrdersForSelectedAccountGroup (address-matched via
areAddressesEqual) and switches key consumers (useRampsOrders,
useRampsProviders, useRampsButtonClickData,
ProviderSelectionModal) from the unfiltered selector.

Updates the Transak additional-verification flow to preserve the
user-entered fiat amount through stack resets: useTransakRouting now
carries amount into RampAdditionalVerification params, and
AdditionalVerification uses that param (not quote.fiatAmount) when
opening the KYC webview. Selector and routing behavior are covered with
expanded unit tests.

^{Written by Cursor
Bugbot for commit
39d5861. This will update automatically
on new commits. Configure
here.}

[4661cdb](https://github.com/MetaMask/metamask-mobile/commit/4661cdba2d91fcd672861ab330f91f134451c111)

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeRamps
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 92%

click to see 🤖 AI reasoning details

E2E Test Selection:
All 11 changed files are exclusively within the Ramps (fiat on-ramp/off-ramp) feature area:

1. New selector selectRampsOrdersForSelectedAccountGroup (app/selectors/rampsController/index.ts): Adds account-group-scoped filtering of ramp orders, replacing the unfiltered selectRampsOrders in UI hooks. This is a behavioral change — orders are now filtered to only show those belonging to the selected account group (multi-SRP/multi-account support).

2. Hook updates (useRampsOrders.ts, useRampsProviders.ts, useRampsButtonClickData.ts, ProviderSelectionModal.tsx): All updated to use the new scoped selector. This affects which orders are displayed in the ramps UI and which provider is considered "preferred" based on past orders.

3. KYC flow fix (AdditionalVerification.tsx + useTransakRouting.ts): Bug fix where the user-entered fiat amount is now correctly passed through to the KYC webview instead of using quote.fiatAmount. This affects the Transak native flow.

4. Test files: Unit tests updated to reflect the behavioral changes.

Impact assessment:

• Changes are scoped entirely to the Ramps feature — no shared components (TabBar, navigation, modals) are modified
• The order filtering change could affect the buy/sell flow if orders are incorrectly filtered
• The KYC amount fix affects the Transak native flow specifically
• SmokeRamps is the directly relevant tag covering fiat on-ramp/off-ramp features

No dependent tags needed: The tag descriptions for SmokeRamps mention integration with SmokeWalletPlatform for wallet actions entry point, but the changes here are internal to the ramps flow (not the entry point from wallet home). No confirmations flow changes are present.

Performance Test Selection:
The changes are limited to the Ramps feature: a new Redux selector for filtering orders by account group, hook updates to use the new selector, and a KYC flow amount bug fix. None of these changes affect UI rendering performance, list rendering, animations, app startup, or other performance-sensitive areas. The selector uses createDeepEqualSelector which is a performance optimization, not a regression. No performance tests are warranted.

View GitHub Actions results

[github-actions]

✅ E2E Fixture Validation — Schema is up to date
17 value mismatches detected (expected — fixture represents an existing user).
View details

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[chloeYue]

LGTM