
Payments / Onramp·Multi-chain · EVM · Solana
Circle
Native USDC issuer with CCTP for cross-chain transfers, Programmable Wallets (developer- and user-controlled MPC wallets), and USDCKit for stablecoin payment orchestration.
- 01USDC payments
- 02cross-chain USDC via CCTP
- 03MPC wallet-as-a-service
- 04stablecoin payouts and remittance
- 05B2B treasury and merchant flows
- pnpm add @circle-fin/developer-controlled-wallets
- pnpm add @circle-fin/user-controlled-wallets
- pnpm add @circle-fin/usdckit
| Variable | Scope | Description |
|---|---|---|
| CIRCLE_API_KEY | Server | Circle Web3 Services API key from the Circle developer console. |
| CIRCLE_ENTITY_SECRET | Server | 32-byte hex entity secret used to sign developer-controlled wallet operations. Must be registered once with Circle. |
Use Circle for USDC, Programmable Wallets, and CCTP. Initialize the server SDK with `initiateDeveloperControlledWalletsClient({ apiKey: process.env.CIRCLE_API_KEY, entitySecret: process.env.CIRCLE_ENTITY_SECRET })` and call `client.createWallets`, `client.createTransaction` for transfers. For cross-chain USDC, burn on the source chain via CCTP, fetch the attestation from Circle's iris-api, then mint on the destination chain. For higher-level payment flows use `@circle-fin/usdckit` (`createUSDCClient`) which abstracts gas, routing, and CCTP under one API. Never expose `CIRCLE_API_KEY` or `CIRCLE_ENTITY_SECRET` to the client.
- ⚑CCTP attestations have meaningful latency — typically ~13-19 minutes on Ethereum mainnet (hard finality). UI must show a pending state and survive page reloads; do not block the user thread.
- ⚑The entity secret is registered once and CANNOT be rotated without contacting Circle support — store it in a KMS/secret manager, never in source or .env committed files.
- ⚑CCTP V2 (fast transfers) and V1 use different domain IDs and contract addresses per chain — pick one version end-to-end and pin domain IDs from Circle's official docs.
- ⚑Sandbox vs production use entirely separate API keys and entity secrets; sandbox USDC is non-redeemable test tokens.
- ⚑Programmable Wallet idempotency keys are required on every mutation — reuse the same key on retries to avoid duplicate transfers.