For launch, usually yes. Building card processing to certify against the schemes is a multi-year programme that almost never earns its place in a first release. The decision that actually matters is not whether to use a processor but which one, judged on two things that only become visible later: whether you get unabridged authorisation and settlement data, and whether the contract and architecture let you leave.
Raw data access is the one that surprises teams. Authorisation rates, decline reasons, issuer behaviour and fraud patterns are where card economics are won, and a processor that returns summarised or normalised responses removes your ability to work on any of it. Ask for a sample of the actual message-level data before signing, not the dashboard.
Dispute and chargeback handling deserves the same scrutiny. It is operationally heavy, it scales with volume, and processors differ enormously in how much of it they do and how much lands on your team. The cost of a processor is the fee plus the headcount their model implies, and the second number is frequently larger.
Exit terms matter more than launch terms. Card migrations are painful because the BIN, the tokens and the stored credentials are entangled with the processor, and a contract that does not address token portability makes leaving expensive regardless of what the architecture allows. This is worth negotiating hardest when you have the least leverage but the most attention: before signing.
The genuine case for building is narrow. An unusual product where scheme-level control is the differentiator, at a volume where basis points fund the programme. That is a small set of companies, and most of them started on a processor and migrated deliberately.