ECom with Custom Quote & Variable Pricing

Traditional product-catalogue ECommerce sites have a simple pricing model;

product → cart → checkout

However in many industries like tour companies, catering services, or website design- there are too many variables for simple cart-based math. Instead there is is a quoting process where the customer changes settings, services, dates, and a calculator quotes the price to be charged.

configure → quote → pay

This is known as a custom quote solution.

Where Custom Quotes Add Complexity

• Dynamic pricing
• Dynamic order details

The System

Variable pricing solutions generally involves these parts;

Configurator (Webflow front-end)

A multi-step form where the customer picks event date and time, enters headcount, chooses delivery or pickup (with address if delivery), selects menu items with quantities, and provides contact info plus dietary/special instructions.

JavaScript calculates a running price based on your rules (weekday vs. weekend rate × headcount + per-item costs). This is purely for UX -- never trust the client-side-calculated price.

Lightweight backend (serverless function)

A small Cloudflare Worker, Vercel function, or AWS Lambda that:

• Receives the order payload from the form
• Recalculates the price server-side using the same rules. This is non-negotiable -- anyone with browser dev tools could otherwise rewrite the client price
• Creates a Stripe Checkout Session (or Invoice -- see below) with the calculated total
• Stores the full order detail somewhere (database, Airtable, email)
• Returns the Checkout URL to the front-end, which redirects the customer to pay

Payments layer (e.g. Stripe)

There are generally two reasonable patterns:

• Direct Checkout -- customer pays immediately. Simpler, but commits you to fulfilling without confirming availability.
• Quote → Invoice -- customer submits the configurator, you get notified, you confirm availability and any back-and-forth (dietary specifics, kitchen capacity), then send a Stripe Invoice for payment. Often the right fit for catering because of consultation, dietary follow-ups, and deposit/balance splits.

Databases (e.g. Airtable)

• Order database - stores orders, payment confirmation, dates, times, etc.
• Customer database - stores customers, and might support future login, if you build the customer portal separately

Important Considerations

Practical considerations

A few things to plan for upfront:

• Deposits. If you take a 50% deposit, charge that via Checkout and create a separate Invoice for the balance closer to the event. Stripe Quotes can model this natively.
• Lead time. Block out dates that are too soon. Validate the event date server-side too, not just in the form.
• Cancellations. Decide your refund window before going live -- Stripe makes refunds easy but the policy is yours to enforce.
• Taxes & GST. Stripe Tax can calculate some taxes automatically once configured, which is much cleaner than baking it into your price logic.
• Calendar conflicts. Capacity for businesses like tour companies and catering is finite. Either expose a real availability calendar in the configurator, or accept that you'll occasionally need to refund and follow up -- and pick the quote-first model accordingly.

Variable Pricing Solutions on Webflow

What does

You will almost certainly require custom coding for your pricing configurator- but

Stripe

Does Stripe have store capabilities?

Yes, but with an important nuance: Stripe is a payments and billing platform you plug into your product with a few lines of code. You accept cards, run subscriptions, send invoices, handle tax, and fight fraud from one dashboard. Flexprice It's payment infrastructure rather than a full storefront builder like Shopify, but it includes most of the commerce primitives you'd need:

• Stripe Checkout -- pre-built, hosted, conversion-optimized payment pages
• Payment Links -- shareable URLs for any product, no code required
• Stripe Billing -- subscriptions, invoicing, recurring plans, dunning
• Stripe Terminal -- in-person/POS if you ever need omnichannel
• Stripe supports credit and debit cards, Apple Pay, Google Pay, ACH, Klarna, Afterpay, and many local payment methods The Retail Exec, across 135+ currencies Foursets

So Stripe handles products, prices, carts, checkout, subscriptions, taxes, and fulfillment hooks -- but you bring the storefront (which is where Webflow comes in).

Does it allow variable pricing?

Yes, extensively. Stripe supports:

• Multiple prices per product (e.g. monthly vs. annual, different currencies, different tiers)
• Tiered/graduated pricing -- different rates at volume thresholds
• Volume pricing -- one rate that changes based on quantity
• Usage-based / metered billing -- charge by consumption (API calls, seats, GB, etc.)
• Customer-specific custom prices -- quote-style negotiated pricing
• Coupons, discounts, and promo codes
• Pay-what-you-want via the Checkout custom_unit_amount parameter

