Merchant Services RFP Checklist for Multi-Location Businesses: What to Ask Before You Sign

Two processors can both quote “interchange-plus” and still produce dramatically different total costs, funding behavior, reporting quality, hardware commitments, support outcomes, and implementation risk. If the RFP does not require standardized answers, the merchant ends up comparing marketing language instead of comparable proposals.

That problem becomes more serious for a multi-location retailer, restaurant group, franchise system, or service business. One provider may assume a single merchant ID and central bank account, while another assumes individual MIDs and location-level deposits. 

One may quote processing markup without gateway charges, hardware support, or implementation costs. Another may describe “next-day funding” without defining batch cutoff rules, weekends, exceptions, or whether deposits are gross or net.

A useful merchant services RFP therefore does not ask, “What rate can you give us?” It defines the merchant’s transaction mix, locations, systems, funding needs, hardware, support expectations, implementation scope, reporting requirements, security responsibilities, and contract terms so every provider answers the same questions in the same format.

The procurement process should follow a disciplined sequence:

Merchant Profile → Standardized Requirements → Provider Response → Normalized Pricing → Operational Review → Technical Validation → Proof of Concept → Risk Review → Contract Review → Selection

The objective is not to find the processor with the lowest advertised number. It is to identify the proposal that best fits the merchant’s actual transaction environment while exposing costs, dependencies, technical gaps, operational risks, and contractual obligations before signature.

What Is a Merchant Services RFP?

A merchant services RFP is a structured request for proposal used to obtain comparable responses from prospective processors, acquirers, gateways, payment technology providers, or integrated payment partners. 

It specifies the merchant’s business environment and asks each bidder to respond to the same pricing, technical, settlement, security, implementation, support, and contractual requirements.

That makes an RFP substantially different from an informal quote request. A quote may show a percentage markup, transaction charge, and monthly fee. 

A well-designed payment processor RFP asks what those numbers apply to, what is excluded, how fees are assessed, how transactions are settled, what systems are required, what the implementation entails, and what happens if the merchant later leaves.

An RFP is also different from a processor sales proposal. The merchant controls the structure of the RFP; the vendor normally controls the structure of a sales proposal. Standardizing the response format prevents providers from emphasizing favorable features while leaving difficult comparisons buried in footnotes.

It is also different from a POS vendor RFP. A POS RFP may focus on inventory, employee management, ordering, customer management, or restaurant operations. 

A merchant acquiring RFP concentrates on payment acceptance, processing, gateway connectivity, merchant accounts, settlement, reporting, devices, security, and related contractual responsibilities. When the systems are integrated, however, each RFP must acknowledge the dependencies between them.

For additional background on evaluating providers, the discussion of choosing a merchant services provider for the business model is useful alongside a more formal procurement exercise.

Why Multi-Location Merchants Need a More Detailed RFP

Multi-location payment environments contain relationships that rarely exist at the same scale for a single-location merchant. A business may have 40 stores, three legal entities, 42 MIDs, multiple ecommerce channels, several settlement accounts, different POS versions, and locations operating across multiple time zones.

One proposal might consolidate those businesses under a reporting hierarchy without changing the ownership of individual merchant accounts. Another might require a different architecture entirely. These differences can materially affect underwriting, funding, accounting, chargebacks, user permissions, integrations, and reconciliation.

A multi-location RFP should therefore describe variables such as:

• Corporate-owned versus independently owned locations.
• Legal entities and tax structures.
• Existing MIDs and desired future MID structure.
• Location-level and channel-level processing volume.
• Card-present, ecommerce, mobile, and recurring-payment channels.
• POS and gateway integrations.
• Different device fleets or connectivity environments.
• Settlement accounts by business entity or location.
• Centralized versus decentralized finance operations.
• Corporate reporting and regional access requirements.
• Implementation waves and store-opening schedules.
• Help-desk responsibilities and after-hours support.
• Reconciliation from POS sales through bank deposit.

Terminology also matters. A processor performs transaction-processing functions. An acquirer has the acquiring relationship within the card-payment ecosystem. 

A merchant account is the commercial arrangement through which the merchant accepts card payments, while a MID identifies a merchant or merchant-account relationship in the relevant processing environment. Store IDs and terminal IDs are operational identifiers and should not automatically be treated as MIDs.

Similarly, the payment gateway transmits payment information between systems, while the POS platform manages broader checkout or business functions. A hardware device is the terminal or other acceptance equipment. 

Visa’s materials distinguish authorization from capture and clearing/settlement: approval of an authorization does not by itself complete the later transaction lifecycle.

That distinction becomes especially important when designing proof-of-concept testing.

Define the RFP Objectives Before Sending It

Before writing technical questions, the merchant should define what the procurement exercise is intended to accomplish. Without explicit objectives, committees can spend weeks scoring features that do not address the business problem that triggered the RFP.

