Thanks for the follow-up. Here is the redacted evidence we can share now. We are not generating or modifying Mercuryo signatures / widget secrets client-side.
1) Client ID + network
- Client ID:
BMhswBezycVnJWn0uApY3qh4iJcxUVIjQt4ZiQtIMHbDjZXsoXQKOVYsCEN7VXwgFSrwkHc_m5IaDKdZMXTtiIk
- Web3Auth network env:
NEXT_PUBLIC_WEB3AUTH_NETWORK=devnet → SDK resolves to WEB3AUTH_NETWORK.SAPPHIRE_DEVNET
- Dashboard check pending on our side for whether Wallet Services / funding toggles for this Client ID are intended for Devnet vs Mainnet.
2) App origin + SDK versions
- App origin (develop):
https://… (paste exact origin you tested — e.g. cards / frontend develop host)
Local: http://localhost:… if reproduced there.
- Packages (installed):
@web3auth/modal@11.3.0@web3auth/ws-embed@6.1.0 (transitive via modal ^6.1.0)@web3auth/single-factor-auth@9.5.0 (used for Telegram only; Google/email funding path uses modal AUTH)
3) showFunding vs showCheckout
Public docs emphasize showCheckout. In our stack the AUTH connector’s Wallet Services embed exposes both:
wsEmbed.showFunding(...)wsEmbed.showCheckout(...)
We call showFunding on the live AUTH wsEmbed after modal Google/email login (embed.isLoggedIn === true).
@web3auth/ws-embed@6.1.0 types include showFunding and showCheckout.
If showFunding is deprecated / wrong for Sapphire Devnet, please confirm we should switch to showCheckout with the same checkoutParams.
4) Minimal init + checkout invocation (secrets redacted)
Init (simplified):
import { WEB3AUTH_NETWORK, WALLET_CONNECTORS } from '@web3auth/modal';
const web3AuthOptions = {
clientId: '<CLIENT_ID>',
web3AuthNetwork: WEB3AUTH_NETWORK.SAPPHIRE_DEVNET, // from env=devnet
chains: [/* Ethereum 0x1, BSC 0x38 */],
defaultChainId: '0x1',
walletServicesConfig: {
loginMode: 'plugin',
whiteLabel: { showWidgetButton: false, hideTopup: false },
},
// AA config enabled outside Telegram Mini App
};
// User logs in:
await web3Auth.connectTo(WALLET_CONNECTORS.AUTH, {
authConnection: 'google', // or email passwordless + loginHint
});
Checkout open (exact shape we use):
// AUTH connector → wsEmbed
const embed = web3Auth
.getConnector('auth', 'eip155')
?.wsEmbed;
await embed.showFunding({
show: true,
checkoutParams: {
show: true,
tokenList: ['USDC', 'USDT', 'ETH'],
// no receiveWalletAddress
},
});
We previously experimented with receiveWalletAddress; it is not used in the failing runs below. Destination address in provider URLs matches the logged-in account EVM address.
5) Provider failures (same checkout session / same day)
Country intended: Ukraine. Fiat: USD. Assets tried: USDT / USDC / ETH, network often ethereum in provider UI.
| Provider |
Symptom |
| Mercuryo |
UI: “Invalid or missing request signature”; POST /v1.6/widget/buy → 403 / 403029 |
| MoonPay |
Does not load / connection fails |
| Transak |
“Something went wrong” |
| Topper |
“Unavailable in my country” even after changing country in UI |
6) Mercuryo example (no secrets)
We understand address + merchant_transaction_id alone don’t prove signature validity; sharing for correlation only:
- widget_id:
e5bf3e67-52a8-4ebc-9648-914e01909146
- address:
0x38618FFb762C2B7B692fAF76f749B1128dE865e9 (matches our account)
- merchant_transaction_id:
2c43a4f0-01e6-40a2-afb7-2af9f3695d89
- timestamp:
2026-09-22 ~12:27–12:28 UTC+3 (Europe/Kyiv)
- Host: production
https://exchange.mercuryo.io/... (while our Embedded Wallets project is on Sapphire Devnet)
Question for your team: is it expected that Devnet Wallet Services funding opens production Mercuryo (exchange.mercuryo.io) with production widget_id, and could Devnet↔Mainnet / credential mismatch present exactly as 403029?
7) HAR / more merchant_transaction_ids
We will attach redacted HARs (one attempt per provider: URL, status, response body, timestamp+TZ, country, browser) in a follow-up — stripping cookies, Authorization, login JWTs, and any secrets.
We can also mint a fresh merchant_transaction_id + timestamp in that reply.
8) What we need from you
- Confirm whether Sapphire Devnet Wallet Services on-ramp is supported for this Client ID / plan.
- Confirm whether we should call
showCheckout instead of showFunding.
- Correlate Mercuryo 403029 for widget
e5bf3e67-… + tx 2c43a4f0-… against your checkout-session signing.
- Any known outage / geo restrictions for MoonPay / Transak / Topper for UA on this project.
Happy to provide HARs and another failing merchant_transaction_id as soon as you confirm the preferred upload path.