Most startups treat Stripe as the thing that collects money and nothing else. Meanwhile the same account can issue virtual cards for vendor payments, hold a balance, and increasingly handle the outbound side of the ledger too. Founders who already run revenue through Stripe often find they have half a spend stack sitting unused.
That is worth knowing, and it is also worth knowing where it stops. Stripe is card and money-movement infrastructure. It is not, on its own, an accounts payable department.
The short version
- Stripe Issuing creates virtual cards for one-time or recurring vendor payments, and creating them carries no charge for the card itself.
- A virtual card per vendor limits fraud exposure to that card's limit if the number is intercepted.
- Stripe previewed bill pay, automated cash rewards, real-time payments and accounting integrations through Treasury at Sessions 2026.
- Stripe Issuing has issued more than 350 million cards as infrastructure, mostly for platforms rather than for a business's own spend.
- What it does not give you: an approval workflow, an invoice inbox, a vendor ledger, or receipt policy enforcement.
What Stripe Issuing actually does for your own spend
The useful primitive is a virtual card you create on demand, with its own number, its own limit and its own name.
Give each recurring vendor its own card. The AWS card has a limit that matches your expected AWS bill. The contractor card has a limit that matches the contract. If a number leaks, the exposure is capped at that card rather than at your whole line, and you cancel one card instead of reissuing everything and re-entering a number at forty vendors.
The second benefit is naming. A card per vendor means the charge arrives already attributable, which turns a category of bookkeeping guesswork into a lookup. "What is this $840 charge from a payments descriptor nobody recognizes" becomes a solved problem when the card itself is named after the vendor.
For a business that already sits inside Stripe and has engineers, creating these programmatically is straightforward. That is the strength and it is also the shape of the limitation: this is infrastructure, driven well from code and less well from an operations dashboard.
Where the AP workflow stops
An accounts payable process is four things, and Stripe gives you the fourth.
- An invoice arrives and lands somewhere findable rather than in one person's inbox.
- Somebody approves it against a budget or a contract, with a record of who approved what.
- It gets coded to an account, a class or department, and a period.
- It gets paid.
Stripe is very good at step four and does not attempt one through three. A dedicated AP tool exists for the first three. That is not a criticism of Stripe, it is a description of what it is for, and it matters because a founder who adopts Issuing thinking they have replaced their AP process has replaced the easiest quarter of it.
The version that works well in practice at small scale: virtual cards for everything recurring and predictable, a real AP or bill pay tool for anything with an invoice and an approval, and one person who owns the coding. At a company under about twenty people the AP tool is often optional, and the coding is not.
What Stripe previewed for 2026
At Sessions 2026 Stripe showed bill pay, automated cash rewards, cash acceptance, check acceptance, real-time payments and accounting integrations through Treasury for platforms, plus embedded components that put Treasury and spend cards into a product in a few lines of code. There was also a preview of prepaid debit cards letting marketplace sellers and customers spend their balance.
Read that list carefully: the framing is Treasury for platforms. Most of it is aimed at companies embedding financial services for their own users rather than at a startup managing its own vendor payments. Some of it lands in both places. The honest position in August 2026 is that the direction is clear and the specifics for a business's own AP are still moving, so build on Issuing today and watch the rest.
The bookkeeping problem this creates
Putting more through Stripe simplifies the integration and complicates the ledger, and only the first half is obvious.
One Stripe account can carry gross revenue, processing fees, refunds, chargebacks, payouts to your bank, and now outbound card spend. Those are six different accounting treatments arriving in one stream, and the software's default guess is right for maybe three of them.
The error that matters most is payouts. A Stripe payout is money moving from your Stripe balance to your bank account. It is a transfer between two asset accounts, and it is never revenue. Booking payouts as revenue understates your processing fees, misstates gross revenue, and produces a margin figure that is wrong all year in a direction that flatters you. It survives right up until someone in diligence ties your revenue to your Stripe dashboard and the numbers do not match.
The correct treatment is unglamorous. Record gross revenue when the charge succeeds. Record the Stripe fee as an expense in the same period. Record the payout as a movement from the Stripe balance asset to the bank asset. Reconcile the Stripe balance monthly like any other account. Add outbound card spend and you now have a second flow through the same account that has to be separated from refunds.
Median handles Stripe as a first-class connection and does this every business day: gross revenue and fees split correctly, payouts treated as transfers, card spend categorized against the vendor, and an accountant reviewing what the automation flags rather than a founder finding it at year end. For the mechanics of the revenue side specifically, see how to automate Stripe revenue tracking.
Frequently asked questions
Can I use Stripe to pay vendors? Yes, through Stripe Issuing, by creating virtual cards for one-time or recurring vendor payments at no charge for the card itself. It does not provide the approval workflow or invoice inbox an AP tool does.
Is Stripe Issuing free? Creating virtual cards for your own vendor payments carries no charge for card creation. Stripe Issuing as a product has its own pricing depending on use, and it changes often, so check the current page.
Does using Stripe for spend simplify my bookkeeping? It simplifies the feed and complicates the ledger. One integration, but six different accounting treatments arriving in one stream.
Should I use Stripe Issuing instead of Ramp or Brex? Usually alongside. Ramp and Brex are spend management with approvals and policy. Stripe Issuing is card infrastructure, strongest when driven from code.
What is the most common Stripe accounting mistake? Recording payouts as revenue. A payout is a transfer of money already earned, so counting it as revenue double-counts the sale and hides the processing fees.
What to do next
- List every recurring vendor charge on a shared card. Each one is a candidate for its own virtual card with a matching limit.
- Check how payouts are currently coded in your books. If they hit a revenue account, that is your highest-value fix and it affects every month this year.
- Decide deliberately whether you need an AP tool yet. Under about twenty people, virtual cards plus disciplined coding usually covers it.
- Reconcile the Stripe balance monthly, the same as a bank account. It is an asset account and it drifts silently when nobody treats it as one.
See how Median handles Stripe end to end, with revenue, fees, payouts and spend separated every business day.