Fiat and notifications
Buy and sell
Section titled “Buy and sell”The job: a “Buy” button that ends with crypto in the user’s address, and a “Sell” button that ends with money in their bank.
In the kit: FiatProtocol in core defines the shape: quoteBuy, buy, quoteSell,
sell, getTransactionDetail, getSupportedCryptoAssets. No provider module ships yet;
write one against that interface, or call the provider’s widget directly.
You bring: an on-ramp provider. It runs KYC and payments; you pass the address and the asset, and receive webhooks about the order.
| Provider | Docs |
|---|---|
| MoonPay | dev.moonpay.com |
| Transak | transak.com |
| Ramp Network | docs.ramp.network |
| Banxa | banxa.com |
Things to settle with the provider:
- Countries and assets. Coverage differs per country, payment method and network.
- Who you are to them. Most providers need a signed agreement and a business review before production keys.
- Fees. The user sees the provider’s fee plus the network fee; some let you add your own.
Notifications
Section titled “Notifications”The job: “You received 50 USDT” while the app is closed.
In the kit: nothing yet.
You bring:
-
An address-watching service that calls your server when something happens to an address:
Chain Examples EVM, Solana and other chains QuickNode serves QuickNode Streams EVM Alchemy Notify (webhooks) Solana Helius webhooks Any Your own indexer polling the history sources -
A server that receives those events, decides what is worth a notification, and maps the address to a device token.
-
Push delivery: Expo push, or Firebase Cloud Messaging and APNs directly.
Rules:
- Only addresses leave the device, never keys. Tell users their addresses are linked to a device on your server, and let them turn it off.
- Filter spam before you push. A notification about a scam airdrop is phishing you delivered yourself.