Supported use cases
User wallets
One wallet per cardholder. The user logs in inside your app, gets a wallet, deposits stablecoins, and spends them with their card. Under a Rain-managed program the wallet is set as the owner of the user’s collateral contract, so the user, and only the user, can withdraw the collateral that backs their card.Corporate wallets
One wallet can support many cards. In a corporate program, the company’s initial user creates a wallet, and that wallet address is included on the corporate application. The wallet then becomes the owner of the company’s collateral contract. All cards issued to company members can spend from that same collateral contract, so the company can fund it from one wallet and use the balance across multiple cards. Wallet creation works the same way as it does for a consumer user. The difference is in the Rain API model: for corporate programs, the collateral contract is associated with the company rather than an individual user.Features
Platform-by-platform detail is in the feature matrix.
Security model
Where keys live. A user’s seed is generated inside a secure enclave in Rain’s wallet infrastructure and never exists in plaintext outside it. Signing happens inside the enclave; the app sends a transaction to sign and gets a signature back. Rain’s servers, and yours, never see the key. Who can sign. Only an authenticated session for the wallet’s owner can request a signature. A session is created by a login your user completes (a one-time code to their contact, or a passkey ceremony on their device) and is stored in the device’s secure storage. It expires and is refreshed automatically while the user is active; when it can’t be refreshed, the SDK tells your app and the user logs in again. Logging in on a new device ends the session on the old one. What non-custodial means. Neither Rain nor you can move a user’s funds. Rain operates the infrastructure but cannot sign on the user’s behalf; you never handle key material at all. Recovery. The seed can be exported by the user as a standard recovery phrase or per-chain private key, decrypted on the device. A user who loses their device logs in on a new one with the same email or phone number, or with a passkey synced through their platform’s passkey provider, and the same wallet is waiting. What Rain can’t do is recover an account that has no reachable login method, which is why enrolling a backup method is important. See Backup and recovery. What the SDK never does. It never calls the Rain issuing API and never holds your API key; contract lookups and withdrawal signatures come from your backend. It never logs or persists exported keys or one-time codes. Presenting exported keys safely and gating them behind biometrics is your app’s job.Coming at GA: a full recovery model with a dedicated setup guide and runbook, and SDK calls to set and change the collateral contract’s owner wallet. Card-settlement signing under a Rain-managed program uses a narrowly scoped, automatically revoked delegated signer; its documentation lands with GA.
How wallets support card spend
Your Rain program is either Rain-managed or partner-managed, and the wallet’s role in card spend differs between them. Wallet creation, authentication, backup and recovery, key export, balances and history, receiving, sending, and gas sponsorship behave identically in both. Only the card-funding and settlement leg changes.
If you don’t know which you’re on, check First steps or ask your account manager. Then read Flow of funds; the mechanics of each model are already documented in Managing collateral and Rain-managed programs, and the wallet pages link there rather than repeating them.
What’s next
Authentication options
Passkeys or one-time codes, and how to choose.
Card funding and settlement
From wallet to card, end to end.
SDK quickstarts
Build it in Swift or Kotlin.