Reading FXY balances out of Floxypay Wallet's non-custodial session and the Polygon chain

FXY, the token Floxypay Wallet is built around, is an ERC-20 deployed on Polygon — its contract reads as 0x4ec4…8335 per the token's CoinMarketCap listing and the Polygon token tracker. That single fact splits the integration cleanly in two: roughly half of what a user sees in this wallet is already a public ledger entry, and the other half lives behind a logged-in web session. An integrator who treats it as one opaque app misses the easy half.

The Android build is the giveaway. Its package id, io.floxypay.fxy.twa (per its Google Play listing), ends in .twa — a Trusted Web Activity. So the app is a shell over Floxypay's web wallet rather than a native client. The integration target is the web session and the Polygon chain; the APK is just the window onto them.

Bottom line: the transfer ledger and live balance are reachable today through Polygon with nothing more than the account holder's address and their consent to tie it to them. The fiat on-ramp, MFA-gated views and any wallet-side labels need the web session, captured with the user during onboarding. We would build the chain read as the backbone and layer the session on top of it — the reverse, leading with the session, leaves history reconstruction fragile.

Account data the wallet actually holds

Floxypay Wallet shows the user a small, concrete set of things. Each maps to a clear source and a clear use.

Getting in: the chain, then the session

1. On-chain read of the FXY contract (the backbone)

Because FXY settles on Polygon, the heaviest data domain — full transfer history and live balance — is a public-ledger read against the account holder's address. No app cooperation is needed for the read itself; we still gate it on the user's consent to associate the address with them. This route is durable: contract addresses and ERC-20 event semantics do not shift when a front end is redesigned. Effort is low. We set up a Polygon RPC or indexer endpoint and the decoding during the build.

2. Authorized analysis of the consented web session

Fiat purchases, MFA state and wallet-side labelling are not on chain. We reach them by analysing the traffic of the Floxypay web wallet under the account holder's authorization — the same session the Trusted Web Activity shell opens. Moderate effort; the durability depends on the web front end, which is why we wire a maintenance check for it (see engineering realities). Access here is arranged with the client during onboarding: a consenting account, or a session the user grants.

3. User-consented session capture

Where a partner wants their own end-user to connect a Floxypay Wallet, the consenting user logs in once and the session is captured for the integration. This is the cleanest fit for an aggregator onboarding many users; we build the consent step and the token lifecycle around it.

In plain terms: build route 1 first and treat it as the source of truth for balances and history, then add route 2 only for the fiat and label fields the chain cannot give you. Route 3 is the shape to choose if you are onboarding other people's wallets rather than your own.

The call, concretely

Two reads cover most of what an integrator wants. The first is the on-chain balance and history; the second is the session-side fiat on-ramp list. Constants below are illustrative and confirmed during the build.

# 1) FXY balance + transfer history on Polygon (backbone, no app dependency)
FXY = "0x4ec4...8335"          # FXY ERC-20, Polygon (confirm on build)
addr = user_address            # consented account holder address

balance = eth_call(
    to   = FXY,
    data = selector("balanceOf(address)") + pad(addr)
)                              # -> uint256, divide by 10**decimals

logs = eth_getLogs(
    address  = FXY,
    topics   = [ TRANSFER_SIG, None, pad(addr) ],   # incoming
    fromBlock= deploy_block, toBlock="latest"
)
# repeat with topics[1]=pad(addr) for outgoing; decode (from,to,value)

# 2) Fiat on-ramp orders (web session — chain cannot show these)
GET https://<web-wallet-host>/api/onramp/orders?limit=50
Authorization: Bearer <session_token captured under user consent>

200 -> { "orders":[ {"id","fiat_amount","fiat_ccy",
                      "fxy_amount","status","created_at"} ], "next": "..." }
401 -> refresh via the Web3-auth session flow, then retry once
429 -> honor Retry-After; the relay/on-ramp endpoints rate-limit
      

The error handling matters more than the happy path here. The session token rides a Web3-auth flow, so a 401 means re-establish the auth session, not just replay a refresh token; and the on-ramp endpoint rate-limits, so a backfill of historical orders has to pace itself. Both behaviours are pinned down during the build, not guessed.

What lands at the end of the build

• An OpenAPI/Swagger specification for a normalized Floxypay Wallet interface — one schema covering balance, transfer history and fiat on-ramp orders, regardless of which route fed each field.
• A protocol and auth-flow report: the Web3-auth session, token lifetime and the 401 re-auth path, plus the Polygon contract read and Transfer decoding.
• Runnable source for the key reads in Python and Node.js — the on-chain balance/history reader and the session-side on-ramp client, with retry and rate-limit handling wired in.
• Automated tests, including a recorded on-ramp session fixture and a Polygon log-decode check against known FXY transactions.
• Interface documentation and data-retention guidance scoped to the FIU-IND posture below.

Engineering realities specific to this wallet

Four things about Floxypay specifically that we account for and handle:

