Ecommerce Website RFP: What to Include Before You Ask for Bids

An ecommerce website RFP should cover ten things: your business and goals, catalog size and structure, payments, shipping and tax, what must migrate from the current store, how search rankings will be protected during the move, the platform question, integrations, security and PCI responsibilities, and how you will score the bids. Get those on paper and vendors can quote the same store. Leave them out and prices differ by a factor of five for reasons nobody can explain.

The ecommerce RFPs that go wrong usually fail the same way: they describe how the store should look and skip how it has to work. Looks are the cheap part. The expensive parts are a large catalog with variants, order history that must survive the move, tax across states, accounting that expects clean data, and years of Google rankings attached to URLs about to change. For the general shape of a web RFP (timeline, process, legal boilerplate), see the website design and development RFP guide; here we stay on what is specific to selling online.

What should the RFP say about the catalog?

Start with numbers: products, variants (sizes, colors, bundles), categories, and how fast the catalog grows. Say whether products have unusual attributes: configurable items, items sold by weight, subscriptions, digital downloads, B2B price lists, minimum order quantities. Each is a line item for a vendor.

Then describe how the catalog is managed today: a spreadsheet every Monday means an import path, an ERP means a sync. Attach a sample export of twenty products with every field so vendors see real data.

Which payment, shipping, and tax requirements belong in the RFP?

Payments. Name your current processor and whether you intend to keep it. List the methods you need: cards, PayPal, Apple Pay and Google Pay, buy now pay later, purchase orders for B2B accounts. These are engineering decisions and conversion decisions: in Baymard's research on US shoppers, 9 percent of those who abandoned a checkout said there were not enough payment methods, and 18 percent left because the site wanted them to create an account (Baymard Institute, cart abandonment research). Guest checkout should be a requirement.

Shipping. Describe how you ship today: carriers, flat or live rates, free shipping thresholds, local pickup, multiple warehouses, international. Name your fulfillment tools. Unexpected extra costs were the biggest reason for checkout abandonment in the same Baymard data (40 percent), so ask vendors how they will show shipping and tax early.

