How to build a stablecoin app

For a first stablecoin payments app on Tempo, start with a TypeScript frontend and backend, a Tempo-compatible wallet, Viem for blockchain operations, and a database for payment records. Add Wagmi for a wallet-connected React interface and providers for fiat funding or withdrawals. This guide maps the stack and the hold, send, and receive flow; start implementing with the Tempo quickstart.

A useful first version lets a user create or connect an account, receive a supported stablecoin, see a balance, send a payment, and inspect its status. Build that complete flow before adding more assets, networks, or financial products.

This is an application architecture guide. If you are still evaluating the settlement network, read Choosing a blockchain for stablecoin payments.

A practical stablecoin app stack

Layer	Starting point on Tempo	Your application owns
User interface	TypeScript; React with Wagmi for wallet interactions	Balance display, recipient entry, payment review, and status
Wallet and signing	A Tempo-compatible embedded wallet or customer-connected wallet	Custody choice, user authorization, recovery, and access controls
Network and asset	Tempo and a supported TIP-20 stablecoin	The allowed network and token contracts
Blockchain operations	Viem's Tempo extensions and an RPC connection	Transaction construction, submission, and delivery verification
Payment records	A backend service and database, such as PostgreSQL	Payment IDs, ledger entries, idempotency, and exceptions
History and reconciliation	Tempo API or an indexing provider	Matching delivered transfers to users, invoices, and accounting records
Funding and withdrawals	Providers supporting your selected asset and route	Onboarding, supported markets, payout status, and customer support

The TypeScript SDK guide explains viem/tempo for onchain reads and transactions, Wagmi for wallet-connected React applications, and the Tempo API client for indexed data and hosted services. Use the SDK setup for the wallet model you choose.

Keep server signing keys and secret API credentials out of browser bundles. A browser wallet should request user authorization; a server signer requires its own protected key-management and approval design.

Choose the wallet and stablecoin first

Decide who controls the funds and how a customer authorizes a payment. An embedded wallet can make account creation part of your app. A connected wallet lets a customer use an existing account. The choice affects custody responsibilities, recovery, and the support experience.

Use the embedded wallet guide to evaluate current integrations and their exact feature support. If you use passkeys, design recovery before launch: losing every copy of the signing key can mean losing access to the account. Check account creation for mainnet availability and limitations of each account model.

Choose an existing supported stablecoin for the initial payment flow. Identify it by network and contract address, and review issuer terms, redemption, liquidity, and provider support. The current stablecoin directory is the starting point. A payment app does not need to issue its own stablecoin to send and receive one.

Build hold, receive, and send

Hold and display a balance

Create or connect the wallet, confirm the network, and read the selected token balance. Keep token quantities precise with integer base units; TIP-20 uses six decimals. Format values for display without using floating-point arithmetic for payment amounts. See the stablecoin developer guide.

The displayed wallet balance and your internal ledger answer different questions. The wallet shows the tokens held at an address. Your ledger records which user or business obligation a payment belongs to, including pending payments, fees, and exceptions.

Receive and credit a payment

Show the supported network, stablecoin, and receiving address together. Create a payment record with the expected asset, amount, recipient, and an opaque reference. Never rely on a token symbol or a customer-supplied transaction hash alone.

Use the receive-payment guide to verify the actual transfer. Check the network, token contract, intended recipient, delivered amount, and transaction status before crediting the user. Receive policies can hold or redirect funds, so successful transaction execution alone is insufficient.

Save the network, transaction hash, and transfer log index as the unique event key. Apply the ledger update and save that key atomically so replayed events cannot credit the payment twice.

Send and confirm delivery

Validate the recipient and amount, show a payment review screen, and obtain the required authorization. Submit the transfer with the configured wallet or signer, then retain the transaction hash and verify delivery. The send-payment guide includes complete examples for Viem, Wagmi, the CLI, and Python.

If submission times out, inspect the existing transaction hash before creating another payment. Keep pending, failed, delivered, and held-payment states distinct. A refund is a separate transfer with its own authorization and records.

Pay fees without a separate gas token

Tempo has no native gas token. Standard stablecoin transfers have sub-cent network fees paid in supported USD-denominated stablecoins. Fees vary, and fee-token and liquidity requirements apply. See network fees for estimation and eligibility.

Your application can sponsor network fees so a customer does not need to fund fees separately. Configure production access, spending limits, and abuse controls for the sponsorship service. Sponsorship covers the network fee; the sender still needs the payment amount. Selecting a fee token also does not convert the asset being sent.

Add funding and withdrawals

A wallet-to-wallet prototype can begin with testnet funds. A production app needs a supported route for customers to acquire the asset and, where required, withdraw it.

Choose providers by the countries, currencies, bank rails, custody model, assets, and transaction sizes you need. Verify onboarding, access, fees, limits, and operational support before offering a route to users. Start with the funding and payout guide and Tempo ecosystem.

Keep onchain settlement and bank delivery separate in the UI. A confirmed stablecoin transfer does not prove that a recipient's bank account has been credited. For cross-network funding, review Tempo Routes, including its current beta access and supported combinations.

Connect payments to your ledger

Use 32-byte payment memos for short, opaque references. Memos on the public network are public. Keep personal information, invoice contents, and other sensitive data in your own systems.

An indexed data service can supply transfer records, but your backend must match them to application records. Store ingestion checkpoints, recover missed activity, process repeated events safely, and surface unmatched or partial payments. The reconciliation guide covers these responsibilities and the available data tools.

Validate one complete flow before expanding

1. Build on testnet. Use the quickstart with accounts you control. Keep testnet and mainnet configuration separate.
2. Verify the payment lifecycle. Test balances, delivery, duplicate events, insufficient funds, incorrect assets, held receipts, failed submissions, and refunds.
3. Confirm production dependencies. Verify asset and provider availability, custody and recovery, funding, liquidity, fee sponsorship, and monitoring.
4. Define operating controls. Map onboarding, screening, transaction monitoring, recordkeeping, security, and support to the product and jurisdictions. Token transfer policies support issuer controls; they do not complete the application's regulatory obligations.
5. Pilot the complete route. Measure funding, onchain settlement, conversion, and withdrawal separately, including their costs and failure cases.

For merchant invoicing, use the stablecoin acceptance guide. For a broader production evaluation, use the enterprise infrastructure guide. To implement the first transfer, open the Tempo quickstart.

Frequently asked questions

What tech stack should I use to build a stablecoin app?

A practical Tempo starting point is TypeScript, a Tempo-compatible wallet, Viem for onchain operations, Wagmi for a wallet-connected React interface, and a backend database for payment records. Add indexed data for history and reconciliation, and providers for any fiat funding or withdrawals. The exact stack depends on custody, assets, markets, and payment flows.

How do I build an app that holds, sends, and receives stablecoins?

Create or connect a wallet, select a supported network and token contract, read balances, authorize outgoing payments, and verify incoming transfers before crediting users. Store payment records in your backend, handle duplicate events, and reconcile delivered transfers to the ledger. Test the full lifecycle before production.

Do I need a custom smart contract or my own stablecoin?

Basic transfers can use an existing supported stablecoin through the SDK without deploying a custom payment contract. Custom contracts may be useful for additional payment logic. Issuing a stablecoin introduces separate issuer, reserve, redemption, and regulatory responsibilities.

Does a successful transaction mean the customer received the payment?

Check the delivered transfer as well as transaction execution. Verify the network, token contract, recipient, and amount in the transfer events; a receive policy may hold or redirect funds. For a fiat payout, also obtain the provider's bank-delivery status.