Typical objectives may include reducing controllable processing expense, improving authorization performance, standardizing payment acceptance across locations, replacing aging terminals, modernizing the gateway, improving reconciliation, simplifying corporate reporting, strengthening support, supporting expansion, or reducing dependence on proprietary technology.

Objectives should be measurable where possible, but they should not predetermine which vendor wins. For example, “provide location-level settlement reporting containing batch and deposit identifiers” is more useful than “select Provider X because its reports look better.”

Procurement teams should establish evaluation criteria and scorecards before bids arrive. Formal procurement guidance similarly emphasizes defining requirements and evaluation criteria before proposal review rather than allowing vendor presentations to reshape the competition afterward. 

Rutgers University Procurement Services, for example, identifies scope development, evaluation criteria, focus-team creation, schedules, and scorecard development as pre-bid activities.

The RFP should also tell bidders which objectives are mandatory and which are preferred. That prevents a strong marketing presentation from compensating for failure on a requirement that finance, IT, or operations actually considers non-negotiable.

Build a Complete Merchant Profile

The merchant profile gives bidders the context needed to design a realistic payment architecture and commercial proposal. Incomplete profiles create assumptions, and different assumptions create proposals that cannot be compared fairly.

The opening section should describe the merchant’s industry, business model, number of locations, ownership structure, current acquiring relationship, existing processor, gateway, POS environment, ecommerce channels, mobile-payment use, recurring payments, expected growth, and desired implementation outcome.

The merchant does not need to expose unnecessary confidential information in the general RFP. Sensitive data can be provided through controlled due-diligence channels or a secure data room after appropriate confidentiality protections are in place.

At minimum, the profile should establish:

• Business type and major sales channels.
• Number of active and planned locations.
• Number of legal entities.
• Corporate-owned versus independently owned units.
• Current POS platform and relevant versions.
• Current gateways and ecommerce platforms.
• Current payment hardware.
• Number of MIDs or merchant-account relationships.
• Recurring or card-on-file programs.
• B2B or commercial-card requirements.
• Current centralized or decentralized support model.
• Desired implementation date or business milestone.
• Anticipated openings, acquisitions, or closures.

If recent processing statements will be shared, redact information that is unnecessary for pricing analysis and use an appropriately controlled delivery method. Statements can help bidders understand transaction mix and fee structure, but they should supplement—not replace—the standardized data workbook.

What Transaction and Location Data Should the RFP Include?

Transaction and location data are the foundation of a credible credit card processing RFP. Providers cannot model pricing, routing, hardware, underwriting, settlement, or technical requirements accurately when they are given only annual sales volume.

Transaction Data Providers Need to Price and Design the Solution

The RFP should provide enough historical data to represent the merchant’s actual environment. 

Useful fields include annual card volume, monthly processing volume, transaction count, average ticket, card-present and card-not-present percentages, ecommerce share, keyed/manual share where meaningful, debit and credit mix when available, commercial-card activity, refunds, chargebacks, recurring payments, international-card activity, and seasonal or daily peaks.

For example:

Metric	Current Volume	Notes
Annual card volume	Merchant supplied	Define period
Monthly transactions	Merchant supplied	Include seasonality
Average ticket	Merchant supplied	Consider channel differences
Card-present share	Merchant supplied	Define methodology
Card-not-present share	Merchant supplied	Separate ecommerce where possible
Refund rate	Merchant supplied	State denominator
Recurring volume	Merchant supplied	Identify stored-credential program

Avoid invented benchmarks. The purpose is to give every provider the same dataset, not to compare the merchant against an arbitrary “industry average.”

Transaction mix matters because a high-ticket B2B location can have different costs and capabilities from a high-volume quick-service restaurant even if the two locations process the same annual dollar volume. 

Ticket size affects the significance of per-transaction fees; ecommerce requirements can add gateway or security considerations; commercial cards may affect data requirements; and recurring payments may introduce tokenization, account-updater, and credential-storage questions.

Location Data Needed for Multi-Location Merchant Services

Location information should be supplied in a separate structured workbook. Each row should represent a store, operating unit, or processing environment and identify how that location relates to the legal and payment hierarchy.

Useful columns include:

Location	Legal Entity	Monthly Volume	Avg. Ticket	Current MID	POS	Hardware	Bank/Funding Model
Location ID	Entity ID	Merchant supplied	Merchant supplied	Masked	Platform/version	Device type	Separate/central

Additional fields may include business address, tax jurisdiction, internet/connectivity type, business hours, current gateway, implementation priority, channel mix, number of lanes, number of devices, and unusual operating characteristics such as late-night closing.

Sensitive identifiers should be masked where full values are unnecessary.

The RFP must explicitly distinguish corporate stores, subsidiaries, franchisees, and other independently underwritten legal entities. A corporate reporting relationship does not automatically mean all locations should share the same merchant account or settlement structure.

Define Merchant Account and MID Requirements

A multi-location merchant account setup should be designed around legal ownership, settlement requirements, processing channels, reporting, and acquiring requirements rather than around an arbitrary rule such as “one MID per store.”

