How it works
Cards are created with your issuer processor — Lead’s role is oversight, so you report each card to Lead as a Card object, keep its status current, and report card spend in your daily Transactions file like any other activity. Settlement with the networks runs through Lead’s network settlement process; your job there is reconciliation.Example scenario
Nest Egg (from the deposit guide) adds a debit card offering. Priya orders one; Nest Egg’s issuer processor creates it, Nest Egg reports it through the Cards API the same day and activates it when Priya confirms receipt. Her coffee purchase is authorized at the processor, settles through the networks, appears in Nest Egg’s Transactions file, and reconciles against Lead’s settlement report for that cycle.Objects involved
Before you start
- A working deposit integration Launch a deposit program and an issuer-processor relationship.
- Use the Cards API (Beta) for new programs; the card file schema remains the path for existing file-integrated programs.
- Card spend rides the same daily Transactions file as the rest of your activity — file-based today, with user transaction APIs as the planned successor (Platform Evolution).
Reporting card issuance
Report each card at creation:POST /v0/cards
{ "account_id": "...", "form": "physical | virtual", "...": "..." }
Decision point (physical cards): report at creation and activate on customer confirmation — the report-then-activate pattern mirrors the card-in-hand reality; virtual cards typically report and activate together.