feat(ramps-controller): prefer previously used provider over API ranking for asset selection - #10536
Merged
Merged
Conversation
…ing for asset selection
wenfix
previously approved these changes
Sep 28, 2026
# Conflicts: # packages/ramps-controller/CHANGELOG.md
Merged
pull Bot
pushed a commit
to Reality2byte/core
that referenced
this pull request
Sep 29, 2026
Minor release of `@metamask/ramps-controller` (26.0.1 to 26.1.0). - Prefer a provider the user has previously completed an order with (most recent first) over API ranking order when `setSelectedProviderForAsset` switches providers ([MetaMask#10536](MetaMask#10536)) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Version and changelog-only release with a minor dependency bump; no runtime logic changes in this diff. > > **Overview** > This PR is a **release cut**, not new feature code in the diff: it bumps the root monorepo from `1299.0.0` to **`1300.0.0`**, publishes **`@metamask/ramps-controller` `26.1.0`** (from `26.0.1`), and wires dependents to that version. > > The **`26.1.0`** changelog records the shipped behavior from [MetaMask#10536](MetaMask#10536): when **`setSelectedProviderForAsset`** switches providers, selection **prefers providers the user has completed an order with** (most recent first) instead of raw API ranking. **`@metamask/transaction-pay-controller`** updates its dependency to `^26.1.0` and notes the bump in its changelog; **`yarn.lock`** is refreshed accordingly. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit fbef638. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Darius Costolas <10818970+meltingice1337@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
10 tasks done
javiergarciavera
pushed a commit
to MetaMask/metamask-mobile
that referenced
this pull request
Oct 1, 2026
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.
In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
<!--
mms-check directive vocabulary — read by
.github/scripts/shared/pr-template-checks.ts
at module load to build the validation plan. Directives are invisible in
rendered
markdown and must NOT be removed or edited without updating the
validator registry.
type=text Section must contain non-placeholder prose.
type=changelog Section must have a valid CHANGELOG entry: line.
type=issue-link Section must have a Fixes:/Closes:/Refs: line with a
value.
type=manual-testing Section must have real testing steps or an explicit
N/A.
type=screenshot Section must have evidence (image/URL) or an explicit
N/A.
type=checklist Section must have all checkboxes consciously checked.
required=true|false Whether a missing/invalid section runs the validator
at all.
blocking=true|false Whether a failure of this check fails the CI
workflow.
Default: false — failures are shown as warnings in the sticky
comment but do not block the PR.
Sections without a directive are checked for structural presence only.
-->
## **Description**
<!-- mms-check: type=text required=true -->
<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->
Bumps `@metamask/ramps-controller` from `^26.0.1` to `^26.1.0` to pick
up [MetaMask/core#10536](MetaMask/core#10536).
**Reason for the change**
On 8.13.0, when a user changes token in Buy and the currently selected
provider does not support the new token,
`RampsController.setSelectedProviderForAsset` switches to the first
compatible provider in API ranking order and ignores order history.
Returning users whose previous orders were all with Transak land on
Coinbase instead (and would land on Crossmint once the Crossmint boost
ships), which pushes them into a new KYC flow with a provider they have
never used. Mobile hits this path from BuildQuote and from MM Pay
(`useEnsureCompatibleProvider`).
**Solution**
In 26.1.0, when a switch is needed, the controller picks the provider of
the most recent completed order that supports the token (from its own
order history), and only falls back to API ranking order when none do.
Provider ids match with or without the `/providers/` prefix,
case-insensitively. The method signature is unchanged, so mobile needs
no code changes beyond the version bump.
**What does not change**
- Users with no order history: ranking, including boosts, still decides.
- A provider the user picked manually is still kept when it supports the
new token.
- Only orders placed in the current unified buy flow count. Orders from
the old aggregator and deposit flows live only in mobile Redux and are
not considered.
**Out of scope (possible follow-ups)**
- The BuildQuote fallback that still picks by ranking when the provider
lists the token but returns no payment methods.
- The first-load selection race between `determinePreferredProvider`
(latest order only, not token-aware) and BuildQuote's own pick.
## **Changelog**
<!-- mms-check: type=changelog required=true blocking=true -->
<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`
If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`
(This helps the Release Engineer do their job more quickly and
accurately)
-->
CHANGELOG entry: Changed Buy to prefer a provider you have already
completed an order with when you switch to a token your current provider
does not support
## **Related issues**
<!-- mms-check: type=issue-link required=true -->
Fixes: https://consensyssoftware.atlassian.net/browse/TRAM-4090
## **Manual testing steps**
<!-- mms-check: type=manual-testing required=true -->
```gherkin
Feature: Prefer a previously used provider when the token change forces a provider switch
Scenario: returning user switches to a token their current provider does not support
Given the app points to the staging ramps environment
And the user has completed a Coinbase order in the Buy flow
And the user has manually selected Crossmint on a token only Crossmint supports (e.g. TRUMP)
When user switches the token to ETH
Then Coinbase is selected as the provider
# Without this change, the top-ranked ETH provider (Topper on staging) is selected
Scenario: user without order history switches to a token their current provider does not support
Given a wallet with no completed ramps orders
And the user is on Buy with a provider selected
When user switches to a token that provider does not support
Then the top-ranked provider that supports the token is selected, same as before
Scenario: user keeps a manually selected provider that supports the new token
Given the user has manually selected a provider on Buy
When user switches to a token that provider supports
Then the manually selected provider stays selected
```
## **Screenshots/Recordings**
<!-- mms-check: type=screenshot required=true -->
<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->
### **Before**
N/A
<!-- TODO: recording of switching Crossmint (TRUMP) to ETH after a
completed Coinbase order, landing on the top-ranked provider (Topper on
staging) -->
### **After**
N/A
<!-- TODO: recording of the same flow landing on Coinbase -->
## **Pre-merge author checklist**
<!-- mms-check: type=checklist required=true -->
<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.
Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->
- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.
#### Performance checks (if applicable)
- [x] I've tested on Android
- Ideally on a mid-range device; emulator is acceptable
- [x] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [x] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example
For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).
## **Pre-merge reviewer checklist**
<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->
- [x] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [x] 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.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Changes Buy/MM Pay provider selection for returning users when tokens
force a switch; limited to dependency behavior with no mobile code
changes, but affects fiat on-ramp UX and provider/KYC flows.
>
> **Overview**
> Bumps **`@metamask/ramps-controller`** from **26.0.1** to **26.1.0**
(`package.json` / `yarn.lock` only—no mobile source changes).
>
> That release changes **`setSelectedProviderForAsset`**: when Buy must
switch providers because the selected one does not support the new
token, the controller now picks the provider from the user’s **most
recent completed order** that supports the token, instead of the first
API-ranked provider. Manual selection and users with no order history
behave as before; API ranking is still the fallback.
>
> Mobile already calls this from **BuildQuote** (token changes) and
**`useEnsureCompatibleProvider`** (MM Pay), so the bump delivers the fix
without app code changes.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
8c6b581. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Co-authored-by: Darius Costolas <10818970+meltingice1337@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation
When the user picks an asset that their currently selected provider does not serve,
setSelectedProviderForAssetswitches to another provider. Today it always picks the first compatible provider inproviders.data, i.e. whatever the API ranks highest. That can move a user away from a provider they have already bought through (and completed KYC with) to one they have never used, forcing them through onboarding again for no reason.This PR changes how
setSelectedProviderForAssetchooses the replacement provider. Among the providers that serve the asset (excluding the currently selected one), it now picks:providers.data(API ranking order), which is the existing behavior.The order history comes from the existing private
#getPreferredProviderIdsFromOrdershelper (completed orders in state, sorted bycreatedAtdescending, deduplicated), which is already used for headless provider resolution. Provider IDs are compared throughnormalizeHeadlessProviderIdon both sides so that IDs stored on orders match the IDs inproviders.dataregardless of format. All existing no-op conditions (providers not loaded, current provider already serves the asset, no compatible provider) are unchanged.The JSDoc for
setSelectedProviderForAsset(and the generated messenger action type) has been updated to describe the new selection order.References
Checklist
Note
Medium Risk
Changes automatic provider selection during buy flows, which affects checkout routing and KYC reuse, but the logic is scoped to compatibility switching with existing no-op guards.
Overview
When the selected ramp provider does not support the chosen asset,
setSelectedProviderForAssetno longer always switches to the first compatible provider in API ranking order.Among compatible alternatives, it now picks the provider from the user’s most recent completed order (reusing existing
#getPreferredProviderIdsFromOrdersandnormalizeHeadlessProviderIdfor ID matching). If none of those providers serve the asset, behavior is unchanged: it falls back to the first compatible entry inproviders.data.JSDoc, messenger action types, changelog, and unit tests cover the new preference order, skipping non-serving prior providers, and API-order fallback.
Reviewed by Cursor Bugbot for commit 735f51a. Bugbot is set up for automated code reviews on this repo. Configure here.