The RFP should ask each provider to map its proposed architecture to a conceptual hierarchy:

Corporate → Legal Entity → Location → MID → Terminal/Channel

Providers should identify where their design differs and why.

The merchant should state whether it needs separate settlement accounts, location-level deposits, multiple MIDs for ecommerce versus card-present activity, or separate merchant accounts for distinct legal entities. 

It should also ask how new locations are boarded, what underwriting information is required, how IDs are assigned, and how closed locations are removed from corporate reporting.

Each provider should answer:

• Who is the actual acquirer?
• Who performs processing functions?
• Which entity signs the merchant agreement?
• How many merchant accounts and MIDs are proposed?
• Can separate legal entities remain separately underwritten?
• Can corporate users see aggregated reporting without commingling settlement?
• Can locations settle to different bank accounts?
• Can channels be assigned separate MIDs where required?
• How are new locations provisioned?
• How are store, terminal, and MID identifiers mapped in reports?

Federal Reserve material describing merchant acquiring notes that acquiring banks and processing service providers can perform distinct roles, which is another reason an RFP should identify the organizations actually performing each function rather than using “processor” for every party.

Standardize the Pricing Response

Pricing is one of the strongest reasons to use an RFP, yet it is often the least standardized part of the process. If Provider A quotes interchange-plus markup, Provider B quotes a bundled percentage, and Provider C excludes gateway and platform charges from its payment proposal, headline comparisons are nearly meaningless.

Require all bidders to populate the same merchant services fee comparison workbook.

Separate Interchange, Assessments, and Processor-Controlled Charges

Where the pricing model allows it, require the proposal to distinguish pass-through interchange, card-network assessments or related network charges, and processor-controlled markup.

For interchange-plus proposals, request the percentage markup and per-transaction markup separately. Ask bidders to identify authorization charges, settlement charges, account fees, gateway charges, and other processor-controlled components.

If a provider proposes a flat-rate or bundled structure, the merchant can still evaluate it—but the pricing model should be labeled accurately rather than treated as interchange-plus.

The goal is not to force every vendor into the same pricing model. It is to force every vendor to disclose enough detail that finance can calculate total projected cost using the same transactions.

Understanding the different categories of merchant services fees and pricing models can also help procurement teams build a response template that separates transaction pricing from recurring and incidental charges.

Require Every One-Time, Recurring, and Event-Based Fee

The processor proposal checklist should require three distinct fee categories.

One-time fees may include:

• Merchant or location setup.
• Implementation.
• Hardware purchase.
• Device configuration or staging.
• Shipping.
• Integration.
• Data migration.
• Token or vault migration.
• Training.
• Professional services.
• Onsite installation or travel.

Recurring fees may include:

• Monthly merchant-account fee.
• Gateway fee.
• Statement or reporting fee.
• PCI-related fee.
• Software subscription.
• Device-management fee.
• Support fee.
• Platform fee.
• Account minimum.
• Recurring hardware-related charges.

Event-based fees may include:

• Chargebacks.
• Retrievals or dispute services.
• Refund processing.
• Voice authorization.
• Batch-related charges.
• AVS or gateway transaction services where applicable.
• International or cross-border charges where applicable.
• ACH returns if ACH processing is included.

The fee schedule should use a mandatory format:

Fee Category	Fee Name	One-Time / Recurring / Event	Amount or Formula	Waivable?	Notes
Processing	Provider markup	Recurring usage	Provider fills	Yes/No	Define basis
Gateway	Gateway fee	Recurring	Provider fills	Yes/No	Per MID/location?
Hardware	Device	One-time/recurring	Provider fills	Yes/No	Purchase/lease
Disputes	Chargeback	Event	Provider fills	Yes/No	Describe related fees

Require bidders to enter $0, included, or not applicable instead of leaving a blank cell. Add a final question: “List every charge, fee, expense, assessment, minimum, surcharge, or pass-through item not already disclosed above.”

The internal guide on negotiating contracts with processors, ISOs, and hardware suppliers similarly emphasizes examining service levels, fees, responsibilities, and supplier terms rather than negotiating price alone.

Normalize Effective Cost Before Comparing Providers

Once proposals arrive, finance should apply each pricing model to the same historical transaction profile.

A useful modeling structure is:

Projected Annual Cost = Interchange + Assessments + Processor Markup + Per-Transaction Fees + Monthly Fees + Gateway + Hardware/Software + Expected Event Fees

Procurement teams can also review common approaches to payment processing cost optimization when deciding which gateway charges, PCI-related costs, monthly fees, and transaction-level expenses should be included in the comparison model.

This is a cost model, not a promise that future costs will equal the historical projection. Interchange mix, card mix, transaction counts, channel mix, network charges, refunds, disputes, and business volume can change.

Scenario modeling can reveal differences that a single blended estimate hides. Run the proposals against representative environments such as:

