Vertical Fintech

Guides

The stack explained: payments, banking, cards, lending

Who this is for

The founder, COO, or head of fintech at a vertical software company who has to pick infrastructure, not a consumer app and not a consulting slide. You already have (or are building) the system of record a trade runs: the POS, the field-service board, the practice system, the marketplace. You want to take a rate on money movement inside that product. This page is the map of the jobs. It is not a ranked vendor list and not a score.

If you already know the job is payments, banking, or lending, skip to that pick guide. If you are still naming the job, stay here. The listings are names. How we pick is the rules this directory uses to put a name on a table. This page is how the tables fit together.

What Vertical Fintech means (rails you embed, not industry apps)

Vertical fintech, on this directory, is the infrastructure a vertical software company embeds so it can take a rate on money movement. The platform stays the product. A bank, payment facilitator, issuer, or licensed lender usually holds the license. Embedded finance is the broader industry phrase. This is the vertical-software cut of that phrase.

It is not the industry software itself. A restaurant POS, a field-service system, or a practice-management app is vertical software. Those products can accept cards, store a balance, issue a spend card, or offer capital. Doing that does not make the POS company a fintech directory, and it does not make this directory a list of industry apps. We list the rails that product embeds. We do not list the industry app.

“Take a rate” is the eligibility test. Referral volume with no price you set and no spread you keep is not the job. A single-store merchant processor is not the job. A consumer wallet, an invoicing app, a scheduler, a BPO, or an agency is not the job. If a vertical software company cannot embed the product so its users move money and the software company earns on that movement, the name does not belong here. Read that again if a vendor homepage says “embedded” and means a plugin for one store.

The honest constraint is license. You do not become a bank, a PayFac, an issuer, or a lender by shipping an API. Someone else is usually registered. You keep the merchant relationship and a fee, a spread, or a bounty. Ask who is registered, who underwrites, who holds deposits or the BIN, and what you actually own if you leave. Do not call the company a fintech because the deck said embedded finance.

The layers (payments → banking → cards → lending → miscellaneous)

A product sits in the layer of the job, not in every layer its homepage mentions. The homepage stack on this directory is five layers. Order on a category page is editorial fit for that job, not a score you can buy.

Payments is the beachhead. PayFac-as-a-service and platform payments: take a rate on merchant volume without becoming a PayFac. The usual first mechanism is an application fee on someone else’s license, or an interchange-plus buy rate you mark up while another party stays registered. Residuals you own are a later claim, not the default start. Orchestration and vaulting can sit next to payments. They do not, by themselves, put a rate in your bank account. The decision tree is on How to pick payments. The names are on payments.

Banking is accounts, wallets, and treasury when the job is holding balances, not only moving card volume. Banking-as-a-service still needs a sponsor bank. Middleware sits in front of partner banks. Some listings are the bank selling its own APIs. Treasury and payment operations move and reconcile money, often on accounts you already have. None of that makes you a bank. Production on this table waits on bank diligence. The decision tree is on How to pick embedded banking. The names are on banking.

Cards is issuing: virtual or physical spend cards a vertical software company puts in its users’ hands. That is card issuing, not card acquiring. Acquiring is the payments job (taking cards at checkout). Issuing runs on a partner bank’s BIN sponsor through an issuer processor or program manager. You brand the card and set spend controls. You are typically not the licensed issuer. Live programs wait on sales, bank approval, and program setup. There is no pick-cards guide on this directory yet. Read the cards table and the issuing glossary if spend is the job. Do not start here if you have not already named the payments job.

Lending is credit or capital offered through the software the merchant (or the merchant’s customer) already runs. Embedded lending is the channel. The product can be merchant cash advance shaped (a cut of sales or a receivables purchase), a bank-originated business loan, or consumer installment at checkout. You are usually not the lender. Brand risk is real if the holdback is stiff or servicing is ugly. This directory does not print factor rates or APRs. The decision tree is on How to pick embedded lending. The names are on lending.

Miscellaneous is infrastructure around the money: orchestration, risk, onboarding, visualization, ledgers, vaults. It is not a PayFac, not a bank, not a card program, not a lender. Know Your Business and Know Your Customer live here as the checks a bank, PayFac, or lender will still require. A PCI vault is how you avoid locking card data in one processor. A risk platform is not a license. The names are on miscellaneous. Do not use this table to take a rate. Use it so the rate you take does not blow up onboarding or fraud.

If a homepage claims payments, banking, cards, and lending, pick the job you are buying this quarter and read that table. A bundled pitch is not a reason to skip “who is registered.”

