Run a payment RFP
An independent tender for your payment set-up, run on your side of the table.
An RFP is the one moment in a payment relationship when the leverage sits with you. Before you sign, every provider in the market wants your volume and prices accordingly. After you sign, the integration is built, the switching cost is real, and the rates that looked sharp on day one are the rates you carry for the next five years.
Most tenders spend that moment badly. Requirements get written from a template, or from the incumbent's own feature list. Proposals arrive in five different formats and are compared on the one number that is easy to compare, the headline transaction fee, which is rarely where the money is. The provider with the strongest commercial team wins, not the provider with the strongest proposition.
When an RFP is the right instrument
A tender is not the answer to every payment problem, and it is the more expensive one to get wrong. If your provider still fits your business and only your pricing has drifted away from the market, you do not need to move, you need leverage. That is cut your PSP costs, where the renegotiation runs with your incumbent and the integration stays where it is.
An RFP is the right instrument when the set-up itself no longer fits. New markets with their own acquiring, schemes and local payment methods. A move to unified commerce where online and the kassa have to sit in one place. A replatform that reopens the integration anyway. A provider whose service changed after an acquisition. Or a renewal you are only willing to sign once you have seen what the rest of the market puts on the table.
The distinction is commercial, not procedural. A tender run purely for price, with no intention of moving, is read as exactly that by the market, and the proposals come back priced accordingly.
Does any of this sound familiar?
We launch in Germany and France next year. Our provider quotes those markets on request and cannot tell us what our cardmix will actually cost there.
Online sits with one provider and the stores with another. Nobody can give us one view of the customer or one reconciliation.
Our provider was acquired. The account team has changed three times since and the roadmap we bought into no longer exists.
We are replatforming. The checkout is being rebuilt regardless, so this is the cheapest moment we will ever have to change provider.
Our renewal is in four months. We will probably stay, but signing without testing the market is not a decision we can defend internally.
Where tenders lose money
The headline transaction fee is the number every merchant compares and the number every provider prices to win. The margin sits in what surrounds it. Acquirer markup on top of interchange, how scheme fees are handled and billed, the treatment of refunds and chargebacks, FX on cross-border settlement, gateway and account charges, minimum monthly commitments, and the rate review clause that decides whether your pricing follows your growth or stays where you signed it.
A tender awarded on headline rate alone routinely hands the winner back everything it conceded, well inside the first contract term, through lines nobody scored.
The second thing tenders lose is the leverage itself. Providers know precisely which merchants are genuinely willing to move and which are collecting quotes to wave at their incumbent. How the process is positioned is worth more than any single question in the document.
Why independence changes the outcome
EcomStream has never worked for a PSP or an acquirer and never will. No referral fees, no implementation revenue, no provider relationships to protect. The shortlist is built on what fits your business, and the recommendation is not shaped by who pays whom.
What EcomStream brings that no template does is knowing where the market genuinely prices for a merchant of your profile, drawn from tenders and audits run across comparable retailers and brands. That is the difference between asking a provider for a discount and knowing what that provider can still give.
Every engagement is handled personally by Ramon Helwegen, in payments since 2009, including eight years on the PSP side of exactly these processes.
How the process runs
EcomStream runs the tender end to end on your mandate, from the first data pull to the signed contract. Requirements and shortlist, evaluation, then negotiation and award. You approve the shortlist and you take the decision, EcomStream does the work in between.
Implementation support through the migration is optional and runs on a day rate, scoped separately from the tender. The ongoing management once you are live is optional too, and runs as Managed Performance Optimisation.
Four to five months from kick-off to signature is normal for a set-up of that scope. More markets, more providers or more internal stakeholders extend it; a single market with a clear incumbent runs shorter.
A tender is not the same thing as covering a gap in your payments team. That is an interim assignment, on a day rate.
What it costs
No cure, no pay. No upfront fee, no retainer. EcomStream is paid a share of the savings the tender delivers, measured on your own volumes against your current cost base, and only once they are contracted.
If the outcome is that your current provider is the right one at the right price, that is a legitimate result of the process and it costs you nothing.
That covers the tender itself. The optional implementation support through the migration is charged on a day rate, agreed before it starts.
Start the conversation. If your provider still fits and only the pricing has drifted, start with cutting your PSP costs. If the gap is in authorisation rate rather than in rates, that is Managed Performance Optimisation.
I'm interested in running a payment RFP
Client references
