A payment processor request for proposal (RFP) is a structured way to compare how prospective providers would support your actual payment flow, risk profile, data responsibilities, operations, and contract terms. Rather than asking only for a quoted rate, define the requirements that affect day-to-day acceptance: sales channels, card-not-present and card-present use cases, recurring billing, dispute workflows, integrations, reporting, settlement, customer support, and planned changes. For high-risk businesses, the RFP should also make the business model, fulfillment evidence, refund practices, and monitoring needs explicit so each response can be evaluated on the same facts.
Use the RFP to document assumptions, request evidence, and identify unanswered questions before selecting a provider; it is not a guarantee of approval, pricing, processing continuity, or a particular risk outcome. The broader selection framework in How to Choose the Best Payment Processor (2026 Guide) can help put the RFP findings into a complete decision process. Requirements, provider capabilities, and payment-network or acquirer expectations vary by merchant, geography, channel, and transaction type.
Table of Contents
- Start With a Decision Problem, Not a Quote Request
- Define the Merchant Profile That Providers Will Evaluate
- Build the RFP Around Comparable Response Fields
- Evaluate the Checkout, Integration, and Authentication Design
- Compare Operations, Reporting, and Support Before Commercial Terms
- Normalize the Commercial and Contractual Comparison
- Score Evidence, Run Diligence, and Make a Defensible Choice
- Frequently Asked Questions
Start With a Decision Problem, Not a Quote Request
An RFP supports a repeatable, documented comparison of processors, acquirers, payment facilitators, gateways, or an integrated arrangement. It is less useful as a generic questionnaire without an operating model. A provider can answer “yes” to a feature request yet remain a poor fit for the merchant’s channels, implementation resources, controls, or reporting.
State the decision on page one. For example: “Select a payment-processing arrangement for a U.S.-based online merchant with one-time and recurring card transactions, a mobile checkout, in-house support, and a planned platform migration.” Define whether “subscriptions” means fixed billing, variable consumption, memberships, installments, or merchant-initiated follow-on charges. The distinctions can affect implementation and operations.
For a business that may be treated as higher risk, use neutral facts rather than labels. Describe the offering, order process, fulfillment, cancellation and refunds, order values, delivery timeframes, sales geographies, available processing history, and expected changes. The aim is not an underwriting conclusion; it is a consistent basis for respondents to identify constraints and dependencies.
A useful RFP also separates must-haves, important preferences, and exploratory items. A must-have could be a required e-commerce platform integration, the ability to accept a particular transaction type, a needed settlement currency, or a specific role-based reporting permission. A preference might be a particular dashboard experience. An exploratory item is a capability that the merchant is considering but has not approved internally. This hierarchy prevents a long feature list from giving small preferences the same weight as requirements that could stop launch.
Name an internal owner for each workstream. Finance should validate settlement files, funding definitions, reserves if proposed, and fees. Engineering should assess APIs, test tools, webhooks, token portability, and release support. Security should review data flows and evidence. Operations should test disputes, refunds, reconciliation, and escalations. Legal or qualified advisers can review questions appropriate to the merchant’s situation. This is educational information, not legal, compliance, or underwriting advice.
Define the Merchant Profile That Providers Will Evaluate
Begin with a concise merchant profile and supporting appendix. Avoid unnecessary sensitive data in an initial competitive process, but provide enough detail for a meaningful response. “E-commerce business seeking card processing” cannot show whether a setup fits the actual checkout, delivery, or customer-service model.
Include legal and trading names, sales locations, site or app URLs, offerings, customers, channels, accepted payment methods, expected volume, transaction values, refund and cancellation policies, fulfillment timing, and seasonality. State the mix of direct-to-consumer, business-to-business, one-time, and recurring activity. Describe marketplace, affiliate, call-center, pre-order, continuity, or delayed-fulfillment elements that affect the customer’s experience of a charge.
For context, prepare a clean period of processor statements and operational records, not only a summary rate. Invite respondents to specify needed evidence. An initial response is not a final underwriting decision: a provider may need more documentation or identify conditions after reviewing the full model. Allow for that in the timeline and approval process.
Map the payment flow in plain language: where a shopper enters payment details, which systems receive events, where orders, refunds, disputes, and communications are managed, and who can change settings. Note whether credentials pass through the merchant environment or use a hosted page, redirect, embedded fields, tokenization, or point-to-point encryption. PCI SSC says PCI DSS applies to entities involved in payment processing and cautions that encryption alone generally does not take cardholder data out of scope. 1
Ask each respondent to diagram the proposed data flow, identify systems and services within its assessment scope, and state merchant assumptions. If tokenization or PCI-listed point-to-point encryption is proposed, ask what changes and what remains the merchant’s responsibility. PCI SSC says a listed P2PE solution can significantly reduce applicable merchant requirements but does not remove PCI DSS applicability entirely. 1
Build the RFP Around Comparable Response Fields
Give every provider the same response format. Free-form proposals are difficult to compare when one respondent defines “settlement” as release of funds and another as a network event. Require documentation, contract language, product configuration, or an implementation assumption for material answers. Treat a blank or “available” response as clarification, not a confirmed capability.
The following template can be placed in the RFP after the merchant profile. Tailor the priority and acceptance criteria before sending it.
RFP Section — Request to Providers — Merchant Evaluation Note
Provider model
Request to providers:
Identify the contracting entity, acquiring or processing role, sponsored relationships where relevant, and subcontracted services.
Merchant evaluation note:
Confirm who owns each obligation and escalation path.
Merchant fit
Request to providers:
State supported business models, channels, territories, transaction types, and any assumptions or exclusions.
Merchant evaluation note:
Compare the response to the documented merchant profile.
Integration
Request to providers:
Describe API versioning, SDKs, hosted options, test environment, webhook behavior, idempotency, error handling, and change notices.
Merchant evaluation note:
Test critical flows, not only a demo transaction.
Payment data
Request to providers:
Provide the proposed data-flow diagram, token model, security documentation, and allocation of payment-data responsibilities.
Merchant evaluation note:
Identify scope assumptions and unresolved controls.
Authentication and risk tools
Request to providers:
Explain available authentication, fraud controls, rule ownership, review workflows, and data fields.
Merchant evaluation note:
Evaluate fit with the merchant’s customer journey and operating capacity.
Operations
Request to providers:
Describe authorizations, captures, reversals, refunds, voids, disputes, reporting, reconciliation, settlement reports, and support escalation.
Merchant evaluation note:
Verify terms and file fields against internal processes.
Commercial terms
Request to providers:
Present all recurring, transactional, one-time, network, third-party, currency, reserve, termination, and optional-service charges with definitions.
Merchant evaluation note:
Normalize each proposal before comparing.
Contract and transition
Request to providers:
Identify term, termination, data access, credential migration, implementation dependencies, and exit support.
Merchant evaluation note:
Review with qualified internal or external advisers as appropriate.
Each answer needs columns for evidence, owner, assumption, and open question. Evidence can include documentation, sample files, an attestation, a demonstration, or contract language. The point is to distinguish a stated capability from one that has been evidenced and tested.
A provider arrangement may include more than the brand on the proposal. Ask who provides the gateway, token vault, fraud tools, support desk, acquiring relationship, dispute support, and data storage, and which services are subcontracted. PCI SSC recommends understanding how services map to applicable PCI DSS requirements and describes requesting documentation of assessed services and environments when a provider represents them as PCI DSS compliant. 2
A responsibility matrix belongs in the RFP, even for a simple stack. List the process or control, merchant and provider owners, any subprocessor, evidence, review date, and unresolved dependency. It does not replace an agreement or validation; it exposes gaps such as a provider supplying tokens while the merchant owns the page loading payment fields.
Evaluate the Checkout, Integration, and Authentication Design
Anchor the comparison in transaction journeys. Document payment initiation through order confirmation plus exceptions: an expired authorization, partial fulfillment, post-settlement refund, duplicate click, timeout, subscription-card change, and dispute notice. For each, ask what event is sent, what identifier is retained, who can act, and how the result is reconciled.
For an API integration, request answers on credentials, permission scopes, test accounts, version support, schemas, idempotency, webhook signatures, retries, event ordering, constraints, and deprecation notices. “REST API available” says little about safe implementation. Test normal and exception paths, expected merchant records, and discrepancy handling. Sandbox behavior does not prove a production configuration will be approved or enabled.
Ask about hosted pages or fields, direct collection, mobile SDKs, terminals, wallets, and payment links only when in scope. Compare the proposed design’s effects on checkout control, data exposure, deployment, accessibility, support, and contingencies—not the largest feature catalog. Confirm that web pages, apps, and processes match the stated integration option.
For e-commerce cards, include authentication rather than treating 3-D Secure as a box to check. EMV 3-D Secure enables merchant–issuer exchange of transaction, payment-method, and device information; an issuer may require extra authentication for a higher-risk transaction. 3
Ask which EMV 3DS version and components are used, supplied merchant data, challenge presentation, returned outcomes and identifiers, monitoring, and configuration ownership. Issuer decisions, network rules, and local requirements vary, so no answer promises authorization, fraud, or dispute results.
A high-risk merchant should clarify who creates and changes risk rules, how changes are logged, what data is visible, which manual-review steps exist, and what occurs when a transaction is held or rejected. Distinguish built-in controls from optional products, third-party services, and merchant configurations. Test a legitimate customer, suspicious pattern, refund, and dispute record. The aim is operational ownership, not a claim that a tool eliminates fraud or chargebacks.
Compare Operations, Reporting, and Support Before Commercial Terms
Proposals may diverge when the merchant refunds, investigates an order, responds to a dispute, or matches deposits to its ledger. Build the operations scorecard before the commercial worksheet. Ask providers to define authorization, capture, clearing, settlement, funding, payout, reserve, refund, reversal, void, and adjustment, then identify records, identifiers, delivery methods, and owners. Similar terms may refer to different events.
Treat reconciliation separately. Give finance’s needed fields: merchant account, order and payment identifiers, authorization, capture and refund references, applicable network or dispute references, date and time, currency, gross amount, fees, net amount, settlement date, and payout identifier. Request a sample file, schedule, retention, corrections process, and adjustment treatment. The records must connect to order and accounting systems.
Evaluate disputes as a workflow, not a promised outcome. Visa’s merchant library publishes dispute-management guidance alongside authorization, security, and fraud material. 4 Ask where notices appear, how deadlines are communicated, what evidence can be uploaded or exported, available research data, controlled access, and escalation when records are missing.
The merchant remains responsible for its own communications, fulfillment records, and response choices; network rules and acquirer procedures may change.
Ask about the severity model rather than “24/7 support.” Request channels, business and language coverage, incident classification, acknowledgement and update targets, escalation roles, maintenance notices, status communications, and the process for a security concern or transaction anomaly. Record included and optional support as a service model to evaluate—not an assurance of uninterrupted availability or guaranteed resolution.
For a replacement processor, transition evidence matters as much as features. Ask about implementation prerequisites, configuration ownership, test stages, cutover dependencies, rollback decisions, reporting overlap, exports, token or credential migration conditions, and closure procedures. The Processor Switching Guide: The 2026 Migration Playbook offers related context. Any migration plan remains subject to agreements, technical validation, and applicable network or provider requirements.
Normalize the Commercial and Contractual Comparison
Compare commercial terms only after services are fully described. Do not rank proposals on a headline percentage, one “effective rate,” or a different transaction mix. Require the same commercial schedule and definition for every line item: transactional, fixed, one-time, gateway, fraud-tool, payment-method, currency-related, reporting, support, reserve, chargeback, retrieval, termination, and transition charges. Request transparent inputs, not a promise that future volume, mix, or fees will remain unchanged.
Provide an accurate representative transaction mix and label it an estimate. Separate card-present and card-not-present activity, values, currencies, refunds, recurring activity, and relevant non-card methods. Ask which assumptions change the response. A worksheet can calculate scenarios but is not a guaranteed cost or savings figure. Maintain an assumption log so decision-makers see whether a low model depends on omissions, a different settlement schedule, or an unconfirmed classification.
Contract review should focus on material operations. Identify agreement documents, incorporated rules, change notices, term and renewal, termination, reserves and funding, data access and retention, confidentiality, security contacts, evidence rights, dispute support, subcontracting, and transition obligations. Ensure the RFP, proposal, implementation plan, and contract do not describe different services. The Negotiating Processing Rates: The 2026 Merchant Playbook is related context; obtain appropriate professional advice on a specific agreement.
It is reasonable to request a written statement of material assumptions and exclusions. It is not reasonable to treat a sales response as a substitute for the final agreement, payment-network rules, security standards, or a provider’s risk review. If a respondent cannot answer a key question until later diligence, record the dependency, owner, expected evidence, and decision impact. A transparent unresolved item is more useful than a confident but ambiguous answer.
Score Evidence, Run Diligence, and Make a Defensible Choice
A scorecard should preserve judgment, not disguise it. Set weights before opening responses. One merchant may weight integration and reconciliation; another may prioritize a payment method, settlement design, or support. High-risk businesses often need weight for documented business-model fit and realistic ongoing evidence and operations. No universal weighting scheme is correct.
Use a scale such as 0 for not evidenced or unsupported, 1 for partial or conditional support, 2 for documented support, and “not applicable.” Separate score from confidence. A demonstrated answer with an implementation owner differs from a slide-deck claim. Record assumptions, evidence, follow-up questions, and the effect of unanswered issues on launch or operations.
Diligence should verify claims that materially change the decision: a technical workshop, administration and reporting demo, sample settlement and dispute files, data-flow walkthrough, relevant third-party documentation, and the expected transaction mix. PCI SSC says third-party review should consider the service and access to the cardholder data environment, and suggests review as changes occur and annually. 2 Depth and cadence depend on the service and risk assessment.
Before selection, write a decision memo naming the selected arrangement, alternatives, criteria, evidence, unresolved dependencies, implementation prerequisites, and approval owners. Include a “no-go” list: an untested integration, missing reconciliation field, unclear data responsibility, or unconfirmed contract term. This is not a compliance certification; it records the choice and remaining validation.
The RFP remains useful after selection. Convert commitments and assumptions into an implementation checklist, governance calendar, contact list, and change-control record. Revisit it when channels, fulfillment, recurring billing, geography, payment-data architecture, or transaction patterns change. A living record prompts a provider conversation instead of assuming the original configuration still fits.
Maintain a controlled question log throughout evaluation. For each material question, record the provider’s answer, source or demonstration, internal reviewer, follow-up action, date, and whether the answer is reflected in the proposed implementation or agreement. Distinguish a provider’s standard capability from a configuration that must be enabled, a custom development request, or a service that needs third-party participation. This discipline helps prevent a decision team from treating an informal meeting statement as an operating commitment. It also gives the implementation team a compact handoff of the assumptions that need confirmation during design, testing, and launch planning. When a response changes, preserve the earlier answer and record why the assessment changed; otherwise, teams can lose sight of dependencies that were material to the original selection.
Use a final review meeting to challenge the scorecard rather than merely ratify it. Ask whether a high score depends on evidence that was never tested, whether an unresolved point has a credible owner and deadline, and whether the selected arrangement creates a dependency that internal teams cannot operate. The decision can be deferred or conditioned on evidence if those questions cannot be answered. A clear conditional decision is more informative than a completed scorecard that conceals uncertainty.
Frequently Asked Questions
What should a payment processor RFP template include?
A payment processor RFP template should include the merchant profile, payment flows, channels and transaction types, integration and security questions, operations and reporting, authentication and risk tools, a commercial schedule, contract and transition questions, and a scorecard. Ask each provider for assumptions, exclusions, dependencies, and evidence. Tailor it to the business model; preliminary responses are not final approval, pricing, or a contractual commitment.
How do high-risk businesses compare payment processors fairly?
High-risk businesses should give each provider the same facts about products, fulfillment, customer policies, channels, transaction mix, available history, and planned changes. Score documented fit, integration, payment-data responsibilities, reporting, disputes, support, commercial definitions, and contract dependencies separately. Because providers may need additional diligence and requirements vary, record open conditions instead of assuming a proposal establishes approval or processing outcomes.
What evidence should merchants request from payment processor candidates?
Request decision-appropriate evidence: product documentation, data-flow diagrams, sample reconciliation and dispute records, implementation plans, relevant security or third-party materials, support procedures, and a commercial schedule. Ask which services, systems, and assumptions are covered. Internal owners should review evidence; it does not replace contract review, merchant validation obligations, or provider diligence.