Typical order most teams ship

Most teams start with payments. That is the site’s own line, and it is the honest sequence for vertical software. You already have merchants. Checkout and payouts are how you take a rate this quarter without a charter. Read the payments pick before you shop a bank.

Onboarding and risk show up immediately, even if you did not plan a miscellaneous project. A PayFac or a sponsor bank will not board a trade name. KYB on the entity, KYC on control persons, and a decisioning path sit under someone else’s policy. You can buy those tools and still not be the underwriter.

Banking comes after you have a reason to hold a balance: wallets, payouts you control, stored value, or a ledger your merchants will live in. Do not buy a BaaS program because a deck said “the full stack.” If you only need to move and reconcile money, that is treasury, not a deposit product.

Cards come when spend in the user’s hand is the product (payouts, expenses, contractor cards), not as a trophy BIN. Issuing is a bank program. It is not a checkout plugin. A deposit sponsor and a BIN sponsor can be the same bank. They are not automatically the same role.

Lending comes when you already see sales or a consumer checkout and you want to offer capital inside that workflow. Processor-tied capital (a Connect platform, an Adyen balance platform, a commerce admin) is the shortest path and the least portable. A white-label working-capital partner is a program you take to the merchants, not a toggle on the processor. Consumer installment is a different borrower than SMB working capital.

This page does not print a month count or a volume number that unlocks the next layer. Teams ship out of order when the job is out of order (a spend-card product with no merchant acquiring; a lending marketplace with no PayFac). Name the job. Do not ship four layers because a vendor sold a suite.

How /method fits

How we pick is the editorial contract for every listing on this directory. This page does not replace it. The stack tells you which table to open. Method tells you why a name is on that table, and why a name is not.

Claims come from materials the vendor publishes: product pages, docs, pricing pages, newsrooms. If a fact is not on those pages, or it is not clear, it is omitted. No invented metrics, pricing, customer names, or geography. Vendor claims stay vendor claims. Best For, Not For, and the Honest verdict are ours.

The verdict is a point of view, labeled as such. It says what the product is actually good for and what it is not. It is not a score, a ranking, or a sales email. Nobody buys a slot, a rank, or a button. There is no paid placement, no sponsor unit, and no affiliate link. The only outbound link on a listing is the vendor’s official site.

A name is eligible only if a vertical software company can embed it to take a rate on money movement for its users. Miscellaneous is supporting infrastructure, not a merchant processor sold to a single store. Merchant processors sold to a single store, consumer wallets, invoicing apps, schedulers, BPOs, and agencies do not belong.

A product sits in the layer of the job, not in every layer it mentions on a homepage. Order on a category page is editorial fit for that job, not review volume and not recency. The category page is the whole list. We do not sell a better slot.

Guides on this directory (this page and the three pick pages) use the same rules: public facts, no invented thresholds, no selling rank. Guides may name vendors in comparison context so the decision tree is usable. Listing oneLiners and verdicts still do not use another company as the pitch.

If you want the short version of why a name is here, read the listing. If you want the rules we will not break to put a name here, read How we pick. If you want to know which job you are in, you are on the right page.

FAQ

Is vertical fintech the same as vertical software?

No. Vertical software is the industry product. Vertical fintech is the money infrastructure that product embeds so the software company can take a rate. This directory lists the infrastructure, not the industry apps. Read vertical fintech.

Do we need the full stack on day one?

No. Most teams start with payments and take a rate while another party stays registered. Banking, cards, and lending are later jobs with their own licenses and diligence. Miscellaneous (KYB, vault, risk) shows up as soon as you board or store a card. It is still not a reason to become a bank.

Where should we start if we want accounts, cards, and capital?

Start by naming the money you already touch. If you take cards from merchants today, you are on payments. If you need to hold their money, you are adding banking. If you need them to spend, you are adding cards. If you need to offer them capital, you are adding lending. Read the pick guide for the first job you will actually ship. A suite pitch is not a sequence.

Why is a name on miscellaneous instead of payments?

Because the job is around the money, not taking the rate. Orchestration, vaults, KYB, and fraud tools do not make the vendor a PayFac, a bank, an issuer, or a lender. If you need the vendor to underwrite and settle merchants, you are still on the payments table.

How does this page relate to How we pick?

This page is the map of layers and the usual order teams ship. How we pick is the editorial contract: public sources, honest fit, no paid placement, eligibility, and how order works. Guides decide the job. Method decides whether a name may appear. Listings are the names.

Updated 13 Sept 2026

Back to the guides. How a name gets on the short list:How we pick.