Tax. US sales tax is the quiet budget risk. If you sell into many states, you likely collect in several of them. State whether you use a tax service (Avalara, TaxJar, or the platform's engine) and what the vendor should configure. Ask who is responsible for tax rules being correct at launch; it is usually shared between you, your accountant, and the vendor.

What has to migrate from the current store?

This is the section most owners underestimate and most vendors under-quote. List everything:

• Products, with images, descriptions, variants, SKUs, and metafields.
• Customers, with addresses and marketing consent status. Saved card data generally cannot move; customers will re-enter cards.
• Orders, and how many years of history you need in the new store versus an archive. Order history drives returns and customer service.
• Reviews, gift cards, store credit, discount codes, and subscriptions, each with its own migration path or none.
• Content: blog posts, landing pages, size guides, policy pages.

For each item, say whether it must be in the new admin, visible to customers, or just exportable. Ask vendors how they migrate, how they validate counts, and what happens if the import fails on launch night. A test migration on a copy of your data, before the real cutover, is a reasonable requirement.

How do you protect search rankings during the move?

A replatform almost always changes URLs, and URLs are where rankings live. Google's guidance on site moves with URL changes says to map every old URL to its new destination, use permanent server-side redirects, avoid redirect chains, and keep redirects in place as long as possible, and it warns that Search visibility may fluctuate temporarily during a move (Google Search Central, site moves with URL changes).

Your RFP should therefore require, as named deliverables: a full URL inventory of the current site, a redirect map covering products, categories, and content, preserved page titles and meta descriptions, a check that product structured data still validates, and a post-launch monitoring period in Search Console. Ask who owns SEO on the vendor's side and whether they review the design before it is built. The full list is in our website redesign SEO checklist. Ask for the redirect map as a spreadsheet you keep; if you change vendors later, you will want it.

How should the RFP handle the platform question?

Either you have already chosen (Shopify, WooCommerce, BigCommerce, a headless or custom build) and the RFP says so, or you ask vendors to recommend one with reasons. What does not work is asking a Shopify agency and a custom shop to bid on the same vague brief and then wondering why one quote is six times the other.

If you are undecided, give vendors what they need to recommend well: catalog complexity, integration list, order volume, in-house technical capacity, and the monthly software budget you can live with. Ask each to state platform fees, transaction fees, and app subscriptions alongside the build price. The arguments for each side are in Shopify versus custom ecommerce; the RFP only needs to make vendors show their reasoning.

Which integrations should you list?

Every system the store touches, with direction and timing:

• Accounting (QuickBooks, Xero, NetSuite): orders, payouts, refunds, tax lines. Daily summary or every order?
• ERP or inventory: stock levels, product data, purchase orders.
• Email and SMS (Klaviyo, Mailchimp, HubSpot): customer sync, abandoned cart flows, order events.
• Shipping and fulfillment: labels, tracking numbers back to the order.
• Marketplaces and ad platforms: product feeds and conversion tracking.
• Customer service and reviews apps.

For each, ask whether the vendor will use a native app, a middleware tool, or custom code, and what it costs to run monthly. This list is often where the real price difference between platforms shows up.

Who is responsible for PCI and security?

Payment card security is governed by PCI DSS, and the rules changed recently. Requirements 6.4.3 and 11.6.1 of PCI DSS v4.0.1, which cover authorizing and monitoring the scripts on your payment page, became mandatory after March 31, 2025. For merchants on the simplest self-assessment path (SAQ A, payment fully outsourced to a provider), those two requirements were removed, but a new eligibility criterion was added: the merchant must confirm the site is not susceptible to script attacks that could affect the payment page (PCI Security Standards Council, e-commerce guidance).

In plain terms: hosted checkouts (Shopify Payments, Stripe Checkout, and similar) put most of the burden on the provider, while custom checkouts pull it onto you and your vendor. Ask vendors which SAQ they expect you to fall under, who completes it, how third-party scripts on checkout pages will be controlled, and how admin access, backups, and security updates are handled after launch. Require that all accounts (hosting, domain, payment, apps) are opened in your company's name.

How should you score the responses?

Decide the weights before bids arrive and publish them:

• Migration and SEO plan: 25 percent. Method, validation, redirect map, monitoring.
• Fit to catalog and operations: 20 percent. Did they engage with your product data and workflows?
• Platform reasoning and running costs: 15 percent. Total monthly cost, not just build price.
• Integrations: 15 percent. Each addressed with a method and a cost.
• Security and PCI responsibilities: 10 percent. Named, not waved at.
• Team, references, and price against scope: 15 percent. Two live stores you can shop on, two owners you can call.

Normalize scope before comparing price. If one bid includes five years of order history and another none, they are not competing bids yet. Then ask the top two vendors for a one-hour working session on their migration plan using your real data.

Premier Logic handles ecommerce builds and the SEO migration with the same team, and we end a free first call with a written recommendation on scope and platform whether or not you hire us. Demand the same from every vendor: a written reason for every recommendation.

Quick answers

How long should an ecommerce RFP be?

Five to eight pages plus attachments (sample product export, integration list, current traffic and order numbers). Spend the words on operations and migration, not design preferences, which can wait for the shortlist.

Should I pick the platform before writing the RFP?

Only if you have a clear reason. Otherwise describe your catalog, integrations, volume, and budget, and ask vendors to recommend a platform with running costs spelled out.

What is the biggest risk in an ecommerce replatform?

Losing organic traffic because redirects and page metadata were an afterthought, followed by broken data: duplicate customers, missing variants, orders that do not reconcile with accounting. Name both as deliverables.

Do I need to think about PCI if I use Shopify or Stripe?

Yes, but less. A hosted checkout keeps you on the simplest self-assessment path; a custom checkout puts script monitoring and more on you. Ask every vendor which SAQ they expect you to complete.

How many vendors should bid?

Four to six, mixing platform specialists and general development studios if you are undecided. Shortlist two for a working session on your real data.

Next step

If you are putting together an ecommerce RFP and want someone to read it before it goes out, or to help weigh the bids after, schedule a free call. Bring your catalog size, current platform, and the integrations you depend on. You will get a written recommendation from Premier Logic covering scope, platform, and the risks we would watch, whether or not we build the store. We count our work in hours given back to the business, and a tight RFP saves a lot of them.