• A low-ticket, high-transaction-count store.
• A high-ticket, low-transaction-count service location.
• An ecommerce-heavy business unit.
• A B2B location accepting commercial cards.

Request sample merchant statements from each provider showing how the proposed fees would actually appear. That allows accounting staff to evaluate whether invoices contain enough detail to verify the pricing agreement after launch.

The RFP should also require providers to identify which charges they control contractually and which are pass-through components. A provider generally cannot credibly promise that an overall effective processing rate will never change when the merchant’s card mix, transaction mix, or external network pricing can change.

Make Funding and Batch Requirements Explicit

“Fast funding” is not a sufficient requirement. A multi-location payment processor should be required to explain exactly how submitted transactions move from batch to settlement and from settlement to merchant deposit.

The merchant should document its preferred settlement-account structure and ask the bidder to confirm supported options.

Funding Requirements to Put in the RFP

Funding questions should cover:

• Bank account by legal entity and/or location.
• Provider-supported funding cadence.
• Gross versus net funding.
• Treatment of processing fees.
• Treatment of refunds and chargebacks.
• Reserve or hold procedures where applicable.
• Funding cutoff dependencies.
• Weekend and banking-holiday treatment.
• Handling of bank-account changes.
• Availability and conditions of accelerated funding services, if offered.
• Deposit-level reporting.
• Treatment of multiple batches in one deposit.
• Procedures for delayed or rejected deposits.

Do not write a universal “next-day funding” requirement without defining what it means. Ask every provider to document its own eligibility conditions, cutoff dependencies, bank-processing dependencies, exceptions, and contractual language.

Gross-versus-net funding also needs definition. Ask whether fees are taken from each deposit or billed periodically, whether chargebacks and adjustments reduce the deposit, and whether several store batches may be combined into one bank entry.

Batch and Settlement Requirements

Businesses should specify how batches need to behave instead of allowing a provider to apply its default configuration without review.

Important requirements include automatic or manual close, location-specific cutoff rules, multiple batches per day, tip-adjustment windows for applicable businesses, late-night business-date handling, and identifiers that accounting can use for reconciliation.

Requirement	Merchant Requirement	Provider Response
Auto close	Define	Provider fills
Batch cutoff	By location/time zone	Provider fills
Multiple batches/day	Required/optional	Provider fills
Business-date handling	Define	Provider fills
Batch identifier	Required	Provider fills
Settlement identifier	Required	Provider fills
Deposit reference	Required	Provider fills

The lifecycle matters because authorization and final settlement are not identical events. Visa’s acceptance documentation explicitly separates an authorization request from the later capture step that initiates clearing and settlement.

For a useful overview of transaction stages, see the lifecycle of a credit-card transaction.

Specify Gateway, Token, POS, and Ecommerce Requirements

A payment gateway RFP should not consist of a checkbox labeled “gateway included.” The merchant needs to know whether the gateway is proprietary, processor-agnostic, integrated into the POS, capable of supporting existing tokens, and usable if the acquiring relationship changes.

Required gateway questions may cover APIs, webhooks, tokenization, stored credentials, recurring billing, ecommerce, 3-D Secure where relevant, Level 2/3 support where needed, data exports, reconciliation fields, and documentation.

A proprietary gateway may provide tight integration but can create additional migration dependencies. A processor-agnostic gateway may provide more flexibility, but architecture, certifications, feature parity, pricing, and support responsibilities still need evaluation.

Token questions should be particularly specific:

• Who operates the token vault?
• What type of token is used?
• Is the token usable only within the current gateway or processor?
• Are network tokens supported?
• Can stored PANs be exported through a PCI-compliant migration process where permitted?
• Can tokens themselves be migrated?
• What migration services and fees apply?
• What data is available after termination?
• How long is reporting access retained?

Do not assume “tokenized” means “portable.”

POS integration requirements should name the POS platform and version, certified integrations, refund handling, multi-MID routing, location mapping, tender behavior, tip handling where applicable, offline functionality where supported, and responsibility for maintaining compatibility after software updates.

For ecommerce, the merchant may also require hosted checkout options, tokenization, AVS, appropriate CVV handling, wallets, recurring billing, idempotency, webhook retries, fraud tools, sandbox access, and documented error handling.

For B2B operations, request support for relevant Level 2/3 information, commercial cards, invoice payments, ACH if needed, virtual cards, and remittance data.

Write Hardware Requirements as Operational Requirements

Payment hardware should be evaluated as a lifecycle rather than simply as a purchase price.

A strong payment hardware requirements section asks bidders to identify supported and certified devices, EMV/contact capability, contactless acceptance, PIN debit support where relevant, mobile-wallet compatibility, accessibility considerations, device management, remote updates, warranties, replacement procedures, spare-device strategy, and end-of-life policies.

Use a standard response table:

Device	Purchase Price	Lease?	Warranty	Replacement SLA	Software/Management Fee
Provider fills	Provider fills	Yes/No	Provider fills	Provider fills	Provider fills