• The TWA shell. Because the Android app is a Trusted Web Activity, the integration target is the web wallet behind it, not the APK itself. We capture the session at the web layer during onboarding, which also keeps the build identical across the mobile, web and desktop versions Floxypay ships.
• Gasless sends look different on chain. Floxypay advertises zero-gas transfers, which means some sends are relayed rather than signed directly by the user's address. We model the relay path so a relayed transfer is still attributed to the right user in reconciliation, instead of being read as a third party's transaction.
• Chain reporting is inconsistent in public sources. Some listings describe FXY as Ethereum, others as Polygon; we resolve this against the live contract during the build rather than trusting a secondary source, and pin the chain id, decimals and deploy block into the delivered code.
• Front-end drift on the session route. The on-ramp and session endpoints are web-app internals and can change without notice. We add a re-validation check to the maintenance scope so a front-end change surfaces as a failing test rather than as silently wrong data.

Consent, custody and the India VDA rules

Floxypay is non-custodial with MPC-enabled key infrastructure, and we keep it that way: the integration is read-only, never touches key shares, and never moves funds. Reading needs an address and a consented session — not a private key.

On the regulatory side, Floxypay positions FXY for India, Africa and Bangladesh. India's FIU-IND treats virtual digital asset service providers under the PMLA, and its AML/CFT guidelines for that sector were updated on 8 January 2026 (per FIU-IND), with consent records, customer due diligence and multi-year transaction-record retention as standing expectations. Whether Floxypay itself holds an FIU-IND registration is not publicly disclosed and is not asserted here. We operate to that standard regardless: scoped consent that names exactly which data domains are read, consent expiry and revocation honoured in the session lifecycle, access logged, and only the fields the integration needs pulled — the on-ramp order list, not the user's whole profile, when only cost basis is required. NDAs where the client needs them.

Where integrators take this

• A portfolio app adds FXY support by reading balance and history on chain, no Floxypay cooperation required for the read.
• An accounting tool ingests a user's send/receive ledger plus fiat on-ramp purchases to produce a cost-basis report.
• A treasury dashboard reconciles relayed (gasless) and direct FXY transfers into one statement.
• An aggregator lets end users connect a Floxypay Wallet via a consented session and normalizes it next to other wallets.

What was checked, and against what

This mapping was put together on 16 May 2026 from the app's public surfaces: the Google Play listing for io.floxypay.fxy.twa, Floxypay's own wallet feature page, the FXY token contract on the Polygon token tracker via its CoinMarketCap entry, and the FIU-IND virtual-digital-asset AML/CFT guidance for the India regime. The contract address, chain and key model above each trace to one of those.

Google Play listing · Floxypay wallet feature page · FXY token / contract (CoinMarketCap) · FIU-IND (India VDA AML/CFT)

Floxypay Wallet mapping — OpenBanking Studio integration desk, 2026-05-16.

Comparable wallets an aggregator would see

Same integration bucket — self-custody wallets holding per-address balances and transaction history that a unified interface would normalize alongside Floxypay Wallet. Named for ecosystem context, not ranked.

• Trust Wallet — multi-chain self-custody wallet; per-address balances and transaction history across many networks.
• MetaMask — EVM wallet with Polygon support; the same balanceOf and Transfer-log read pattern applies to any ERC-20 it holds.
• Coinbase Wallet — self-custodial wallet independent of the Coinbase exchange; broad token coverage and on-chain history.
• Exodus — multi-asset desktop and mobile wallet; portfolio balances and a local transaction record.
• Zengo — keyless MPC wallet; comparable key model to Floxypay's MPC infrastructure, with on-chain balances behind it.
• Atomic Wallet — multi-currency wallet holding balances and swap/transfer history per asset.
• SafePal — mobile wallet with on-chain balances and transfers across EVM chains including Polygon.
• Tangem — hardware-backed mobile wallet exposing on-chain balances and transaction history per address.

Screens from the app

Public store screenshots, for interface reference.

Questions integrators ask about Floxypay Wallet

The Android build is a Trusted Web Activity — so where does integration actually happen?

The package id io.floxypay.fxy.twa carries the .twa suffix of a Trusted Web Activity, so the Android app is a thin shell around Floxypay's web wallet. We integrate against that web session and against the Polygon chain directly, not against the APK. The shell only matters for how we capture the session during onboarding.

Can you reconstruct a full FXY transfer history, or only the current balance?

Full history. FXY is an ERC-20 on Polygon, so every send and receive for the account holder's address is a public Transfer log we can read end to end. The live balance comes from balanceOf on the contract. The web session adds what the chain does not carry: fiat on-ramp orders, MFA state, and any human-readable labels the wallet shows.

It is non-custodial with MPC key infrastructure — does that stop you reading the data?

No. Reading balances and transfer history needs the address and a consented read session, not the private key. The MPC key infrastructure protects signing, not visibility. We never touch key shares or move funds; the integration is read-only against on-chain state and the consented session.

Does India's FIU-IND VDA framework change what you can deliver here?

It shapes how we run the engagement, not whether it can be done. Floxypay markets to India, Africa and Bangladesh, and the FIU-IND AML/CFT guidelines for virtual digital asset service providers (updated 8 January 2026, per FIU-IND) expect consent records, data minimization and retention discipline. We build to that posture: scoped consent, logged access, and only the fields the integration needs.

Engagement runs one of two ways, your choice. Source-code delivery starts at $300 — you get runnable API source plus interface documentation, and you pay only after delivery once it works for you. Or use the hosted API and pay per call, nothing upfront. Either way the access, a consenting test account and any compliance paperwork are arranged with you during onboarding, and the build runs in one to two weeks. Start at /contact.html.