MetaMask-style mental model
Most EVM dApps expect an EIP-1193 provider: an object with request({ method, params }) that answers wallet RPC calls. MetaMask injects that object at window.ethereum. WallCard gives you the same interface, but you construct and pass it explicitly.
| Concern | Browser extension wallet | WallCard SDK |
|---|---|---|
| Discovery | Injected globally (window.ethereum) | You import createNoderailsCardProvider() |
| Connect | Extension UI | Popup to /session-connect (card PAN, CVV, PIN) |
| Sign / send tx | Extension approval UI | Popup or iframe to /onetime-connect |
| Library fit | wagmi, ethers, viem connect to injected provider | Same libraries connect to WallCard provider |
Where ethers.js and viem fit
ethers.js and viem are transaction and encoding libraries. They do not replace a wallet. You pass the WallCard provider into BrowserProvider (ethers) or a wagmi custom connector (viem under the hood). WallCard handles custody and approval; ethers/viem handle ABI encoding and RPC-shaped calls.
Solana parallel
For Solana, the same provider object answers solana_* RPC methods. Your app or Solana wallet adapter integration calls provider.request() with Solana-shaped params. Approval still flows through WallCard hosted UI, not Phantom injection.
Sui parallel
For Sui, call sui_signPersonalMessage, sui_signTransaction, or Wallet Standard aliases (sui:signPersonalMessage, sui:signTransaction). createNoderailsCardProvider() registers WallCard with Sui Wallet Standard in browser contexts so @mysten/dapp-kit and similar libraries can discover the wallet. Use getLinkedAddresses().sui for the linked address after SessionConnect.
Popup instead of extension
From your dApp's perspective the API matches extension wallets. The user experience differs: connect and sign open WallCard web wallet UI where the user enters card details and OTP instead of unlocking a browser extension.