One caveat worth knowing: In February 2026, Stripe acquired Metronome, a usage-based billing platform built specifically because Stripe Billing couldn't handle real usage billing at scale. Flexprice So if you're doing complex high-volume metered billing, that capability is now part of Stripe but historically had limits -- for normal variable pricing (tiers, subscriptions, custom amounts), native Stripe Billing is fine.

Integration options into your Webflow site

There are essentially five paths, ordered from simplest to most powerful:

1. Webflow native Ecommerce + Stripe -- Webflow's built-in storefront uses Stripe under the hood. Requires a Webflow Ecommerce site plan. Once you've connected a payment gateway, you'll need to add an Ecommerce site plan and enable checkout before you can begin accepting payments. Webflow Help Center Best for selling physical/digital products with a normal cart.

2. Stripe Payment Links -- Create a link in Stripe and paste it onto a Webflow button Khod. Fastest possible setup, no Ecommerce plan needed, works on any paid Webflow plan. Good for one-time products, donations, event tickets.

3. Official Stripe App from the Webflow Marketplace (built by Flowout) -- Effortless Product Management: Create and manage your Stripe products right from Webflow... Payment Links: Create, manage and embed Payment Links directly in Webflow. Payment Collection: The easiest, fastest and most no-code way to collect payments from major credit cards, Apple Pay and local payment methods. Webflow No code, but more polished than raw Payment Links.

4. Stripe Checkout / Stripe Elements via Webflow Code Embed -- Stripe's embeddable components let you add payment functionality using Webflow's Code Embed element... These components handle PCI compliance, fraud detection, and payment method selection automatically. Webflow Requires a bit of JS but keeps customers on-brand.

5. Direct Stripe API (custom) -- Direct API integration enables custom pricing logic, advanced subscription management, marketplace payments, and deep CMS integration. This approach requires server-side code but offers complete control over payment experiences. Webflow Needed if you have dynamic pricing rules, gated content, complex subscriptions, or want to drive prices off your Webflow CMS.

Which one fits you?

A quick decision guide:

• Selling a handful of standard products → Webflow Ecommerce (option 1)
• One product, donation, or quick checkout → Payment Links (option 2)
• No-code but want polish → Stripe App from Marketplace (option 3)
• Subscriptions or memberships with gated content → Stripe + Memberstack or custom API (option 5), since If you're using Stripe for subscriptions, you'll need to handle logic for signups, plan changes, cancellations, and user access -- which isn't built into Webflow by default Amply
• Variable/dynamic pricing driven by user input or CMS data → Custom API (option 5)

One thing to watch: Webflow's native Ecommerce is solid for standard catalogs but Stripe's default form may not allow deep customization. Design Limits: Webflow's e-commerce templates may not fit all business needs. Rsacreativestudio If your pricing model is genuinely variable (custom quotes, dynamic discounts, metered usage), you'll want to skip native Webflow Ecommerce and use Stripe Checkout or the API directly with Webflow as the marketing front-end.

Want me to dig deeper into any specific path -- for example, how to wire up dynamic pricing where the price is calculated based on CMS data or user inputs?

Practical considerations

A few things to plan for upfront:

• Deposits. If you take a 50% deposit, charge that via Checkout and create a separate Invoice for the balance closer to the event. Stripe Quotes can model this natively.
• Lead time. Block out dates that are too soon. Validate the event date server-side too, not just in the form.
• Cancellations. Decide your refund window before going live -- Stripe makes refunds easy but the policy is yours to enforce.
• GST. Stripe Tax can calculate NZ GST automatically once configured, which is much cleaner than baking it into your price logic.
• Calendar conflicts. Catering capacity is finite. Either expose a real availability calendar in the configurator, or accept that you'll occasionally need to refund and follow up -- and pick the quote-first model accordingly.

What I'd actually build

For a NZ catering business today:

• Webflow for the marketing site and configurator (use the CMS for menu items so the chef can update them without dev work)
• Cloudflare Workers or Vercel functions for the backend (cheap, fast, simple)
• Stripe Checkout for payment, with Stripe Tax enabled for GST
• Airtable or Supabase for order records -- Airtable is easier if non-developers need to manage orders day-to-day
• Resend or Postmark for transactional emails (confirmation, deposit-paid, balance-due reminder)

If the budget for a custom backend is zero, the workable no-code path is Cognito Forms or Jotform embedded in Webflow via iframe -- both have decent calculation logic and Stripe integration with unlimited custom fields. Less elegant and no real server-side validation, but functional.

