.png)
People lump anyone who “does payments” into one bucket. That creates bad RFPs and bad expectations.
Futurify is an independent software vendor (ISV). We build and run a payment layer inside your systems. We are not a payment service provider. We are not a money services business. We never sit in the flow of funds.
The short version
| ISV (us) | PSP | MSB | |
|---|---|---|---|
| What you buy | Software + delivery (Build, then Run) | Payment acceptance / processing as a service | Money movement / remittance / stored-value services under licensing |
| Where the tech runs | Inside your perimeter (default) | Their platform / rails you integrate to | Their licensed operation |
| Who holds funds | Never us — your processors / banks | Often in their settlement model | Typically the licensed entity |
| Processor / bank contracts | Yours | Often with or through them | Their licenses and partners |
| Merchant / end-user payment support | You (or your ops) — we do not run a merchant helpdesk | They do — that is part of the service | They do — compliance + customer ops sit with the licensee |
| What “support” from us means | Run: exceptions on the layer, connector updates, next rail — not merchant support | Product + ops support for their payment product | Licensed ops + customer support for their money service |
| Exit | You keep code, config, data, contracts | Unwind their commercial + technical path | Regulatory + operational unwind |
Deployed inside vs running independently
A PSP or MSB runs their service. You connect to it. Their stack, their uptime story, their support queue for payment issues, their licensing footprint.
An ISV like Futurify ships software that lives in your stack. Your platform. Your controls. Your processor contracts. The router is yours; the rails are rented from processors and banks you choose.
That is why we say: own the router, rent the rails.
Payment inside the product, not a redirect
Because we sit inside your stack, payment does not have to mean bouncing the user out to someone else’s checkout.
We integrate payments into your platform so they feel like part of the same flow. Examples we build into onboarding and product:
- PAD / ACH — collect the void cheque (or equivalent) in your onboarding, extract the bank details, and hand them to your PSP or MSB partner — without leaving your UI.
- Cards — card capture and handoff as a step in your onboarding (embedded Components / Drop-in on your page), not a separate hosted-checkout hop. Issuer 3DS or some alternate methods can still open a challenge step inside that flow.
We do that integration work. Your processors and MSBs still move the money; we wire the experience so it feels like one product.
A PSP or MSB can still give you hosted pages and redirects. An ISV inside your stack can make payment look like your product.
Support — the line people miss
PSPs and MSBs sell an operated money service. Supporting merchants (or consumers) on that service is part of what you buy.
We do not replace that. We do not take custody. We do not become your payment helpdesk for end customers.
What we do sell after Build is Run: an owned exceptions queue on the layer, connector care, and help adding the next rail — so settlement and routing stay workable after go-live. That is engineering ownership of software you own, not MSB/PSP customer support.
If a buyer expects “we outsource payments ops and merchant support to Futurify,” they want a PSP or MSB, not us.
Why the label matters on a cutover
- Procurement — buying software + fixed-price Build is a different risk packet than onboarding a licensed money mover.
- Margin — you keep the processor spread; we never take custody to skim float.
- Exit — fire the ISV and you still hold contracts and the instance. Leaving a PSP/MSB is a money-path change.
- Second processor — the layer is designed so provider two is not another greenfield (see related writing).
Who this page is for
You are comparing vendors and someone asked “are you a PSP?” You need a one-pager that says no — and what that implies for where the stack runs, who supports merchants, and who holds funds.