Developer-First Issuing Replaces Manual Operations
Meg Nakamura, co-founder and CEO of Apto, on winning underserved markets with card issuing
Developer-first in issuing is really a claim about replacing manual financial operations with software. In card issuing, even basic setup has historically meant sales calls, custom configuration, bank coordination, and human review. Apto is positioning against that older model by making program setup look more like Twilio or Stripe, where a developer can sign up, get keys, test, launch, and only bring in people for exceptions or scale.
-
The reason this still felt new in issuing is that the category was built around enterprise deals first. Marqeta proved API-first issuing at scale, but the next wave, including Lithic, Highnote, and Apto, was explicitly aimed at the long tail of developers and startups that traditional issuer processors left underserved.
-
What developers actually want is control over card behavior without waiting on an account manager. That means choosing spend controls, limits, funding logic, wallet links, or debit program options through APIs and dashboards, instead of filing tickets and waiting for operations teams to configure each program by hand.
-
This changes the business model as much as the product. Self serve issuing lets a platform take many small bets on startups and embedded finance companies, then grow with the few that break out, much like Twilio. That is very different from an enterprise processor model built around a small number of large accounts.
The next phase of issuing is a split market. Large integrated platforms will keep winning standard card programs, while developer-first issuers win where teams need speed, modularity, and unusual product logic. As more software companies embed cards into payouts, lending, treasury, and crypto flows, the issuers that turn operations into APIs will keep taking share.