Want me to sketch out the configurator UX flow, or dig into the Stripe Quote/Invoice approach (which I suspect fits catering better than direct Checkout)?

Stripe

If you have a middle tier, you can use Stripe.

This is exactly what price_data with unit_amount is for -- you do all your calculation server-side, arrive at a final number, and hand Stripe just that number to charge.

Stripe doesn't need to know how you got there. It doesn't care whether it's 800 calculations or one. From Stripe's perspective, it's just "charge this customer this amount in this currency for this description."

A minimal example:

const session = await stripe.checkout.sessions.create({
  mode: 'payment',
  line_items: [{
    price_data: {
      currency: 'usd',
      unit_amount: 247350,  // $2,473.50 in cents
      product_data: { 
        name: 'Custom Tour -- 6 days, 4 people',
        description: 'Wellington → Queenstown, includes...'
      }
    },
    quantity: 1
  }],
  success_url: 'https://yoursite.com/success',
  cancel_url: 'https://yoursite.com/cancel',
});

A few things worth knowing:

• Amounts are in the smallest currency unit -- cents for USD/EUR/GBP/AUD/etc. So $24.73 becomes 2473. Some currencies (JPY, KRW) have no decimals, so you pass the whole number directly.
• Do the calculation server-side, not in the browser. If your front-end posts the final price to your backend and your backend just forwards it to Stripe, anyone can open dev tools and pay $1 for your $2,000 tour. The backend should either redo the calculation or validate the inputs that produced it.
• You can split it into multiple line items if you want the receipt to show a breakdown (accommodation, transport, guide fees), or keep it as one line. Stripe charges the sum either way.
• Metadata is your friend for storing the calculation inputs -- metadata: { tour_id: 'abc123', pax: 4, start_date: '2026-06-01' } -- so you can reconcile later or debug if a customer queries the price.

The mental model: Stripe is a payment terminal, not a pricing engine. You tell it the amount, it takes the money.

Why fully client-side won't work

To create a Stripe Checkout Session, you need your secret key (sk_live_...). If that key ever touches the browser, anyone can view-source it and start issuing refunds, creating charges, pulling customer data, or draining your account. Stripe will detect it and roll the key, but the damage window is real.

The same applies to amounts: if the browser tells Stripe "charge $2,473.50," a malicious user just rewrites the JavaScript to say "charge $1.00" and Stripe has no way to know that's wrong. Stripe trusts whoever holds the secret key.

So the rule is: the secret key and the final amount must be set somewhere the user can't tamper with.

What "no backend" actually means in practice

You don't need a server you manage. You need a function that runs somewhere other than the browser. These are basically free, take 10 minutes to set up, and are what every modern Webflow/Stripe build uses:

• Cloudflare Workers -- free tier covers 100k requests/day
• Vercel Functions -- free tier is generous, deploys from a Git repo
• Netlify Functions -- same idea
• Make.com / Zapier webhooks -- no-code, slower, but works

Your Webflow site calls one of these via fetch(). The function holds the secret key, does the price calculation (or validates the inputs), creates the Checkout Session, and returns the Checkout URL. Browser redirects. Done.

javascript

// In your Webflow page (client-side) const response = await fetch('https://your-worker.workers.dev/checkout', { method: 'POST', body: JSON.stringify({ tourId: 'abc', pax: 4, dates: [...] }) }); const { url } = await response.json(); window.location = url;

The worker is maybe 30 lines of code. It's not a backend in the heavyweight sense -- it's a single function on someone else's infrastructure.

The "I really mean client-side only" options

If you genuinely cannot or will not run a function anywhere:

1. Stripe Payment Links with adjustable quantity. You pre-create a Payment Link in Stripe for "Tour deposit, $50/unit" and let the customer's calculated price determine how many units. Crude, only works if your prices land on clean multiples, and the customer sees "47 × $50" on the receipt instead of "$2,350 tour."

2. Pre-built price tiers. Create dozens of Stripe Products at fixed price points ($100, $250, $500, $1000...) and have the client pick the closest one. Awful UX, awful for accounting, but technically client-only.

3. Stripe Pricing Table embed with custom amounts. Limited, doesn't really fit dynamic per-customer pricing.

4. Send the customer an invoice manually. Customer fills out a form, you get an email, you create a Stripe Invoice in the dashboard, customer pays. Fine for low volume.

None of these are good for an 800-calculation tour pricing engine.