Require providers to specify whether devices are purchased, rented, provided under another arrangement, or subject to a separate equipment contract.

Long equipment leases deserve particular scrutiny. Finance should calculate the total contractual equipment cost, early-exit obligations, replacement responsibilities, ownership at termination, software dependencies, and whether canceling processing services leaves a separate equipment obligation in place.

The RFP should also ask who stages devices, loads configuration, maps terminal IDs, ships hardware, maintains spare inventory, performs firmware updates, and supports device replacement.

Make Reporting and Reconciliation Testable

A provider should not receive full reporting credit merely for saying “real-time dashboard included.” Finance needs fields, hierarchy, export formats, retention periods, and reconciliation logic.

For a multi-location merchant, useful reporting requirements may include:

• Corporate roll-up.
• Region and location views.
• MID-level activity.
• Terminal or channel reporting.
• Authorization reporting.
• Batch reporting.
• Refunds.
• Chargebacks.
• Fees.
• Adjustments.
• Settlement.
• Deposit information.
• Downloadable files.
• API access.
• Role-based user permissions.

A conceptual corporate hierarchy might be:

Corporate View → Region → Location → MID

The RFP should ask how users are restricted so regional managers can see permitted locations while finance can see enterprise-wide settlement and pricing data.

Most importantly, require bidders to demonstrate how accounting can follow:

POS → Batch → Settlement → Deposit → Bank

Useful reconciliation fields include location ID, MID, batch ID, settlement ID, funding ID, gross amount, refunds, fees, chargebacks or adjustments, expected funding amount, actual deposit amount, and bank reference.

Ask providers for an actual sample settlement report. The sample should show enough detail for accounting to understand how a $50,000 gross batch could become a different bank deposit because of refunds, fees, adjustments, or netting.

A reporting demonstration should also include exports rather than only dashboard screenshots. Determine whether transaction and settlement data can be exported at scale and whether APIs have pagination, retention, authentication, or volume limitations that affect finance operations.

Turn Support Promises Into Measurable SLAs

“24/7 support” describes availability, not performance. A useful payment processor SLA defines incident severity, initial response, escalation, communication cadence, responsibilities, and the resolution objective or service-restoration objective proposed by the vendor.

Define Severity Before Asking for Times

The merchant can define business-impact categories while requiring each bidder to propose contractual service levels.

For example:

Severity 1: Payments unavailable across major locations or a similarly critical production outage.

Severity 2: Material payment degradation, significant multi-store impact, or failure of an important payment function.

Severity 3: Limited location, device, reporting, or individual-user issue with a workaround or limited operational effect.

The provider should complete:

Severity	Example	Initial Response	Escalation	Update Frequency	Resolution/Restoration Target
Sev 1	Major payment outage	Provider fills	Provider fills	Provider fills	Provider fills
Sev 2	Material degradation	Provider fills	Provider fills	Provider fills	Provider fills
Sev 3	Limited issue	Provider fills	Provider fills	Provider fills	Provider fills

Do not impose a supposedly universal industry response time. Ask the provider to propose the commitment, then determine whether the commitment satisfies the merchant’s operational risk tolerance.

Define Escalation and Ownership

A useful escalation path might resemble:

Store → Merchant Help Desk → Provider Support → Senior Operations/Processor → Executive Escalation

The actual structure should match the merchant’s operating model.

Ask whether the provider supplies a named account manager, implementation manager, technical escalation contact, round-the-clock support or network-operations coverage where applicable, and executive sponsor.

More importantly, define ownership when multiple vendors are involved:

Issue	Provider	Gateway	POS Vendor	Merchant IT	Acquirer
Terminal offline	Fill	Fill	Fill	Fill	Fill
Authorization failure	Fill	Fill	Fill	Fill	Fill
Settlement issue	Fill	Fill	Fill	Fill	Fill
API failure	Fill	Fill	Fill	Fill	Fill
Hardware replacement	Fill	Fill	Fill	Fill	Fill

Hardware support needs its own commitment. Ask whether advance replacement, expedited shipping, onsite service, merchant-held spares, or other arrangements are available and under what terms.

Document the Payment Processor Implementation Plan

A strong proposal should describe implementation as a project, not a promised launch date.

The payment processor implementation plan should identify a project manager, milestones, dependencies, responsibilities, testing, pilot locations, deployment waves, data or token migrations, hardware staging, user provisioning, cutover procedures, rollback procedures, reconciliation validation, and post-launch stabilization.

Require an Implementation RACI and Milestone Plan

A RACI-style table makes responsibility gaps visible:

Task	Merchant	Processor	POS/Gateway	Owner
MID setup	Define	Define	Define	Assigned
Hardware staging	Define	Define	Define	Assigned
Integration	Define	Define	Define	Assigned
Testing	Define	Define	Define	Assigned
Training	Define	Define	Define	Assigned
Cutover	Define	Define	Define	Assigned
Reconciliation	Define	Define	Define	Assigned

Do not accept only “implementation takes four to six weeks” or another generic estimate. Request milestone dates or durations, dependencies, merchant deliverables, underwriting prerequisites, integration dependencies, equipment lead times, and conditions that could delay the schedule.

For large estates, the provider should propose a rollout method with a pilot, wave size, regional sequence, readiness gates, stabilization windows, and rollback criteria.

Go/no-go criteria might require confirmation that MIDs are active, terminals are configured, gateway connectivity is validated, test transactions pass, reporting is verified, staff are trained, settlement mapping is confirmed, and support resources are ready.

Rollback planning should address terminal authorization failures, gateway failures, incorrect settlement mapping, critical POS integration issues, or other problems that would make continuation unsafe or operationally unacceptable.

Require Specific Training Commitments

Training should appear as a deliverable in the RFP and implementation statement of work rather than as an informal promise made during demonstrations.

Different teams require different instruction. Store associates may need basic transaction and device workflows. Managers may need refund, void, and escalation procedures. Finance teams need settlement and reconciliation reporting. 

System administrators need user administration, reporting configuration, and device-management knowledge. IT teams may need API, logging, webhook, authentication, or troubleshooting documentation.

Require bidders to populate a table such as:

Audience	Training Topic	Format	Duration	Materials	Included Cost?
Store staff	Transactions/devices	Provider fills	Provider fills	Provider fills	Yes/No
Managers	Exceptions/support	Provider fills	Provider fills	Provider fills	Yes/No
Finance	Settlement/reconciliation	Provider fills	Provider fills	Provider fills	Yes/No
IT/Admin	Platform/integration	Provider fills	Provider fills	Provider fills	Yes/No

Ask whether training includes live sessions, recorded sessions, quick-reference guides, train-the-trainer materials, sandbox environments, and post-launch refresher sessions.

All associated costs should be disclosed in the implementation pricing schedule, including travel, professional services, custom documentation, staging, installation, and additional training.

Make Proof-of-Concept Testing a Real Payment Test

A processor proof of concept should verify actual operational requirements before enterprise rollout. A demo is not a POC, and an approved $1 test authorization is not sufficient evidence that settlement, reporting, device operations, and support workflows will function correctly.

Define Representative POC Scope

Select at least one location or environment representative of the planned deployment. Depending on the merchant, testing may include:

• Card-present purchase.
• Contactless transaction.
• PIN debit where relevant.
• Refund.
• Void.
• Tip adjustment for applicable merchants.
• Split tender where applicable.
• Ecommerce transaction.
• Tokenization.
• Recurring transaction.
• Level 2/3 data where relevant.
• Batch close.
• Settlement report.
• Merchant bank deposit.
• Corporate reporting.
• API or webhook delivery.
• Hardware deployment.
• Controlled support ticket.

A standardized evidence table makes acceptance objective:

Test	Expected Result	Pass/Fail Criteria	Evidence
Authorization	Approved transaction correctly recorded	Defined	Log/report
Refund	Refund linked and reported correctly	Defined	Report
Batch close	Correct transactions included	Defined	Batch record
Settlement	Amount and IDs available	Defined	Settlement report
Deposit	Bank deposit matches expected funding	Defined	Bank/reconciliation evidence

A successful authorization is not enough. The POC should verify capture, batch, settlement, reporting, and deposit matching.

That point follows the actual payment lifecycle: authorization approval precedes later capture, clearing, and settlement processes.

Test Reporting, Support, Hardware, and APIs

Finance should verify location roll-ups, batch IDs, settlement identifiers, fee presentation, and exports. For an API-driven environment, test authentication, idempotency, webhooks, retries, error responses, and differences between sandbox and production behavior where the provider can demonstrate them.

Hardware testing should include configuration, deployment, firmware or software updates, peripheral compatibility, device management, and a replacement workflow.

A controlled noncritical support ticket can also reveal whether the ticket reaches the correct team, whether communication is understandable, whether ownership is retained, and whether escalation works as described.

Finally, the RFP should define what happens if the POC fails. Options may include remediation and retesting, delayed award, adjustment of rollout scope, or rejection if a mandatory requirement cannot be satisfied.

Include Security, PCI DSS, and Data-Portability Requirements

Security questionnaires should go beyond asking, “Are you PCI compliant?”

PCI DSS applies to entities that store, process, or transmit payment account data and to relevant environments that can affect payment security. 

PCI SSC also makes clear that outsourcing payment processing does not eliminate every merchant responsibility: merchants still need to understand shared responsibilities and ensure applicable third-party responsibilities are properly addressed.

For an official source, the PCI Security Standards Council merchant security guidance explains the operational and technical objectives of PCI DSS.

The RFP should request:

• PCI DSS responsibility allocation.
• Provider compliance evidence appropriate to the service.
• Explanation of how the proposed architecture affects merchant PCI scope.
• P2PE options where relevant.
• Tokenization.
• MFA for appropriate administrative access.
• Role-based access controls.
• Logging and audit trails.
• Secure remote-support practices.
• Vulnerability-management responsibilities.
• Incident-response procedures.
• Breach-notification obligations.
• Third-party dependencies.

An informative internal overview of payment security and PCI compliance can provide additional context, but final PCI scope and validation requirements should be confirmed with the appropriate compliance-accepting entities and qualified professionals. 

PCI SSC itself advises merchants to confirm applicable validation requirements with the organizations managing their compliance program.

Data ownership and exit rights should be handled in the same diligence process. Ask who owns or controls transaction history, reporting exports, customer vault data, processor/gateway tokens, and API records. 

Require the provider to describe PAN migration capability where permissible, token portability, post-termination reporting access, retention periods, migration procedures, and all export or professional-service fees.

Put Contract Requirements in the RFP Before Negotiation

The best technology proposal can still become a poor business decision if the contract contradicts the proposal. Contract questions therefore belong in the RFP rather than waiting until procurement has already selected a finalist.

Request disclosure of:

• Initial contract term.
• Renewal provisions.
• Notice requirements.
• Termination rights.
• Early termination charges.
• Minimum processing or revenue commitments.
• Fee-change rights.
• Hardware obligations.
• Data-portability rights.
• Implementation commitments.
• SLA remedies.
• Pricing commitments.
• Confidentiality and security terms.
• Audit or reporting rights where appropriate.

For early termination, ask the vendor to classify any obligation: fixed amount, liquidated-damages formula, remaining hardware balance, other formula, or not applicable. Do not assume one structure is standard.

Price-change language also requires precision. Ask which processor-controlled markups or recurring fees are fixed, which can change, what notice applies, and how external interchange or card-network changes are passed through.

Similarly, distinguish a guarantee of processor markup from a guarantee of the merchant’s entire effective rate. The latter can be affected by variables outside a processor’s direct control, including transaction and card mix.

For SLAs, ask whether recurring failures can trigger service credits, formal remediation, escalation, or negotiated termination rights.

Auto-renewal clauses and notice periods should be reviewed carefully under applicable contract law and any other rules governing the merchant’s circumstances. Legal counsel should review final provisions rather than relying on generalized assumptions about what renewal language is enforceable.

Standardize the Proposal Response and Scorecard

Every requirement should require one of four answers:

• Comply
• Partially Comply
• Does Not Comply
• Custom Development Required

The provider should then explain the answer and identify any dependency, cost, roadmap item, third-party product, or contractual limitation.

This structure is especially useful for technical features. A response such as “Yes, we support tokenization” reveals little. “Comply—gateway vault token; export requires PAN migration project and separate professional-services fee” is far more useful.

Require supporting evidence where it materially improves verification: sample statements, settlement reports, documentation, screenshots, architecture diagrams, hardware specifications, implementation schedules, or API references.

Scoring categories may include:

Category	Weight	Provider A	Provider B	Provider C
Pricing	Merchant sets
Funding	Merchant sets
Reporting	Merchant sets
Support	Merchant sets
Implementation	Merchant sets
Technology	Merchant sets
Contract	Merchant sets

No universal weighting is appropriate. A retailer replacing 2,000 terminals may weight hardware and implementation heavily, while an ecommerce company may prioritize API reliability, token portability, and authorization performance.

Pricing should be normalized before scoring. If different bidders calculate savings from different assumptions, the comparison is not reliable.

Conduct Finalist Due Diligence Before Award

Finalists should be asked to demonstrate the areas most difficult to validate from written proposals.

Request sample statements, settlement reports, chargeback workflows, reporting exports, device-management demonstrations, and technical architecture workshops.

A sample settlement report should show gross activity, refunds, adjustments or fees where applicable, net funding, batch identifiers, and deposit references. A dispute demonstration should explain how chargebacks are received, documented, submitted, tracked, and reported.

References can also be useful when they resemble the merchant’s operating environment. Ask for clients with comparable location count, POS complexity, transaction scale, or rollout requirements. References are supporting evidence, not proof that the merchant will receive identical results.

High-level operational due diligence may also examine the provider’s support structure, acquiring/sponsor relationships relevant to the proposal, hardware roadmap, system dependencies, and platform direction. Avoid drawing unsupported conclusions about a provider’s financial strength from marketing claims.

Complex deployments may justify technical workshops or site visits before award. These sessions can walk through a real store transaction, exception handling, reconciliation, network architecture, device operations, and incident escalation.

After scoring, finalists can be asked for a best-and-final offer using the same assumptions and commercial template. Negotiations may address pricing, hardware, implementation services, SLAs, portability, and termination terms while preserving a fair and documented evaluation process.

Make Contract-to-RFP Traceability Mandatory

A sales presentation is not an implementation agreement.

Anything important in the winning proposal should appear in the final contract, order form, SLA, pricing schedule, security addendum, or implementation statement of work as appropriate.

Use a commitment matrix:

RFP Requirement	Provider Response	Contract/SOW Location	Verified?
Pricing markup	Proposal section	Pricing schedule	Yes/No
Funding configuration	Proposal section	Service terms/SOW	Yes/No
Support SLA	SLA response	SLA exhibit	Yes/No
Training	Implementation response	SOW	Yes/No
Data export	Technical response	Contract/data terms	Yes/No
Hardware replacement	Hardware response	SLA/order terms	Yes/No

This is where many procurement efforts fail. The winning provider may promise dedicated implementation resources, migration assistance, special pricing, or escalation support during evaluation, while the final agreement contains generic terms.

Traceability lets procurement ask a simple question before signature: Where is each material promise documented in an enforceable or operationally governing document?

The internal article on processor and supplier negotiations also stresses documenting terms, KPIs, responsibilities, and ongoing performance expectations rather than treating signature as the end of vendor management.

Common Merchant Services RFP Mistakes

The most common failure is asking only for processing rates. A competitive markup is valuable, but it cannot compensate for incompatible POS integrations, unusable settlement reports, expensive hardware obligations, weak escalation, or an implementation plan that does not account for the merchant’s location structure.

Another mistake is providing incomplete transaction data. Without channel mix, transaction count, ticket size, and location-level characteristics, providers may build pricing from assumptions that differ materially.

Other frequent mistakes include:

• Failing to disclose multiple legal entities.
• Assuming one MID structure fits every location.
• Ignoring gateway ownership.
• Omitting batch cutoff requirements.
• Failing to define gross versus net funding.
• Accepting “24/7 support” instead of measurable SLAs.
• Allowing blank fee fields.
• Ignoring professional-services and training charges.
• Treating hardware price as total hardware cost.
• Failing to define training deliverables.
• Skipping proof-of-concept testing.
• Testing authorization without testing settlement.
• Ignoring token and data portability.
• Comparing proposals built from different transaction assumptions.
• Failing to request sample statements.
• Relying on presentation promises that never reach the contract.
• Treating headline savings as the sole decision criterion.

The remedy is straightforward: structure the RFP around how payments actually operate from checkout through reconciliation and contract exit.

Merchant Services RFP Checklist

Before issuance, verify that the RFP addresses every material category:

Category	Requirement Included?
Business profile	☐
Location data	☐
Transaction data	☐
MID structure	☐
Pricing template	☐
Funding	☐
Batch requirements	☐
Gateway	☐
Hardware	☐
POS integration	☐
Reporting	☐
Reconciliation	☐
Security	☐
Support SLA	☐
Escalation	☐
Implementation	☐
Training	☐
Proof of concept	☐
Data portability	☐
Contract terms	☐
Scorecard	☐

The RFP should also require every bidder to answer a core set of operational questions:

Who is the actual acquirer and who performs processing? How will each legal entity and location be structured? How many MIDs are proposed? How is pricing calculated? Which charges are excluded from the headline rate? How are fees deducted? How are batches tied to settlements and deposits? Which identifiers are available for reconciliation?

It should ask which POS platforms and gateways are certified, which terminals are supported, how hardware replacement works, who controls stored-payment credentials, what can be exported at termination, how support escalation works, who manages implementation, what training is included, what can be tested before rollout, what happens when testing fails, and exactly what termination obligations remain if the merchant leaves.

Frequently Asked Questions

Conclusion

A strong merchant services RFP makes providers compete against the merchant’s real operating requirements rather than against one another’s sales presentations.

The RFP should describe the merchant’s businesses, locations, legal entities, transaction mix, MIDs, POS and gateway environment, hardware, funding needs, batch rules, reporting requirements, security responsibilities, support expectations, implementation constraints, training needs, proof-of-concept criteria, and contract requirements. It should then force every bidder to answer those requirements in a standardized format.

Pricing should be normalized against the same historical dataset. Funding promises should be tied to explicit cutoffs and settlement behavior. “24/7 support” should become a measurable SLA. 

Implementation should become milestones and responsibilities. A POC should follow transactions beyond authorization into capture, batch, settlement, reporting, deposit, and reconciliation.

Finally, the RFP process should not stop when a preferred provider is selected. The winning commitments must survive contract negotiation.

The most useful final question is therefore not simply, “Which provider scored highest?” It is:

“Can we trace every material pricing, operational, technical, support, implementation, security, portability, and contract commitment that influenced our decision into the documents we are actually signing?”

If the answer is yes, the merchant has transformed the RFP from a rate-shopping exercise into a meaningful payment-procurement control.

This article is for general procurement and payment-operations information and is not legal, accounting, security, tax, or financial advice. Merchants should validate proposed pricing, payment architecture, PCI DSS responsibilities, settlement arrangements, technical requirements, data-migration rights, SLAs, and contract provisions with qualified payment, finance, information-security, procurement, and legal professionals before signing an agreement.