镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Log joinable order ids for Paybis sells and Revolut buys - #6226

Open
j0ntz wants to merge 3 commits into
developfrom
jon/conversion-orderid-campaigns
Open

j0ntz wants to merge 3 commits into
developfrom
jon/conversion-orderid-campaigns

Conversation

@j0ntz

@j0ntz j0ntz commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

Description

Asana task

Fixes two ramp conversion events whose ids could not be joined to the partner reports the reports server stores ({appId}_{pluginId}:{orderId}), so /v1/checkTxs missed them.

  • Paybis sell: the payment-details handler destructured pluginId from PAYBIS_TO_EDGE_CURRENCY_MAP, shadowing the ramp's own pluginId. Sell_Success then logged the wallet's chain (bitcoin, litecoin, ethereum, ...) as fiatProviderId, about 540 events in 30 days. The chain id is now currencyPluginId, so the event logs paybis.
  • Revolut buy: partnerRedirectUrl was encoded before fetchRevolutRedirectUrl encoded it again. The doubly encoded return URL never reopened the app, so no Buy_Success was logged for Revolut even though reports has Revolut orders. The URL is now passed plain. The order id the GUI mints (makeUuid) is the id Revolut reports under (rawTx.id), so no id change is needed.

Rango swaps now log their request id through EdgeApp/edge-exchange-plugins#498; the reports-side lookup for Paybis request ids, Banxa, Maya and THORChain 0x ids lands in EdgeApp/edge-reports-server#235.

Not fixable in the GUI (Simplex): all 16 Simplex Buy_Success events in the last 90 days log orderId: "unknown". The JWT widget flow lets Simplex mint the order_id, the return deep link does not carry it, and the reports row (keyed on order_id) holds nothing the GUI knows. It needs Simplex to append order_id to the return URL, or a move to the Wallet API flow where the partner supplies the id.

On an iOS simulator, a Revolut buy (region DE, 60 EUR to ETH) listed the Revolut quote; tapping it ran approveQuote with the single-encoded return URL and opened the Revolut checkout. The checkout requires a Revolut account sign-in, so the return deep link past it is covered by fetchRevolut.test.ts, which asserts the return URL is encoded exactly once.

The Paybis sell change is a rename covered by tsc. The test account holds 0.065 SOL, under the 0.1671 SOL sell minimum, so the simulator run used a local, uncommitted bypass of the sell balance checks. With it, a 0.3 SOL sell (California, USD) got a Paybis card quote, and tapping it opened the Paybis widget's review screen. Continuing led to Paybis KYC, which asks for a tax residence and home address. The payment-details handler this PR changes runs only after that step, so a completed sell with fiatProviderId: paybis still needs a KYC'd Paybis account and at least 0.3 SOL.

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

  • Yes
  • No

Dependencies

none

Requirements

If you have made any visual changes to the GUI. Make sure you have:

  • Tested on iOS device
  • Tested on Android device
  • Tested on small-screen device (iPod Touch)
  • Tested on large-screen device (tablet)

Note

Medium Risk
Targeted fixes to fiat ramp deep linking and conversion logging; wrong ids affect reports reconciliation but do not change funds movement or auth.

Overview
Fixes two ramp flows where conversion analytics could not be matched to partner order data ({appId}_{pluginId}:{orderId}), so /v1/checkTxs skipped them.

Paybis sell: In the payment-details path, destructuring pluginId from PAYBIS_TO_EDGE_CURRENCY_MAP shadowed the ramp’s own pluginId (paybis). Sell_Success then logged the wallet chain (e.g. bitcoin, ethereum) as fiatProviderId. The map field is renamed to currencyPluginId so events consistently log paybis.

Revolut buy: The success return URL was encodeURIComponent’d before fetchRevolutRedirectUrl, which encodes partnerRedirectUrl again. Double encoding broke the post-checkout deep link, so the app often never received success and Buy_Success was missing. GUI and ramp Revolut providers now pass the plain return URL; fetchRevolut.test.ts asserts it is encoded exactly once. Docs in fetchRevolut.ts clarify that callers should pass an unencoded URL.

CHANGELOG adds both fixes. ESLint no longer exempts the legacy GUI revolutProvider.ts from lint (unchanged behavior in that file mirrors the URL fix).

Reviewed by Cursor Bugbot for commit 7b5cd64. Bugbot is set up for automated code reviews on this repo. Configure here.

Test evidence

7b5cd64
Stop double-encoding the Revolut return URL
2026-09-29
🪓 local uncommitted bypass of the sell balance checks in RampCreateScene, reverted before push

9. revolut buy quote

10. revolut checkout signin wall

11. sell min amount wall

12. 🪓 paybis sell quote

13. 🪓 paybis sell widget

14. 🪓 paybis kyc address wall

The sell path destructured `pluginId` from PAYBIS_TO_EDGE_CURRENCY_MAP,
shadowing the plugin's own id. Sell_Success then reported the wallet's
chain (bitcoin, litecoin, ...) as fiatProviderId, and the saved fiat
action named that chain as its provider, so no Paybis sell could join to
its partner report.
fetchRevolutRedirectUrl already encodes partnerRedirectUrl through
URLSearchParams, so the extra encodeURIComponent reached Revolut as a
literal https%3A%2F%2F... string. Revolut appended `?orderId=` to it and
redirected there, which never resolves back to the app: the buy success
deep link, its Buy_Success event and completion modal never ran, and no
Revolut buy joined its partner report.
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant