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.
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.