A standard payment stack RFP runs to several hundred questions. Most of them are answered with some version of “yes”. A small number are answered with detail that genuinely separates the suppliers. The work is making sure your RFP is mostly the second kind.
Mark McMurtrie has spent a career writing payments RFPs from the merchant side. We sat down with him to draw out the question patterns that distinguish good orchestration evaluations from polite ones. The answers are surprisingly practical.
The “can you” problem
The most common RFP failure mode is the closed question. “Can you support smart routing?” “Are you PCI compliant?” “Do you offer decline cascading?”
Every supplier will answer yes. That isn’t because they’re being slippery; it’s because the question doesn’t leave anywhere else to go. And once everyone’s said yes, the scoring matrix gives every supplier the same mark, and the differentiation work has to happen somewhere else. Usually in the demo, when there’s no time to interrogate the detail.
Mark’s reframe is simple. Stop asking “can you?” Start asking “how, in what depth, and against what data?”
So instead of “are you PCI compliant?”, the better question is: “What is the date of your last PCI DSS Level 1 certification, and who was the Qualified Security Assessor who signed it off?”
Both questions test the same thing. Only one of them reveals whether the supplier has just renewed, is six months overdue, or has changed assessor recently because the last one flagged something. None of that is in the yes/no answer.
Specific question patterns for orchestration
The “how, in what depth, against what data” pattern unlocks the parts of an orchestration evaluation that matter most. Three areas where it pays off.
Smart routing
“Can you support smart routing?” reveals nothing. “What parameters can your routing engine evaluate at the transaction level: card type, currency, BIN range, merchant category, time of day, issuer behaviour, historical authorisation rates by route, and which of those parameters can the merchant configure versus which are fixed?” reveals everything.
The depth of the routing configuration is the difference between a router that follows a static rules table and a router that responds to live data. The “can you?” question can’t distinguish them. The parameter question can.
Decline cascading
The shallow question is “do you cascade soft declines?” The depth question is: “Under what specific conditions does your cascade trigger? Network rules, soft-decline response codes, time-since-last-attempt, merchant configuration, or some combination? What’s the typical recovery rate you see across your enterprise base, by acquirer pair and by industry?”
The first question separates suppliers who cascade from those who don’t. The second separates suppliers who understand cascading economics from those who’ve checked a feature box.
Integration and parity maintenance
Orchestration’s whole pitch is the single API. “Can you connect to acquirer X?” misses the actual operational question, which is: “When acquirer X releases a scheme update or a new API version, how quickly do you maintain feature parity, and what’s the merchant’s exposure during the transition? What’s the longest your platform has been behind a scheme change in the last twelve months?”
The right answer is honest about timelines, transparent about exposure, and includes specifics rather than reassurance.
Beyond the spreadsheet
Most RFP formats default to an Excel response template. Each question gets a cell. The supplier fills the cells. The merchant scores the cells.
Mark is direct about the cost of this. “If your format of your RFP is solely ‘complete this Excel spreadsheet’, then it’s not easy to see graphical images, and pictures often tell a thousand words.”
For orchestration specifically, the architecture matters. The way a supplier explains how their routing engine sits relative to acquirers, how their reconciliation pipeline ingests settlement data, how their cascading flow handles state. These are easier to evaluate from a diagram than from a paragraph. Allow suppliers to attach diagrams. Some will produce better ones than others, and the difference will tell you something useful about whether they think visually about architecture.
The differentiation question
The single most useful question Mark recommends including in every RFP is one that most procurement teams leave out, because it doesn’t fit the structured-scoring format.
“Why is your solution better than your competitors’?
It’s open. It can’t be marked on a five-point scale. It produces wildly different responses across the supplier set. And it forces every supplier to articulate their actual USP rather than hide behind feature-parity claims.
The strongest responses are surprising. The weakest are essentially restatements of marketing copy. Both are revealing.
Weighting questions to the primary objective
Most RFPs apply even weightings. Every section is worth roughly the same, and every question inside each section is worth roughly the same. This produces a scoring matrix where suppliers cluster within a few percentage points of each other, and the final decision ends up being made on something outside the matrix entirely.
The discipline is to weight by the primary objective the RFP was set up to serve. If the objective is cost reduction, the commercial section is weighted heavily, and the questions about fee transparency, interchange optimisation, and FX margins get more marks than the questions about checkout customisation. If the objective is international expansion, the local payment method coverage and time-to-add-new-markets get weighted more than the cost discussion.
Pick one weighting bias and apply it. The clustering breaks. The shortlist becomes obvious.
The questions worth asking yourself first
Before sending any of these questions to a supplier, three questions are worth asking inside your own organisation.
Have we written down our primary objective in a single sentence, and does the RFP weighting reflect it?
Are our questions specific enough that a thoughtful supplier could produce a non-obvious answer? If every supplier could answer “yes”, or worse, every supplier will, the question is wasted.
Are we leaving room for diagrams, narrative explanations, and supplier-led differentiation?
If those three are honest yeses, the answers you get back will tell you who you’re choosing, not just who responded.
