← Protocols
Wirex (BaaS)
Payments / Onramp·Multi-chain · EVM · Bitcoin

Wirex (BaaS)

01Description

Wirex Banking-as-a-Service API for partners offering blockchain-based financial products: card issuance (virtual + physical, 3DS-authenticated), crypto-asset custody and unified balance tracking, SEPA/ACH bank account integration, KYC/onboarding, recipient management, and transaction history.

02Best for
  • 01issuing crypto-funded Visa/Mastercard debit cards to end users
  • 02embedded EUR (SEPA) or USD (ACH) banking inside a Web3 product
  • 03consumer wallets that need fiat off-ramp via card spend
  • 04unified crypto + fiat balance UX with regulated rails
  • 05global remittance flows leveraging stablecoin liquidity and local payouts
03Install
  • # REST API — no official SDK. Use fetch / ofetch / axios.
  • pnpm add zod # recommended for runtime-validating Wirex responses
04Environment variables
VariableScopeDescription
WIREX_API_KEYServerPartner API key issued by Wirex after BaaS onboarding. Server-only.
WIREX_API_BASE_URLServerSandbox or production base URL provided by Wirex during partner onboarding (not publicly listed).
WIREX_WEBHOOK_SECRETServerSigning secret used to verify Wirex webhook deliveries (card events, transfers, KYC state changes).
05Prompt snippet
Use Wirex BaaS when the product needs regulated card issuance + multi-asset banking under one partner. Core flows: create a user (`/users` with KYC payload) → assign capabilities (cards, SEPA, ACH, crypto) → issue a card (`/cards`) → fund it from the user's crypto or fiat balance → handle 3DS authentication callbacks server-side → reconcile spend events via webhooks. All card transactions require 3DS step-up; never bypass it. Balances are unified across crypto + fiat — read the aggregated balance endpoint, don't sum sub-balances client-side. For payouts, use the recipient + global-address endpoints to dispatch SEPA/ACH transfers. Treat all webhook deliveries as at-least-once and idempotent on your side.
06Gotchas
  • Wirex BaaS is partner-gated and license-dependent: regional availability for card issuance varies (EU, UK, APAC tend to be live first; US ACH support has separate enrollment). Confirm coverage for your target users before building.
  • Card issuance triggers KYC re-checks even for already-onboarded users — UI must handle a 'pending' card state, not an instant issuance.
  • 3DS authentication is mandatory and Wirex-hosted; you must redirect the user to Wirex's challenge URL and handle the return callback — do NOT attempt to inline the challenge.
  • Bank-account beneficiary validation differs between SEPA and ACH (IBAN vs routing+account number) — the same `/recipients` endpoint accepts both shapes but error messages are terse; validate client-side first.
  • Crypto deposits to a Wirex-managed address are credited after on-chain finality which varies per asset (BTC ~6 confirmations, ETH ~12) — show a 'confirming' state instead of optimistic credit.
  • Webhook payload schemas can change between minor API versions; pin your client to a specific `X-API-Version` header and version your webhook handlers.
07Alternatives