feat(ramp): add unified order processor behind V2 feature flag

[amitabh94]

Summary

Add a unified order processor that calls RampsController.getOrder (V2 API endpoint) instead of separate SDK calls for aggregator and deposit order polling. Feature-flagged behind the unified buy V2 flag.

Depends on: Core PR to add getOrder to RampsService (branch: feat/ramps-unified-getorder in MetaMask/core)

Changes

• New file: unifiedOrderProcessor.ts -- Single processor that calls RampsController.getOrder for all provider types

  • Includes exponential backoff on errors (ported from aggregator processor)
  • Includes pollingSecondsMinimum support (ported from aggregator processor)
  • Extracts provider code from both deposit-style (/providers/transak-native/orders/abc) and aggregator-style order IDs
  • Maps unified RampsOrder response to FiatOrder for Redux

• Updated: orderProcessor/index.ts -- Router checks options.useUnifiedProcessor before delegating to SDK-specific processors

• Updated: index.tsx (FiatOrders) -- Passes useUnifiedProcessor: isUnifiedV2Enabled into processor options for both pending and force-update polling loops

Feature Flag Gating

When V2 is enabled (useRampsUnifiedV2Enabled):

• Both AGGREGATOR and DEPOSIT orders use processUnifiedOrder
• Single API call to GET /v2/providers/:code/orders/:id
• No SDK dependencies for order polling

When V2 is disabled:

• Existing processAggregatorOrder (@consensys/on-ramp-sdk) unchanged
• Existing processDepositOrder (@consensys/native-ramps-sdk) unchanged

Test plan

• Verify V2 flag off: aggregator and deposit orders poll via existing SDK processors
• Verify V2 flag on: both order types poll via unified processor (V2 API)
• Verify exponential backoff on repeated errors
• Verify pollingSecondsMinimum is respected
• Verify deposit order ID parsing (/providers/transak-native/orders/...)
• Verify aggregator order provider extraction from order data
• Verify order status mapping (COMPLETED, FAILED, CANCELLED, CREATED, PENDING, UNKNOWN)

Made with Cursor

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

🔍 Smart E2E Test Selection

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

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes are focused on the Ramps (buy/sell crypto) functionality:

1. app/components/UI/Ramp/index.tsx: Adds the useRampsUnifiedV2Enabled hook and passes a new useUnifiedProcessor option to the order processing function.

2. app/components/UI/Ramp/orderProcessor/index.ts: Conditionally routes order processing to the new unified processor when the V2 flag is enabled for AGGREGATOR and DEPOSIT providers.

3. app/components/UI/Ramp/orderProcessor/unifiedOrderProcessor.ts (NEW): Implements a unified V2 order processor that uses RampsController.getOrder API, with exponential backoff, status mapping, and provider/order code extraction.

These changes are:

• Scoped to Ramps: Only affects fiat on-ramp/off-ramp order processing
• Feature-flagged: Controlled by useRampsUnifiedV2Enabled hook (build flag or remote feature flag)
• Backend processing: Affects order status polling and updates, not UI rendering

SmokeRamps is the appropriate tag as it covers "fiat on-ramp (buy crypto) and off-ramp (sell crypto) features" including order processing flows. The existing E2E tests in tests/smoke/ramps/ (onramp-unified-buy.spec.ts, offramp-token-amount.spec.ts) will validate these changes.

No dependent tags are needed as per the SmokeRamps description - it only mentions integration with SmokeWalletPlatform for wallet actions entry point, but these changes don't affect the entry point, only the order processing backend.

Performance Test Selection:
These changes affect order processing logic (polling, status updates, API calls) but are backend/data processing focused rather than UI rendering focused. The unified order processor handles order status polling with exponential backoff, which doesn't impact UI rendering performance, account list rendering, app launch, or other performance-critical user flows. The changes are feature-flagged and only affect how fiat orders are fetched and updated in the background, not how they are displayed.

View GitHub Actions results

[sonarqubecloud]

Quality Gate failed

Failed conditions
3.8% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud