Skip to main content

Back to Resource Center

5 BNPL RFP Questions Every Enterprise Merchant Should Ask

July 31, 2026

A group of professionals meeting to discuss creating an RFP for a new payments platform.


Share article

Pricing. Integrations. Uptime. Reporting.


These questions belong in any enterprise buy now, pay later (BNPL) request for proposal (RFP). But they rarely reveal the things that matter most once the program is live: 


  • Who carries repayment risk

  • Whether the provider expands customer reach

  • How BNPL appears throughout the customer journey

  • Whether it complements existing financing programs

  • How quickly your team can realistically launch


This is where a surface-level vendor comparison can leave important questions unanswered.


Before your team sends its next BNPL RFP, add these five questions to the evaluation. They will help Marketing, Ecommerce, Finance, Payments, Technology, and Operations teams pressure-test the provider behind the pitch.

1. What is your loss rate and who absorbs it?



Every BNPL provider will talk about pricing. Few will lead with repayment risk, loss-rate methodology, or merchant exposure.


This matters because the lowest-fee commercial model isn't always the right one for the business. Evaluate pricing alongside repayment-risk ownership, settlement structure, and what happens when a customer doesn't repay.


Ask providers directly:


  • What is your loss rate?

  • How is it calculated?

  • Who absorbs non-payment risk?

  • Is the merchant paid upfront?

  • What repayment exposure remains with the merchant?


A good answer will clearly define risk ownership, repayment responsibility, and settlement structure. No vague language. No hand-waving.


Finance should not have to guess who owns the risk. With Zip, merchants are paid in full upfront while Zip carries repayment risk. Their model is backed by a 1.86% loss rate, and 98%+ of transactions repaid in full.


This is the kind of detail Finance will want before final approval. Better to ask for it in the RFP than chase it down after commercial terms are already in motion.

2. What percentage of my addressable customers can actually use this?



Most BNPL providers will give you an approval rate, but few will tell you which customers that rate actually covers.


The better question is: approval rate against which population?


A high approval rate can look impressive when measured against a narrow customer group. But enterprise merchants need to understand whether a BNPL provider can help reach qualified shoppers who may be overlooked by traditional payment options.


Finance and Payments teams typically own the final assessment on this question because customer reach has to be evaluated alongside repayment performance, merchant risk, and long-term business value.


Ask providers directly:


  • How do you define the customer population behind your approval rate?

  • What audience is included in that calculation?

  • How do you evaluate addressable reach?

  • How do you support incremental customer opportunities?

  • How do you expand access without relying on narrow qualification claims?


This is where customer reach becomes more important than a headline percentage.


Over 119 million Americans are financially underestimated. For merchants, this points to a meaningful addressable audience beyond shoppers already well served by traditional payment options.


Keep the RFP focused on reach, responsibility, and incrementality. Avoid underwriting-specific language or questions about who is excluded. The goal is to understand whether the provider can responsibly expand access to qualified shoppers and support incremental customer opportunity.


Providers like Zip are designed to help merchants reach qualified shoppers who may not be fully served by traditional payment options, while maintaining strong repayment performance. That combination is what the Finance and Payments teams need to see before giving final approval.

3. Where will BNPL appear in the customer journey, and who owns the strategy?



A checkbox labeled “supports omnichannel” doesn't tell you much.


What matters is whether the provider can actually execute an omnichannel BNPL strategy, where BNPL will actually appear across the buying journey, and who is responsible for making those placements work.


Payment Experience (PX) is the strategy of placing payment options at the right moments across the customer journey, from product discovery to checkout and repeat purchase. A well-designed PX strategy makes these options easier to recognize and understand before the final checkout decision.


In most enterprise organizations, Marketing and Ecommerce teams own this strategy because they’re responsible for shaping the customer journey, driving adoption, and optimizing conversion across channels.


Ask providers directly:


  • Where will BNPL appear across the customer journey?

  • Who recommends placement strategy?

  • What assets, tools, or strategic support are provided after launch?

  • How do you support consistency across online, in-store, app, and recovery moments?

  • How do you help optimize placement over time?


Look for answers that include more than checkout. Check for guidance around product display pages (PDPs), cart, checkout, pre-qualification experiences, exit-intent moments, cart abandonment recovery, in-store signage, QR discovery, and app experiences.


Placement strategy matters because shoppers evaluate purchases long before the final step: while browsing, comparing, adding to cart, visiting a store, or returning after an abandoned session. A checkout-only placement may address one conversion moment, while a broader PX strategy supports more of the path from consideration to purchase.


This is the thinking behind Zip's Payment Experience (PX) framework, which helps merchants extend payment visibility across online, in-store, and app-based touchpoints throughout the customer journey.

4. How will this affect our existing financing programs?



Most BNPL RFPs are created by Marketing or Ecommerce, but many final approvals come from Finance & Payments.


That gap can create problems late in the process, especially for merchants with existing financing programs like Private Label Credit Cards (PLCCs), promotional financing, or store credit programs.


Finance will want to know whether BNPL creates incremental growth or simply shifts tender from one existing program to another. So ask that question before Finance asks it for you.


Ask providers directly:


  • How do you evaluate overlap with existing financing programs?

  • How do you measure incremental growth?

  • How do you help avoid simple tender shifting?

  • How does BNPL complement PLCCs, promotional financing, or store credit programs?

  • What should Finance review before final approval?


A strong provider answer should explain where BNPL adds value within the broader payment mix and how it supports incremental growth without simply shifting tender from one option to another. That gives Marketing a more defensible growth case and Finance a more concrete basis for evaluation.


This is one area where Zip can complement existing financing programs, giving merchants another flexible payment option while supporting incremental growth.

5. What does go-live actually require, and what happens if timelines slip?



Implementation should not be treated as a post-RFP detail.


Enterprise merchants often underestimate what it takes to launch a BNPL provider across channels, teams, and systems. That becomes especially risky when holiday readiness, internal resourcing, or a November code freeze is on the table.


Implementation planning is typically led by IT & Operations teams, which are responsible for integration, testing, security reviews, and launch readiness. 


Ask providers directly:


  • How much technical lift is required from our team?

  • What dependencies exist?

  • Who owns each decision?

  • Can online and in-store deployments move on different timelines?

  • What happens if timelines slip?


This does not need to become a full technical deep dive, but the RFP should make the real launch path visible.


Look for specifics around merchant-side requirements, point-of-sale (POS) considerations, platform compatibility, operational ownership, implementation support, and expected timelines. For in-store deployments, ask whether flexible payment options can be activated through app-based or virtual card experiences without requiring a full POS rebuild. If a provider says implementation is easy, ask what “easy” actually means for your team.


A fast launch matters when time is of the essence. With Zip, 55% of merchants go live within one month, and 70% go live within two months.


For enterprise merchants, that timeline detail matters. A BNPL provider may look good in a pitch, but if the launch plan misses peak selling windows, the business impact changes quickly. That gives merchants a practical benchmark for pressure-testing provider timelines before they choose a BNPL partner.

The 5-question BNPL RFP checklist



Before you send your next BNPL RFP, make sure it answers:


  • What is your loss rate, and who absorbs repayment risk?

  • What percentage of my addressable customers can actually use this?

  • Where will BNPL appear in the customer journey, and who owns the strategy?

  • How will this affect our existing financing programs?

  • What does go-live actually require, and what happens if timelines slip?


These five questions won’t cover every line item in an enterprise BNPL RFP, but they will help separate a surface-level vendor evaluation from one that holds up after launch.

To learn more about Zip and the BNPL RFP process, please reach out today to speak with a payments expert.



33Q FY26 results released to the ASX


4FY25 Annual Results released to the ASX


5National Population by Characteristics: 2020–2024,” U.S. Census Bureau, November 2024. Numbers are reflective of unlocked customer segments of underserved Americans and are not reflective of Zip’s customer base.


6Internal data analysis of transactions from July 2024 - June 2025, Source: first order vs contract signed date