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

After

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.