Wix Stores has one price per product. If a bakery, a candle maker or a wine shop wants trade customers to pay less than the public, there is no wholesale switch to flip. Wix's own workaround is a members-only store page with duplicated products at wholesale prices, and its article (Creating restricted store pages) also names one app, SparkLayer.

Full disclosure: I make one of the apps below, Wholesale Prices & B2B Groups. I describe it last, with its limits. Everything else comes from each app's Wix App Market page, read on 3 November 2026. Where a page didn't say something, I say "not stated" and don't guess.

What the free workaround costs you

The members-only page works for a small catalog: duplicate each product at its wholesale price, put the copies in a "Wholesale" category on a page set to site members, and approve new members manually. The cost is upkeep. Every price change, photo and description has to be made twice, and the page itself doesn't enforce a minimum order. If you have thirty products and two trade customers, that may be fine. At three hundred products it isn't.

The questions that sort the apps

A search for "wholesale" in the App Market returns dozens of results, but most are dropshipping, catalog or quote tools. Ten of them are close fits for giving approved buyers their own prices on a Wix Stores shop. Before you read the list, decide:

1. How does a buyer become a trade customer? An application form you approve, a label or group you fill yourself, or a group you fill by email.
2. Do you need case packs and minimum order quantities, or only a percentage off?
3. Do you need quotes and a buyer portal, or just a price in the cart?
4. How many trade buyers will you have? The free plans cap this differently.

What the listings say

Most of these are new, with zero or one review. That isn't a reason to skip them, but test each on your own store with a real trade login before you hand it to a customer.

How I'd pick

• A few trade accounts, want to try for free: one of the free plans above.
• Buyers should apply and be approved from your site: the apps that list an application form.
• Case packs, MOQs and quotes: TradePortal and B2B Wholesale Pricing list them; neither page explains how prices show in checkout, so test an order.
• A real B2B operation with a sales team: SparkLayer, priced for that.
• Only hide prices until login: B2B Login To See Price.

Where mine fits, and where it doesn't

Full disclosure, I built Wholesale Prices & B2B Groups. You mark trade customers with a contact label such as "Wholesale". When they are logged in as site members, they get the group price in the cart and at checkout. A group has pricing lines: a percentage off the whole store, a collection or chosen products, or a fixed price per product, with an optional minimum order subtotal.

What it doesn't do:

• No application form. You add the contact label yourself.
• One discount per product. Wix applies one automatic discount per product, so a trade customer gets the best price on that product, not a stack. A coupon code they type comes off on top.
• No quantity tiers, case packs or quotes.
• Collections are capped at 500 products per group, and the price line on the product page works on sites built in the Wix Editor, not in product grids.
• Free is one group with one store-wide percentage. Pro is $9.99 a month, or $7.99 billed yearly, with a 14-day trial.

If you need applications, packs or quotes, one of the apps above fits better.

The full side-by-side guide, with a checklist and FAQ: Wix wholesale and B2B apps compared.

You take room bookings on Booking.com or Airbnb and also on your own Wix site. A guest books the last double room on your site at 10:00, and at 11:00 someone books it on Booking.com. That is the double-booking problem, and the usual free fix is iCal calendar sync. It works, but it is slower and more limited than most people expect. Here is how it works and where it stops.

Full disclosure: I built a Wix app for this (it is at the end). The first part works without it.

How iCal sync works

An iCal link is a web address that returns a calendar file (often ending in .ics) listing the booked or blocked nights of one room. No prices, no guest names. Sync needs two links per room, one per direction:

• Export: each site gives you a link with its own bookings.
• Import: you paste the other site's link into each site, and that site blocks those nights.

The steps, with the sites' own help pages

• Booking.com export: extranet > Rates & Availability > Sync calendars > Add calendar connection on the room > Skip to export > name it > Copy link. Each room has its own link. (Booking.com help)
• Airbnb export: Calendar > Availability > Connect calendars > Connect to another website > copy the link. (Airbnb help)
• Import into your site: paste each link into whatever runs the booking calendar on your site, one link per room. If a link starts with webcal://, change it to https://.
• Give your site's link back: in Booking.com, Add calendar connection on the room and paste your site's link. In Airbnb, paste a link ending in .ics under Connect to another website.

Where it stops

It is not instant. Booking.com says it imports every two hours, Airbnb about every three hours, and both say plainly that calendars are not synced in real time and can lead to double bookings. The slowest reader sets your risk: a booking on your site at 10:00 may not close those nights on Airbnb until around 13:00. Buttons like Import now (Booking.com) and Refresh (Airbnb) shorten the wait, but you have to press them.

Booking.com does not offer it to everyone. Its help page lists requirements, including a maximum of 20 room types and one unit per room type. Five identical rooms sold as one room type do not qualify, and Booking.com points those properties to a connectivity provider (a channel manager). Check your extranet for the Sync calendars option before you plan around iCal.

Wix's own hotel product works differently. Wix Hotels by HotelRunner has a one-way Airbnb iCal connection (Wix to Airbnb; Airbnb reservations are entered by hand) and a channel connection for Booking.com. Wix's help pages describe both. Wix Bookings is built for services and classes, not room stays.

Keeping the double-booking window small

• After a direct booking, press Refresh in Airbnb and Import now in Booking.com.
• When you are nearly full, block the last dates by hand on each site.
• Do not chain calendars through Google Calendar; each hop adds a wait.
• Decide in advance what you do about a rare overlap.

What I built

Full disclosure, I built Hotel & B&B Booking System, a Wix app for small hotels, B&Bs and guesthouses. Each room has its own calendar link with your confirmed direct bookings and blocked nights. You can import Booking.com, Airbnb, VRBO and Google Calendar links per room, and the app reads them about every 15 minutes. Imported nights are not sent back out, so calendars do not echo each other.

The limits remain. Booking.com and Airbnb read your link on their own schedule, so an overlap is still possible in that window, and if an imported event covers nights of a confirmed direct booking, the app marks that booking in the Bookings and Today tabs and emails you once. It does not move or cancel either booking, so you decide which one stands. iCal carries dates only, not prices. This is not a channel manager and it does not push rates to Booking.com. If you have many rooms or want rates pushed, a channel manager is probably the right tool.

The full guide with the table of update times and an FAQ: How to sync your Booking.com and Airbnb calendar with your Wix website.

Wix Stores can price shipping by weight, by order price or by number of items out of the box, with up to 30 ranges in each table. It can't price shipping by postcode for normal shipping regions, which only go down to country and state level. Postcodes are only available for local delivery, and you can't combine weight and price in one rate.

Here is what each built-in option does and how to set it up.

Where are the shipping settings?

In your site's dashboard, go to Settings and open Shipping, delivery & fulfillment. New stores start with two regions, "Domestic" and "International". Each region has one or more rates, and a region with no active rate can't buy from you (Wix overview).

To add a region, click + Create Region, click Continue and select Shipping. To add a rate to an existing region, use Add Rate.

A region can be "a country, a group of countries, or states/provinces within a country" (Creating shipping and delivery regions). Wix's developer documentation adds that some countries, including Norway, Austria, Switzerland and Poland, can't be split into sub-regions at all.

How do I charge shipping by weight?

1. Make sure every product has a Shipping weight. A product without a weight counts as 0. Products with variants can have a weight per variant under Edit Variants.
2. In your region, add a rate and choose Rate by weight.
3. Add your weight ranges with Add Range and a price for each. You can create up to 30 ranges.
4. To ship free above an order amount, tick Offer free shipping when customers purchase a certain amount in the same rule.

Wix's guide: Setting up a rate by weight shipping rule.

How do I charge by order price or by number of items?

The steps are the same, with Rate by price or Rate by quantity. Both allow up to 30 ranges.

• For price, Wix suggests entering 0 in the last range to offer free shipping above an amount (guide). The article doesn't say whether the price is measured before or after discounts.
• For quantity, the ranges count the total items in the cart (guide). So "first item 5, each extra item 2" has to be written out as ranges: 1 item 5, 2 items 7, 3 items 9, and so on. With 30 ranges, that's fine for most shops.

Can I charge shipping by postcode or ZIP code on Wix?

Only with local delivery. When you set up a local delivery option, you choose how to define the area: Radius, Zip / postal codes, Draw on a map or Cities. You can add up to 50 local delivery areas per region, and each can have its own rate: free, flat, by weight, by price or by quantity.

Postal codes accept partial codes with an asterisk, such as "M5B*" or "M*" for a wider area (Wix guide). Wix notes that postal codes work differently in each country.

So for a bakery or a florist delivering in its own city, local delivery with postcodes is the right tool and costs nothing extra. For a shop that ships by carrier across a whole country and wants different prices for, say, the islands or the far north, Wix's shipping regions don't go below state level. Local delivery is built for deliveries in your own area, and Wix doesn't describe using it for carrier shipping, so if you try it that way, check how it looks at checkout first.

Different shipping for heavy or bulky products

Wix replaced the old "rate by product" setting with delivery profiles. In Shipping, delivery & fulfillment, click More Actions and Create delivery profiles, then + Create New Profile, add the products with Add Items, and create regions and rates for that profile. Wix's examples are heavy and light, oversize and regular, fragile and non-fragile.

You pick products one by one, not by category. When a cart mixes profiles, Wix either combines rates with matching names or charges the more expensive one, depending on your settings.

Where the built-in options stop

• Weight and price together. For example, by weight, but free over 100. Wix says "it is not possible to combine shipping rules based on weight with shipping rules based on price" (feature request).
• Postcode zones for normal shipping, like a higher price for postcodes starting with 9.
• Per kilo pricing above a base weight, such as 6 for the first 2 kg and 1 for each kilo after that, beyond 30 ranges.
• Hiding a rate for some products, such as no express shipping when the cart contains furniture, without moving those products into their own profile.
• A bulky item extra by category, added on top of the normal rate.

Live carrier rates are a separate topic: Wix has built-in USPS rates for US merchants, and carrier apps such as Shippo, ShipStation and Easyship for others (Wix guide).

An app for your own rate rules

Full disclosure: I make Shipping Rate Rules. You build shipping options priced by a table of cart weight, cart value or item count, with extras such as a price per kg or lb above an included weight, "first item plus each additional", a share of the cart value, an extra per item from chosen categories, free shipping above a cart value, and a lowest and highest price. Each option can be limited to countries, states or regions, and postcodes (a prefix like "NW1" or a range like "0150-0199"), and hidden when the cart holds products from chosen categories. You can test a cart in the dashboard before saving.

What it doesn't do: no live carrier rates, no pricing by distance and no pricing by package size. It uses your product weights, so products without a weight count as 0. You add the app to each region in your shipping settings (Manage Your Apps) with a backup rate, which Wix shows if none of your options fits a cart or the app doesn't answer in time. If the region also keeps its own Wix rates, shoppers see both. The free plan runs one shipping option at a time.

It's on the Wix App Market.

FAQ

Can I set different shipping rules for one product? Yes, with a delivery profile. Put the product in its own profile and give that profile its own regions and rates.

Can I stop orders from postcodes I don't deliver to? With local delivery, only the areas you define are offered. For normal shipping, Wix regions go down to state or province level, not postcodes.

How many weight ranges can I add? Up to 30 per rate. Older forum threads mention a limit of 10, but Wix's current guide says 30.

Last checked: 15 October 2026

Related guides

• UK postcode shipping on Wix: London zones, Highlands and exact districts
• Add a handling, packaging or service fee at Wix checkout
• Minimum order and quantity limits on Wix: every option compared
• Per-kg or per-lb shipping on Wix Stores
• Wix shipping rate apps compared

Originally published at kayabyte.dev.

Full disclosure: I built the app described in the last section. The first sections are about the problem and the by-hand options, which need no app.

If you take bookings for a cabin, a flat or a few rooms on your own website, the nightly price is only part of what you charge. Guests also pay for breakfast, early check-in or a pet, and in many places they owe a city or tourist tax. After the booking comes more work: sending the address and the door code, and telling the cleaner who leaves and who arrives.

What hosts usually need on top of the nightly price

• Extras: early check-in, late check-out, breakfast, a pet fee, an extra bed. Some are optional, some should always be added.
• A tourist or occupancy tax as its own line, so the guest sees what is the room and what is the tax.
• A message before arrival with the address, key box or lock information, wifi and parking.
• One search across several cabins or rooms, so a guest picks dates and sees what is free.
• A calendar for the cleaner that lists every check-out and what comes next.

Doing it by hand

It works, and for one or two bookings a month it is fine.

• Extras and tax: put them in the confirmation or in an invoice, or fold a fixed "cleaning and service" amount into the nightly rate. The downside is that the guest does not see the full price before paying, and you do the arithmetic every time.
• Arrival message: keep a template in your mail app and send it a few days before each check-in. The risk is forgetting one, or sending it for the wrong booking.
• Cleaner: share a Google Calendar and add each check-out yourself, or forward your Airbnb and Booking.com calendar links. Imported calendars usually show "reserved" blocks, not who arrives next.

If you are not sure how your tourist tax has to be charged or reported, ask your municipality. That is a legal matter and no booking tool decides it for you.

What to look for in a booking tool

• Are extras optional or required, and charged per stay, per night, per guest or per guest per night?
• Does the guest see each extra and the tax as separate lines, and does the checkout total match?
• Can the tax be per person per night, per person per stay, per stay or a percentage, with children left out if your rules say so?
• With a deposit, do extras and tax follow it, or does the total stop adding up?
• Is the arrival message sent by the tool, once per booking, with a preview?
• Does the cleaner calendar leave out guest names and contact details?

Where my app fits

Full disclosure, I built Stay Direct, a booking app for vacation rentals and cabins on Wix sites. Its Host Pack has:

• Extras (all plans). Counted once per stay, per night, per guest or per guest per night, optionally always added. Each extra is its own line in the widget price and at checkout. Counted once per booking, not per room.
• Tourist or occupancy tax (all plans). A fixed amount per person per night, per person per stay or per stay, or a percentage of the stay price. For per-person taxes guests can say how many children are in the party so they are left out, and you can cap the taxed nights. It is a separate line. You still pay the tax to your municipality yourself; the app only collects and shows it.
• Pre-arrival email (Pro and Business). Written once per property, sent to each guest with a confirmed booking 0 to 14 days before check-in (your choice), once per booking. Replies go to your site's business email. Preview and test send included.
• Search across properties (Pro and Business). Guests pick dates and guests, see which of your properties are free with the total price, and book from the results.
• Cleaner calendar (Pro and Business). A calendar link with one entry on every check-out day saying when the next guests arrive. No guest names or contact details.

No commission on bookings; guests pay through your own Wix checkout.

Where it is not the right fit: no quantity per extra (one tick is one charge), the search widget handles single-room bookings, the arrival email is plain text with an English footer, and it is not a channel manager (calendars connect by iCal links, which carry dates only).

The longer version of this article, with an FAQ, is on kayabyte.dev.

Disclosure: I make Hotel & B&B Booking System, an app for Wix sites that I describe near the end. Everything about Wix below comes from Wix's own help pages, linked in each section. Checked on 2 November 2026.

If you run a hotel, B&B or guesthouse and want guests to book rooms on your own Wix site, there are three routes: Wix's own hotel app, a booking app from the App Market, or a manual workaround. They suit different places, so start with what you actually need.

What does a small hotel or B&B need from a booking system?

Before comparing tools, write down your list. For most small places it looks like this:

• Room types with several identical rooms. Four "Double rooms" are one thing to sell, but four rooms to keep track of.
• Availability across those rooms, so the fifth guest is told the type is full and nobody is given the same room twice.
• Rates: room only, bed and breakfast, a cheaper non-refundable rate, seasons, weekend prices, long-stay discounts and a minimum stay.
• A deposit or full payment at booking, through a checkout you already use.
• Sync with Booking.com and Airbnb, so a night sold there is closed on your site and the other way round.
• A front-desk view: who arrives today, who leaves, which rooms are taken.

Can Wix Bookings take hotel room bookings?

Wix Bookings is built for scheduling services. Wix describes it as a system that lets clients book and pay for services such as workshops, courses or private sessions, online or in person (Wix guide). Its unit is a time slot, a class or a course, not a nightly stay in one of several rooms. People do bend it to fit (a service per room, for example), but you end up managing availability by hand. For overnight stays there are better-fitting options.

What is Wix Hotels by HotelRunner?

It is Wix's own app for hotels, B&Bs and rentals. Wix describes it as a way to manage availability and reservations with calendars, offer packages, and showcase rooms on booking sites such as Booking.com, Airbnb and Expedia (Wix overview).

What speaks for it:

• A channel manager. Your rates and availability are sent to Booking.com, Airbnb, Expedia and others. Wix says the channel manager comes included when you upgrade your site and that no additional fees apply, and that the number of channel connections varies by plan.
• Rate plans, seasonal rates and per-date restrictions such as minimum stay and closed to arrival, with bulk updates (overview).
• Nine languages in the app itself.

What to check before you commit:

• Booking.com takes over your calendar. Wix says that after connecting, your whole inventory is transferred to Booking.com and replaces the existing calendar there, and that all updates must then be made in the Wix dashboard because your Booking.com calendar is locked. You can connect one Hotel ID per channel to each account (Wix guide).
• The Airbnb iCal connection is one way. Availability goes to Airbnb, but Wix says rates and reservations do not come back, and you update Airbnb reservations in Wix by hand. It needs a Premium plan (Wix guide).
• The number of channels depends on your plan, and Wix's help pages do not list the numbers.
• Owners report limits on the Wix forum, such as minimum stays and long-stay discounts. I went through them, with sources, in Wix Hotels by HotelRunner limits. I could not find a public price list for the app, so check the cost for your plan yourself.

If you need rates pushed to Booking.com and Expedia, this is the route to look at first.

Can I do it by hand with forms and calendars?

For a very small place, yes. A common setup is a page with your rooms and prices, an enquiry form, and a shared calendar you keep up to date. You confirm each stay by email and send a payment link.

It works for a few rooms and a few bookings a week. It breaks down when:

• Guests expect to see availability and pay at once.
• You take bookings on Booking.com or Airbnb as well, because every booking has to be entered in several places.
• You have identical rooms, because the count per room type is easy to get wrong.
• Deposits and balances need chasing.

What can a booking app do instead?

An app from the Wix App Market puts a booking calendar on your site, works out the price and takes payment through your checkout. Apps differ a lot, so use this checklist when you compare them:

• Several identical rooms per room type, with a room-by-room view.
• Rates and rules: rate options, seasons, weekend prices, long-stay discounts, minimum stay, allowed check-in days.
• Deposits and which payment methods are available.
• Calendar sync: how many calendars, in which directions, and how often. Ask whether it is a direct connection to the booking sites or iCal links.
• Commission: none, or a percentage of each booking.
• Extras and tourist tax as separate lines in the price.
• What it does when two bookings overlap, and whether you are told.
• Languages for guests, and whether it needs a paid Wix plan to take payments.

Where Hotel & B&B Booking System fits (mine)

Full disclosure: I built Hotel & B&B Booking System. You set up room types such as "Double room" with four identical rooms. Guests pick dates and party size, see the price for their stay and book one or more rooms through your site's checkout. It has Bed & breakfast and Room only rates, a non-refundable rate as a percentage adjustment, seasons, weekend prices, long-stay discounts, minimum stays, deposits, extras and a tourist tax line. The dashboard opens on a Today view (arrivals, departures, staying tonight) and a room-by-room grid of the next 14 nights. Each room has its own calendar link for iCal sync with Booking.com, Airbnb, VRBO and Google Calendar, in both directions: we read your other calendars about every 15 minutes, and they read ours on their own schedule.

Plans: Free (1 room type, 5 online bookings a month, 1 synced calendar), Pro at $8.99 a month ($6.99 billed yearly) and Business at $17.99 a month ($13.99 billed yearly), with a 14-day trial. There is no commission. Online payments need a Wix Premium plan.

Where it is not the right fit:

• It is not a channel manager. It does not use Booking.com's or Expedia's APIs and does not push your rates there. Sync is by iCal links and carries dates only.
• iCal is not instant, so an overlap is possible in the minutes before the next read. See how to sync your Booking.com and Airbnb calendar with your Wix website.
• It cannot hold or pre-authorise a card.
• The dashboard is in English; the guest widget is in 9 languages.
• There is no check-in or check-out status for the front desk.

See Hotel & B&B Booking System on the Wix App Market

FAQ

Can Wix take hotel bookings without an app? Wix Hotels by HotelRunner is Wix's own hotel app. Wix Bookings is built for services, classes and courses rather than nightly stays.

What do I need to take payments online? A Wix Premium plan that accepts payments and a connected payment provider. Wix says you must upgrade your site to accept bookings and online payments.

Do I need a channel manager? If you want your rates and availability pushed to Booking.com or Expedia automatically, yes. If you mostly take direct bookings and keep other sites in step with calendar links, an iCal-based app can be enough.

Can guests book more than one room? It depends on the tool. Check this on the demo or in the listing before you choose.

What is the cheapest way to start? Try the free plans and trials with a real test booking. Whatever you pick, make a booking for two rooms, one for a weekend and one that crosses a season, and see if the price is what you expect.

Last checked: 2 November 2026. Spotted something out of date? Write to support@kayabyte.dev and I'll fix it.

Related guides

• How to sync your Booking.com and Airbnb calendar with your Wix website
• Wix Hotels by HotelRunner limits: minimum stays, last-minute bookings and more
• Direct booking on a Wix site: every option compared (2026)
• Sync Airbnb with your Wix site without double bookings

Wix has two built-in ways to charge an extra fee in a Wix Stores checkout: a handling fee attached to your shipping rates, and a newer Additional fees section in your checkout settings that adds a fixed fee or a percentage of the subtotal to every order. For a simple fee on every order, that's all you need.

Here is how both work, and where they stop.

Option 1: a handling fee on your shipping rates

This is the older setting, and Wix documents it in Adding handling fees:

1. In your site's dashboard, go to Shipping, delivery & fulfillment.
2. Click the More Actions icon next to the region you want and select Add handling fees.
3. Select the shipping rules the fee applies to.
4. Enter the handling fee and click Save.

Customers see the fee as its own line next to the delivery rate and in the order summary.

Because it hangs on shipping rules, it only appears when a shipping rule is used. A digital-only order, for example, has no shipping rule to carry it. Wix's own tip, if you don't need a separate line, is to simply add the amount to your shipping price.

If you use delivery profiles (separate shipping for some products) and a cart mixes profiles, Wix says the highest handling fee is applied once.

Option 2: Additional fees in your checkout settings

This is the newer way, and it doesn't depend on shipping. Wix moved it here from the old Wix Functions tool, which no longer lets you create new functions (Wix's note on the change):

1. In your site's dashboard, go to Settings > Checkout.
2. Scroll down to Additional fees and click Charge Additional Fees.
3. Pick a template: Fixed fee (a fixed amount per order) or Subtotal percentage fee (a percentage of the order subtotal, before discounts and taxes), then click Use Template.
4. Enter a Fee name (customers see it in the cart and at checkout) and a Fee amount (before tax), and click Activate.

Wix's help article gives the example of "a $2 customization fee".

The section's own description says fees can be "based on order, customer, or shipping details". When I opened it on a test site in October 2026, though, both templates only asked for a name and an amount, with no conditions to set. Wix may add more over time, so look at what your dashboard offers before you go further.

What about a small-order fee?

If what you really want is to stop tiny orders, Wix has a built-in minimum order amount: in Settings, open Store products & Inventory and turn on Set a minimum subtotal. It blocks checkout below the amount instead of charging a fee. Note that it doesn't apply to pickup orders or digital products.

If you'd rather accept small orders and charge a little extra, say $3 on orders under $25, that's a fee with a condition. The native Additional fees templates had no condition like "only below an amount" when I checked, so that one needs something else.

Can I charge a fee for cash on delivery or credit card payments?

Not with Wix's own settings. Shop owners have asked for a fee on manual payments in the Wix Studio forum without a native answer. Fee apps now get the payment method type the shopper picked (Wix developer docs), but only once the shopper has chosen one, so the fee can appear late in checkout. A few App Market fee apps offer payment-method fees; Handling & Checkout Fees doesn't yet. Check the rules where you sell first: in the EU and the UK, surcharges on consumer card payments are banned. The simple options are still a small fee on every order, or building the cost into your prices.

What about gift wrapping?

I couldn't find a built-in gift wrap option in Wix's help. Wix's article on product options says "You cannot collect extra payment for gift wrapping with a modifier" (the new product catalog may handle modifiers differently, so check your product page). The free workaround is a product option, such as "Gift wrap: yes / no", where the "yes" variant has a higher price. That works per product, not as one fee per order.

Where the built-in options stop

Going by what Wix documents, these are the cases where you'll likely need something else:

• A fee only for some products or categories, such as packaging on fragile or chilled items, charged once per order.
• A small-order fee that only applies below a subtotal.
• A fee for some postcodes or countries, like islands or remote areas, without changing your shipping rates.
• A fee for one delivery option or for pickup, such as a fee for same-day delivery.
• Several fees at once, each with its own line, and a choice of whether tax applies.

An app for conditional fees

Full disclosure: I make Handling & Checkout Fees. Each fee is a fixed amount or a percentage of the matching items' subtotal (with an optional minimum and maximum), for the whole order, chosen products, or chosen categories. You can limit a fee to a subtotal range, ship-to countries, postcodes or postcode ranges, and shipping, pickup or a named delivery option. Every fee shows as its own named line in the cart and at checkout, and tax is off unless you turn it on for that fee.

What it doesn't do: no payment-method fees, for the reason above. It only counts Wix Stores products, not bookings. It doesn't change product prices, shipping rates or discounts. A postcode or delivery fee only appears at checkout once the shopper has entered those details. If the app can't calculate a fee in time, no fee is added and checkout carries on. The free plan runs one fee at a time.

It's on the Wix App Market.

FAQ

How do I add a 5% service fee to my Wix checkout? Try Settings > Checkout > Additional fees and the Subtotal percentage fee template first. It doesn't depend on shipping rules, so it should also apply to orders of digital products. Check with a test order.

Can I add a surcharge per item on top of flat rate shipping? Not as a per-item add-on. The closest built-in option is the Rate by quantity shipping rule, where you set prices for item-count ranges (up to 30 ranges, per Wix's guide).

Can customers pay the card processing fee instead of me? Not with Wix's own settings. Fee apps can now see the payment method type once the shopper picks one, and a few offer card or cash on delivery fees. Card surcharges are banned for consumer cards in the EU and the UK, so check your local rules. A fee on every order, or slightly higher prices, work everywhere.

Last checked: 26 October 2026

Related guides

• Wix Stores shipping by postcode, weight or number of items
• Minimum order and quantity limits on Wix: every option compared
• Wix booking fees, surcharges and deposits compared
• Per-kg or per-lb shipping on Wix Stores

Originally published at kayabyte.dev.

What new hires get by default

• Autowatch is on by default, but it only covers pages a person creates, edits or comments on. A new hire watches nothing in the team space until they have worked on a page there.
• Watching a space covers all its pages and blog posts, and the person has to switch it on (or an admin does it for them, see Option 3).
• Watching does not give access. If the space is restricted, the new hire has to be able to see it first.

Option 1: a step in the onboarding checklist

Put a short "Follow these spaces" section on the onboarding page, with a link to each space and one line: open the space, select Watch. It costs nothing and works for a handful of spaces and one or two hires a month. It breaks when the list of spaces changes, when people skip the step, or when a new hire joins a team that follows eight spaces. Nobody checks that it was done.

Option 2: @mention on the key pages

For the few pages everyone must read, mention the new hire in a comment or add them to an announcement page. That is not a continuous feed from the space, and it is a manual job for each person.

Option 3: an admin adds the watch

The REST API can add a watch for someone else, one account at a time. It needs the Confluence Administrator permission, or Space Administrator on that space, plus the header X-Atlassian-Token: no-check:

curl -s -o /dev/null -w "%{http_code}\n" -u "you@example.com:your-api-token" -X POST \
  -H "X-Atlassian-Token: no-check" \
  "https://your-site.atlassian.net/wiki/rest/api/user/watch/space/TEAM?accountId=NEW_HIRE_ACCOUNT_ID"

A 204 means the watch was added. Run by hand, it is one more onboarding task. Run on a schedule, it needs somewhere to run, and it cannot tell watches it added from watches people chose: someone who unwatched on purpose is added again, leavers keep watching, and a cleanup step does not know which watches it may remove. I wrote the whole script and its limits in How to make a Confluence group watch a space. If you prefer a ready-made one, there is a free MIT script here: github.com/kayabyte-2/atlassian-admin-scripts.

Option 4: let group membership drive the watches

If you already keep a group per team (say engineering), the cleaner design is that adding someone to the group makes them watch. Full disclosure: we build Group Watchers, so weigh this accordingly. Group Watchers works like this:

• A rule maps one or more groups to a space or a single page. A space can have several rules.
• Joiners: add the new hire to the group and the app adds their watch. It checks membership every hour, and right away when you change a rule or select Sync now.
• Access: members who cannot see the space are skipped and counted in the rule status, then checked again every 6 hours, so a hire who gets space permission a day later still ends up watching.
• Leavers: when someone leaves every group in a rule, the app removes the watch it added. You can switch that off, and watches people had before are never removed.
• If a new hire unwatches, the app does not add them back.
• It runs on Atlassian's Forge platform and makes no calls outside Atlassian.

Two limits: only Atlassian user accounts can watch, so portal-only customers and app accounts are skipped. And if an identity provider fills your groups, the new hire appears when your provisioning puts them there, so check how quick that is.

One more thing: will they get email?

A new watcher may see little in their inbox. Edits and new pages go into the daily digest by default, while comments are emailed straight away. Each person changes this under their profile picture, Settings, Email. Add one line about it to the onboarding page.

Which one to pick

• A few spaces and rare hires: the checklist.
• Key pages only: @mention.
• Many spaces, frequent hires, groups you already maintain: group-driven watching, with a script you run or an app.

Confluence and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Jira tracks the hours, but it has no concept of a budget, so there is nothing to alert on out of the box. Here is what you can build with the built-in tools, and where each option stops.

Step 0: decide what the budget is

Before any tool, write down three things per client: the number (hours or money), what it covers (a project, an epic, a version), and the period (one-off, or resets every month). Every option below breaks if this is vague.

Native option 1: time tracking fields and a filter

Each work item has Original estimate, Remaining estimate and Time spent. A filter such as project = ACME shown as a list with the Time Spent column, plus a subscription, gives you a regular email with the work items.

Limits: the filter lists work items, it does not total the hours. It knows nothing about a budget, so it cannot tell you that you passed 80 percent. A subscription sends on a schedule whether or not anything is wrong.

Native option 2: Automation with a scheduled rule

This is the closest native approach.

1. Create a rule with a Scheduled trigger (daily is plenty).
2. Add a Lookup work items action with JQL for the client's scope, for example project = ACME AND worklogDate >= startOfMonth().
3. Add a Send email or message action that goes out when the hours cross a threshold you typed into the rule.

The sum is where it gets rough. Smart values can read time spent per work item, and in a scheduled rule you can add them up across the lookup results, but check the output on a real run before you trust it: time spent on a work item covers all dates, not just the current month, so a monthly budget needs care. The threshold lives inside the rule, so every client is a copy of the rule to edit.

Limits:

• Hours only. Money needs rates, and dated rates are awkward to keep inside a rule.
• One rule per client or budget, with the number hard-coded.
• Rule runs count towards your plan's Automation usage, and a lookup over a large project is slow.
• It tells you the threshold was crossed. It does not tell you when the budget will run out at the current pace.

Native option 3: a spreadsheet

Export the worklogs (author, date, time), sum per client, compare with the budget in a column, and colour the cell when it passes 80 percent. This is honest and works, as long as someone refreshes it. In practice the export gets a week old, and the alert is a person remembering to open the sheet.

What a good warning needs

• A budget with a number and a period, not a threshold buried in a rule.
• Spend that is always current, with rates when the budget is money.
• A pace, so "80 percent used" can be read as "11 days left" or "fine until the end of the month".
• A status you can scan across all clients in one place.

Burnrate

Full disclosure: we build Burnrate. Burnrate for Jira reads the worklogs your team already logs, prices them with a dated rate card and compares them with budgets that you create per project, epic, fix version or JQL query, in money, hours or both, one-off, monthly or quarterly.

What it gives you for this problem:

• A warning level per budget (80 percent by default). When usage reaches it, or the forecast says the budget will be exceeded, the budget shows as At risk. Past the limit it shows Over budget; otherwise On track.
• A forecast next to the status: pace over the last 28 days, a projected total for the period and, when it falls inside the period, the day the budget runs out. How that is calculated is in the burn rate article.
• All budgets in one list, so you see which clients are at risk without opening a sheet.

What it does not do: it does not email or message you when a budget turns At risk, and there is no dashboard gadget yet. You see the status when you open Burnrate. If you want a push, a team routine that opens the budget list every Monday does the job, and a native Automation rule on hours can sit next to it as a backstop.

For two or three clients with hour budgets, an Automation rule per client is fine. When there are many budgets, some in money, some resetting monthly, a status that is always current is the part worth handing over.

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Request participants

Participants are people added to one request. They can view it, comment and get the same notifications as the reporter. Agents add them under People, then Request participants. Customers can do it with Share in the portal. Each person added gets an email saying so, and a participant can turn their notifications off.

The catch: a participant is one person. There is no field for a Jira group (JSDCLOUD-1268 on jira.atlassian.com asks for it), so a team of 8 is 8 entries on every request.

CC on email requests

If customers CC addresses on an email to the project's email channel, those people can be added as participants. That is real CC behaviour, but it is per email, it only covers addresses somebody typed, and it knows nothing about your groups. It does nothing for requests raised in the portal.

Organizations and customer notification settings

An organization is a named group of customers. A request shared with one is visible to its members in the portal. They get a single "Organization added" email, and later updates only if they turn notifications on for that request. So organizations answer "who can see this", not "who follows this", and they hold customers, not your internal team.

The project's customer notification settings decide which emails customers get for a request. They control what is sent to people who are already on it. They do not add anyone.

Automation

A rule on Work item created can set Request participants, so a fixed list of people can be added to every new request of a type. Depending on your Automation version this is under Edit work item or a dedicated participants action, so check what your site offers.

The limit is the one you would expect: the people are typed into the rule. When someone joins or leaves the team you edit the rule, and requests that are already open do not change. Each run also counts towards your plan's Automation usage.

When a native setup is enough

If the team is small and rarely changes, one Automation rule per request type is fine. If you only need a handful of requests followed, adding participants by hand is fine too. Neither stops being fiddly when the team changes every month.

The app route

Full disclosure: we build Group Participants, so weigh this accordingly. Group Participants for Jira Service Management uses Jira groups instead of typed lists. From what it does today:

• Rules per service project and request type (or every type if you leave it empty), each pointing at one or more Jira groups.
• On a new request it adds the active members of those groups as participants, usually within a few seconds. The reporter and people already on the request are skipped.
• An hourly check adds people who joined the group to matching open requests (not in a Done status category).
• Removing people who left is off by default, because someone may also have been added by hand. You can switch it on.
• "Sync open requests now" brings existing open requests in line, up to 1,000 per rule per run.
• On any request, Actions then Add group as participants does the same for one request, using the agent's own permissions.
• Limits: only active Atlassian accounts are added, and Jira Service Management decides who can be a participant, so people without customer access to the project are rejected. Portal-only customers cannot be in Jira groups, so they are not covered. It works with Jira groups, not organizations.
• It runs on Atlassian (Forge) and makes no calls outside it.

Which one to use

• A team should follow every request of a type, and the team changes: participants from a group.
• Customers from one company should see each other's requests: an organization.
• Customers who email in and CC a colleague: the email channel already handles that.

The longer version, with a FAQ, is in this guide.

Jira Service Management, Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

This is about why it happens, what Jira can show you, and where the built-in tools stop.

Why it happens

• Starting is free. Moving a card to In Progress costs a click, and finishing costs days.
• Blocked work stays "in progress". Waiting on a reply, a deploy or a review, people start something else, and the first item never leaves the column.
• The helpful people collect the most. Whoever says yes fastest ends up with the pile.
• Nobody sees it. A board shows cards, not how many one person holds.

Column limits count the column, not the person

Jira's column constraints set a minimum and maximum number of work items per column and colour the header when it is exceeded. They count every work item in the column, whoever holds it, and people can still move work in. A column limit of 6 is respected with a split of 4, 1 and 1. Someone working across three boards can be under every column limit and still hold ten items.

Spot it with JQL

This finds work that is in progress and assigned:

statusCategory = "In Progress" AND assignee is not EMPTY ORDER BY assignee

Save it as a filter and add a Two dimensional filter statistics gadget with Assignee on one axis. Each row is one person's count across every project the filter covers. To check one person, use assignee = currentUser() AND statusCategory = "In Progress".

Assignee swimlanes on the board give a similar view for one board.

It shows the problem and stops nothing. It works when the team looks at it every day.

Automation, after the fact

A rule can trigger on a work item transitioning to your In Progress statuses, look up work items with assignee = {{issue.assignee.accountId}} AND statusCategory = "In Progress", compare {{lookupIssues.size}} with your limit, and comment or notify a lead.

The catch is timing. The rule runs after the move, so the work has already started, notifications go out, and two moves at the same moment can both slip under the count. It is a nudge. Each run also counts towards your Automation usage.

Workflow conditions and validators

To stop the move itself, the check has to run on the transition. Jira's built-in conditions and validators can look at the work item being moved: its fields, the user's permissions, sub-task status. They cannot count how many other work items the assignee already has in progress. That needs a scripted validator or an app.

Before you pick either, decide four things: across all projects or per project, what counts as starting work (To Do into In Progress yes, In Progress into In Review no), who is exempt (on-call, support), and what happens if the check cannot run. A limit that blocks people when Jira is slow does more harm than good, so let the move go ahead.

Or agree it as a team first

Pick a number, say 3, and decide what happens at the limit. In Kanban the answer is usually to help finish something instead of starting something. That alone fixes a lot. We wrote the longer version, including the flow theory, in a guide on Kanban WIP limits per person: https://kayabyte.dev/atlassian/guides/kanban-wip-limit-per-person-jira

An app that puts the check on the transition

Full disclosure: we build Personal WIP Limits, so weigh this with that in mind. Personal WIP Limits for Jira adds a workflow rule, "Personal WIP limit", that you put on the transitions that start work, in company-managed and team-managed workflows.

• When the assignee is at their limit, Jira shows a message and the work item stays where it is.
• One limit for everyone, counted across all projects or per project. Projects can have their own limit or be switched off, and groups can be exempt.
• Moves between In Progress statuses and unassigned work are never blocked. If the app cannot check, the move goes ahead.
• An admin overview shows work in progress per person against the limit.
• It stores only its settings and makes no calls outside Atlassian.

Limits are a guardrail, not a guarantee, and everyone gets the same limit in this version.

If you only want visibility, the dashboard is enough. If you want the move itself to stop, the check has to sit on the transition.

I covered the column, filter and Automation options step by step in an earlier post: https://dev.to/kayabyte/how-to-set-a-wip-limit-per-person-in-jira-and-what-the-built-in-options-miss-52k5

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

The definitions

• Burn rate: money (or hours) spent per day or per week. In Jira terms, logged time multiplied by the hourly rate of whoever logged it.
• Run-out date: today plus remaining budget divided by burn rate. If 12,000 is left and the team burns 400 a day, the money lasts 30 days.
• Remaining estimates: the burn rate says how fast you are spending, not how much work is left. Pricing the Remaining estimate of open work items tells you what finishing will cost, which you can hold against what is left.

The burn rate should come from recent weeks, not from the whole project. A project that crawled for two months and then got a full team has a very different pace today than its average.

For the cost side (rates, dated rate changes, budgets per epic or version), see How to see project cost and budget in Jira from worklogs. This article is about the forecast on top.

Native and manual ways

Time tracking report

Jira's time tracking report shows original estimate, remaining estimate and time spent per work item for a project or version. Good for a quick look at hours. It has no rates, no dates for the pace, and no budget to compare with.

Export plus spreadsheet

1. Pull the individual worklogs (author, date, time spent) through the REST API, or export work items with their time fields.
2. Price each worklog with a rates table.
3. Sum the cost of the last 28 days and divide by 28. That is your daily burn rate.
4. Run-out date: =TODAY() + remaining / burn_per_day.
5. For the estimate view: sum the Remaining estimate of open work items, multiply by an average hourly rate, add to spent.

This works, and it is the right way to learn what the numbers mean. Each step is easy; the trouble is keeping it alive.

Dashboard gadgets

A Filter results gadget can list time spent and remaining estimate per work item, but the built-in gadgets count work items rather than total hours, so totals still mean an export. Either way it is hours, not money, and the gadgets do not know your budget or your pace.

Where it stops working

• The sheet is stale as soon as someone logs time or moves work between epics.
• A 28-day window needs a daily recompute. Nobody does that by hand.
• The first week of a month or project gives a pace that swings wildly. You need a rule for when to trust it.
• A run-out date after the budget period ends is not interesting. A formula happily prints it anyway.
• Rates are sensitive, and the people who should see a run-out date are rarely the people who should see what each colleague costs.

Burnrate

Full disclosure: we build Burnrate. Burnrate for Jira reads the worklogs your team already logs, prices them with a dated rate card and compares them with a budget. This is how its forecast works, taken from how we built it:

• Pace is the average daily spend over the last 28 days, or over the days since the period started if that is shorter.
• Run-out date is the money (or hours) left divided by that pace. If the budget has both an amount and hours, the earlier of the two wins.
• It only shows a date that falls inside the budget's period. If the pace would not use the budget up in time, you see the projected total at the end of the period instead.
• It waits until there are enough days to forecast from: 7 days of pace, or half the period for budgets shorter than two weeks.
• Estimate at completion is spent so far plus the Remaining estimates of open work, priced at the scope's average cost per hour. It is a separate figure from the run-out date, so you can see both views, and for one-off budgets a budget is marked at risk if either points over it.
• A budget is flagged At risk when usage passes your warning threshold or the forecast goes over the budget.

It does not email you about it, and it has no dashboard gadget yet. You see the forecast in the budget list and on each budget.

For one project and a monthly look, the spreadsheet above is enough. When several budgets run at once and you want the run-out date to be current when you open the page, that is the part worth handing over.

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Participants and organizations are different things

• Request participants are people on one request. They get its notifications and can comment in the portal. There is no field for a group, so a team of 12 is 12 entries.
• Organizations are lists of customers kept in Jira Service Management. Sharing a request with one makes it visible to the members. They get one "Organization added" email, and later updates only if they turn notifications on for that request.
• Neither is a Jira group. An organization is a second list that has to be maintained next to the group you already have.

So for "this team follows these requests, and the team changes", participants are the right field and organizations are not a substitute.

What happens when group membership changes

Nothing, natively. Jira groups and request participants are not linked. Add someone to a group and no existing request gains a participant. Remove someone and they stay on every request they were already on. Whatever you build has to do the syncing itself.

Option 1: Automation

A rule on Work item created, with a request type condition, can set the Request participants field. Depending on your Automation version you will find this under Edit work item, or as a dedicated action for request participants. Check what your site offers, since I have not confirmed the exact action name on every plan.

Limits for the joiners and leavers problem:

• A rule has no built-in "members of this group" list. The people are typed into the rule, so every team change means editing it.
• It runs on creation. Requests that are already open are not touched when you edit the rule.
• You can add a second rule on a schedule that searches open requests and edits each one. That works, but you have to write the add part, the remove part, and the people list yourself.
• Smart values give you the reporter and the fields on the request. I would not rely on them to expand a group into accounts. Test that on a throwaway request before building on it.
• Every run counts towards your plan's Automation usage.

Option 2: the REST API

This is the flexible route, and the pieces are small:

1. Read the group: GET /rest/api/3/group/member?groupId=...&includeInactiveUsers=false, paged.
2. Find open requests: JQL such as project = SD AND statusCategory != Done AND "Request Type" in ("Invoice question").
3. Read current participants: GET /rest/servicedeskapi/request/{issueIdOrKey}/participant.
4. Add the missing ones: POST /rest/servicedeskapi/request/{issueIdOrKey}/participant with a body of {"accountIds": [...]}.
5. Remove leavers: DELETE on the same path with the same body shape.

Things that will trip you up:

• One person who cannot be a participant (no customer access to that service project, for example) can make the whole POST fail with a 400. Retry the batch one account at a time.
• Rate limits happen on long runs. Honour Retry-After and make the job safe to run again.
• To find joiners and leavers you must keep the last-seen member list somewhere and compare it with the current one. Without that you cannot tell a leaver from someone who was added by hand.
• Decide about leavers on purpose. A person removed from the group might also have been added to a request manually, and a blanket cleanup would drop them.
• Someone may be covered by two rules for the same request type. Removing them because they left one group would be wrong.

It is a perfectly good small script, and it needs somewhere to run and be maintained.

Option 3: an app that does the sync

Full disclosure: we build Group Participants, so weigh this accordingly. Group Participants for Jira Service Management is the script above, packaged as a Forge app. From what it does today:

• Rules per service project and request type, each pointing at one or more Jira groups. New matching requests get the groups' active members as participants.
• An hourly sync looks at open requests (not in a Done status category) that match a rule and adds people who joined the group since the last run.
• Removing people who left is opt-in, because they may have been added by hand. Someone who left one rule's groups but is still covered by another rule for that request type stays on.
• A "Sync open requests now" button runs it on demand, and a manual run re-adds every current member.
• If a lookup fails or is rate limited, the rule keeps its old snapshot, so the next run tries the same joiners and leavers again. It does not treat a failed group lookup as an empty group.
• People JSM will not accept as participants are counted as "could not be added", and one such person does not fail the whole batch.
• A rule covers up to 1,000 open requests per run.
• An agent can also add any group to a single request from the work item's actions menu.
• It works with Jira groups, not organizations, and it does not cover portal-only customers, because JSM does not allow them in groups.
• It stores only its settings and member snapshots, makes no calls outside Atlassian, and runs as its own Forge app, so it does not use your Automation runs.

If your team rarely changes, an Automation rule is enough. If it changes every month and open requests matter, either write the scheduled script with the checks above or use an app. The thing to avoid is a hand-edited list that nobody owns.

For the difference between organizations and participants in more depth, see this guide.

Jira Service Management, Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Option 1: everyone watches the space

Watching a space covers all its pages and blog posts, so a watcher is told about new pages. Each person selects Watch on the space for themselves. Watching is per user account, so a group of 30 people is 30 separate watches.

The catch is how the notification arrives. Open your profile picture, then Settings, then Email:

• Daily Digest collects recent activity into one email a day. On a new account it includes new pages and live docs.
• Content I'm watching decides what is emailed in real time. On a new account only Comments, New blog posts and New whiteboards are on. New pages and live docs is off.

So by default a watcher hears about a new page the next day, in the digest. For real-time emails each person has to switch on New pages and live docs under Content I'm watching. It is a personal setting, so you can't set it for the team.

Option 2: @mention the team or the people in the page

Mentioning someone in a page notifies that person, and it works well for one announcement. The limits: it is manual, it depends on the author remembering, and the mentioned person must be able to see the page. It also does nothing for the next page.

Option 3: Automation for Confluence

Automation for Confluence can run a rule when a page is created in a space. As far as I could verify, the actions include sending an email and posting to Slack or Microsoft Teams, which covers "tell the team about new pages". Check two things in your own site before you rely on it: which recipients the email action accepts (a list of people, or a group), and that the Slack or Teams integration is connected for your site. I did not find an action that makes a group watch a space, so rules are for announcing, not for watching.

The upside is that the message goes out in real time and lands where the team already looks (a channel). The downside is that someone owns the rule and the recipient list, and people who join the team later are only included if the list follows the group.

Option 4: an admin adds the watches with the REST API

An admin can add a watch for another person with the REST API, one account at a time: POST /wiki/rest/api/user/watch/space/{spaceKey}?accountId={accountId}, with the header X-Atlassian-Token: no-check, as a Confluence Administrator or a Space Administrator of the space. A script can loop over a group's members. It is a snapshot, though: joiners are missed, leavers keep watching. I wrote the whole script and its limits in How to make a Confluence group watch a space, so I won't repeat it here.

Option 5: an app that keeps the group watching

Full disclosure: we build Group Watchers, so weigh this accordingly. Group Watchers: Auto-Watch Spaces & Pages for Confluence maps one or more groups to a space or a single page and keeps the members watching:

• It runs right after you change a rule and then every hour.
• Joiners start watching. For leavers it removes only the watches it added, and you can switch removal off.
• People who unwatch are not added back, and watches people already had are never touched.
• It runs on Atlassian's Forge platform and sends no data outside Atlassian.

What it does not do: it doesn't send its own notifications and doesn't change anyone's email settings. A watcher gets Confluence's normal notifications, based on their own settings. So the digest point from Option 1 still applies, and new pages arrive in real time only for people who switched on New pages and live docs.

Which one to pick

• One announcement: @mention, or post in the team channel.
• Real-time heads-up for every new page, in chat or email: an Automation rule on page created.
• Team members should get Confluence's own notifications, and the team changes often: keep the group watching, with a script you maintain or an app.

These also combine well: watching for the personal feed, and an Automation rule for the channel.

Confluence and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

What Jira gives you

• Worklogs: who logged how much time, on which work item, on which day.
• Time tracking fields: Original estimate, Remaining estimate and Time spent on each work item.
• JQL to find the work items in a project, epic or version, and CSV export with their time fields.

Everything is in hours. Jira has no hourly rates and no budget with an amount and a period.

Option 1: export and a spreadsheet

Exporting work items gives you Time spent per work item, but not per person or per day. For a real cost you need the individual worklogs: author, date and time spent.

1. Pull the worklogs with the REST API: /rest/api/3/issue/{key}/worklog per work item, or /rest/api/3/worklog/updated plus /rest/api/3/worklog/list for everything changed since a date.
2. Keep a rates table with one row per person or role, an hourly rate and a start date. When a rate changes, add a row instead of editing the old one.
3. Price each worklog with the rate that applied on its own date: hours times rate. If you only keep the current rate, every rate change silently re-prices past work.
4. Group the cost by project, epic or fix version. For epics and versions, include the time on child work items and sub-tasks.
5. Compare with the budget: spent so far, remaining, share used.

Where the spreadsheet breaks

• It goes stale. Worklogs are added, edited and deleted every day, and work moves between epics and versions. A monthly export is out of date within days.
• Forecasting is manual. "Will the money last?" needs a pace, a run-out date and the remaining estimates of open work priced at your average rate.
• Cost and billing differ. What an hour costs you and what you bill the client are different rates, so you need two tables.
• Rates are sensitive. Most people who should see whether a budget is on track should not see what each person costs, so the sheet ends up shared with very few people.

Option 2: Automation

A scheduled rule can look up the work items in an epic or project and message someone when their time spent passes a threshold you typed in. That is a rough check of hours against an hour budget. For money you still need a rates table somewhere, and dated rates are awkward to keep inside a rule. Rule runs also count towards your plan's Automation usage.

Rules that keep the numbers trustworthy

• Never change a past rate. Add a new one with a start date.
• Decide once what a budget covers (a project, an epic and its children, a version or a JQL query) and whether it is one-off or resets every month or quarter.
• Keep non-billable work out with a label, and apply it to the work under it too.

Option 3: an app that reads the worklogs

Full disclosure: we build Burnrate, so weigh this one with that in mind. Burnrate for Jira reads the worklogs your team already logs and keeps the numbers current.

• A rate card with dated cost and billing rates for a default rate, roles and people. A new rate never changes the cost of past work.
• Budgets in money or hours for projects, epics, fix versions or any JQL query, one-off, monthly or quarterly.
• Pace, run-out date, projected spend and an estimate at completion from remaining estimates.
• A Cost panel on every work item and epic, and reports by project, epic, person or month with CSV export.
• Two Jira permissions decide who manages rates and who only sees budgets.

For one small project and a monthly report, the spreadsheet is fine. When several budgets run at once and rates change, keeping it current by hand is the part that stops working.

More detail in the guide: https://kayabyte.dev/atlassian/guides/jira-project-cost-from-worklogs

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Column limits count the column, not the person

On a board, under Columns, you can set a minimum and maximum number of work items per column. Jira colours the column when it goes over.

• The limit counts every work item in the column, whoever it is assigned to. One person can hold most of a column and the limit still looks fine.
• It is a warning. People can still move work into a full column.
• It counts one board. Someone who works across three teams' boards can be under every column limit and still have ten things in progress.

Column limits help a team see a bottleneck. They do not give anyone a personal limit.

Option 1: a filter and a dashboard

You can at least see who is overloaded.

1. Save a filter with this JQL:

statusCategory = "In Progress" AND assignee is not EMPTY ORDER BY assignee

2. Add a Filter results or Two dimensional filter statistics gadget to a dashboard, using that filter, with Assignee on one axis.

Each person's count is the number of work items they have in progress. This shows the problem. Nobody is stopped, and somebody has to look at the dashboard.

Option 2: Jira Automation

Automation can warn when someone goes over.

1. Trigger: Work item transitioned, to your In Progress statuses.
2. Action: Lookup work items with JQL like assignee = {{issue.assignee.accountId}} AND statusCategory = "In Progress".
3. Condition: {{lookupIssues.size}} greater than your limit.
4. Action: comment, notify the team lead, or transition the work item back.

The gap: the rule runs after the move. The work has already started, people get notifications about a move that is then undone, and the count can be off when two moves happen at the same moment. It is a nudge, not a limit. Each run also counts towards your plan's Automation usage.

Option 3: stop the move itself

To block a work item from starting when its assignee is at their limit, the check has to run on the transition, before the move happens. Jira's built-in validators cannot count how many work items someone already has in progress, so this takes a scripted validator or an app.

Whichever route you take, decide these first:

• Across all projects, or per project? One limit for everything a person does, or one per project for people who split their time on purpose.
• What counts as starting work? To Do into In Progress should count. In Progress into In Review should not.
• Who is exempt? On-call and support rotations often need to pick up urgent work regardless.
• What happens if the check fails? A limit that blocks people when Jira is slow does more harm than good. Let the move go ahead.

Option 4: an app that adds the workflow rule

Full disclosure: we build Personal WIP Limits, so weigh this one with that in mind. Personal WIP Limits for Jira adds a workflow rule you put on the transitions that start work, in company-managed and team-managed workflows.

• When the assignee is at their limit, Jira shows a message such as "Alex has reached the limit of 3 work items in progress" and the work item stays where it is.
• Count across all projects or per project, give projects their own limit or switch them off, and exempt groups.
• Moves between In Progress statuses and unassigned work are never blocked. If the app cannot check, the move goes ahead.
• It stores only its settings and makes no calls outside Atlassian.

If you only want visibility, the dashboard from Option 1 is enough. If you want a limit that actually stops the move, the check has to sit on the transition, and that is the part worth an app or a script.

More detail, including the flow-theory side, in the guide: https://kayabyte.dev/atlassian/guides/jira-wip-limit-per-person

Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

How request participants work

• Request participants is a field on service requests. Everyone in it gets the request's customer notifications and can see and comment on it in the portal.
• It holds people, not groups. Adding a group means adding each member by hand.
• Only people who may raise requests in that service project can be participants. On sites where customers need explicit access, group members without it are rejected.

Atlassian's request for group participants, JSDCLOUD-1268, has collected hundreds of votes over the years and has not been built.

Option 1: organizations

1. In the service project, go to Customers and create an organization, or use an existing one.
2. Add the people to it.
3. Customers in the organization can share requests with it, and agents can share a request with an organization.

The catch: sharing with an organization makes the request visible to its members, but it does not make them participants. Members get one "Organization added" email, and later updates only if they turn notifications on for that request. Organizations are also separate from Jira groups, so somebody has to keep both lists in step.

Option 2: Jira Automation

A rule can set the Request participants field when a request is created.

1. Trigger: Work item created, with a condition on the request type.
2. Action: Edit work item, and set Request participants to the people who should follow it.

That works for a fixed list of people. Automation has no simple built-in way to turn a Jira group into its current members, so the list lives inside the rule and someone updates it when people join or leave. Requests that are already open do not change when the list does. And every rule run counts towards your site's monthly Automation usage, which is limited by plan.

If you are comfortable with the REST API, there is a more flexible route: the service desk API can add participants to a request with one call listing several account IDs, and you can read a group's members with the group/member endpoint. Wire that into a scheduled rule or a script and you get something close to group behaviour. It is also more moving parts to maintain, and it won't remove leavers unless you write that part too.

Option 3: ask the requester

Requesters can add participants from the portal. Fine for one-off requests, unreliable for "this team must always be on it".

Decide these before you automate anything

• Which requests? Usually a few request types per project, not everything.
• New requests only, or open ones too? When someone joins the team, should they be added to requests that are already open?
• What about leavers? Come off open requests, or stay until it is closed?

Option 4: an app that works from Jira groups

Full disclosure: we build Group Participants, so take this one with that in mind. Group Participants for Jira Service Management works with the Jira groups you already have:

• Rules per service project and request type: new requests get everyone in the chosen groups as participants.
• An agent action adds any group to a request from the work item's actions menu.
• An hourly sync adds people who join a group to matching open requests. Removing people who leave is optional, and someone still covered by another rule stays on.
• It stores only its settings and member snapshots, and makes no calls outside Atlassian.
• It runs as its own Forge app, so it does not use your Automation rule runs.

Other Marketplace apps do the same thing, some of them cheaper. I compared a few here: https://kayabyte.dev/atlassian/guides/jsm-group-request-participants-apps-compared

For a fixed team and a couple of request types, an Automation rule is probably all you need. Once the team changes regularly, keeping a hand-written list current is the part that starts to hurt.

Jira Service Management, Jira and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

What the built-in behaviour is

• Each person selects Watch on a page or a space. Watching a space covers all its pages and blog posts.
• Only user accounts can watch. There is no way to add a group as a watcher, so a group of 40 people is 40 separate watches.
• People see what they watch under Notifications, Watching, and can unwatch whenever they like.

So the native options are: ask everyone to click Watch (works for five people, not for fifty), or have an admin set the watches for them.

Option 1: an admin sets the watches with the REST API

Confluence's REST API can create a watch for another person, one at a time:

• Space: POST /wiki/rest/api/user/watch/space/{spaceKey}?accountId={accountId}
• Page: POST /wiki/rest/api/user/watch/content/{pageId}?accountId={accountId}

You need the header X-Atlassian-Token: no-check, and the caller must be a Confluence Administrator, or a Space Administrator of that space. Anyone else can only add a watch for themselves. A watch never grants access, so members who can't see the space are skipped.

Here is a one-time script that adds every member of one group to one space. It needs an API token for your own account, curl and jq:

SITE="https://your-site.atlassian.net"
AUTH="you@example.com:your-api-token"
SPACE="TEAM"          # the space key
GROUP="developers"    # the group name

# 1. Look up the group's ID
GROUP_ID=$(curl -s -u "$AUTH" "$SITE/wiki/rest/api/group/picker?query=$GROUP" \
  | jq -r --arg n "$GROUP" '.results[] | select(.name == $n) | .id')

# 2. Read the members, 200 at a time, and add a watch for each
start=0
while :; do
  page=$(curl -s -u "$AUTH" "$SITE/wiki/rest/api/group/$GROUP_ID/membersByGroupId?start=$start&limit=200")
  for id in $(echo "$page" | jq -r '.results[] | select((.accountType // "atlassian") == "atlassian") | .accountId'); do
    curl -s -o /dev/null -w "%{http_code} $id\n" -u "$AUTH" -X POST \
      -H "X-Atlassian-Token: no-check" \
      "$SITE/wiki/rest/api/user/watch/space/$SPACE?accountId=$id"
  done
  [ "$(echo "$page" | jq -r '._links.next // empty')" = "" ] && break
  start=$((start + $(echo "$page" | jq '.results | length')))
done

A 204 means the watch was added. For one page, use the page endpoint with the page ID from the URL.

Where the script stops

It is a snapshot. Fine for a one-time rollout, but groups change:

• Joiners are not added until you run it again.
• Leavers keep watching, and keep getting emails about a space that is not theirs any more.
• People who unwatched on purpose get added back on the next run, and usually respond by filtering the emails.
• Watches people set up themselves look identical to the ones you added, so a cleanup script can't tell which ones it may remove.

You can put the script on a schedule, but then you also need a record of which watches you added, who opted out and who already watched before. That record is the real work.

Option 2: Automation for Confluence

I looked for a way to do this with Automation for Confluence rules and did not find a built-in "add watcher" action for a group's members, so I would not count on it. You can have a rule send a notification or post when a page is created in a space, which covers "tell the team about new pages" but not "make the team watchers". If you know of a way I missed, I'd like to hear it.

If watchers say they get no email

Before changing anything, check the email defaults. New pages and page edits in watched content go into the daily digest by default, while comments are emailed straight away. Each person can change it under their profile picture, Settings, Email. Updates also show under Notifications, Watching in Confluence itself.

Option 3: an app that keeps the watches in sync

Full disclosure: we build Group Watchers, so weigh this accordingly. Group Watchers: Auto-Watch Spaces & Pages for Confluence maps one or more groups to a space or a single page and keeps the watches in line with the groups:

• It runs right after you change a rule and then every hour.
• Joiners start watching. For leavers it removes only the watches it added, and you can switch removal off.
• People who unwatch are not added back, and watches people already had are never touched.
• It runs on Atlassian's Forge platform and sends no data outside Atlassian.

There are other Marketplace apps for this too, one of them free. I put a comparison on our site: https://kayabyte.dev/atlassian/guides/confluence-group-watch-apps-compared

If your group is small and stable, the script above is enough. The app earns its place when people move around often and you don't want to own the bookkeeping.

Confluence and Atlassian are trademarks of Atlassian. Kayabyte is independent and not affiliated with or endorsed by Atlassian.

Wix Stores has one price per product and no wholesale mode. Wix's own suggestion for trade prices is a members-only page with duplicated products at wholesale prices. That works for a small range, and it gets heavy as the range grows. Below is the built-in setup first, what it can't do, and then an app that applies a group price to the products you already have.

What does Wix offer for wholesale prices?

Wix describes the workaround in Creating restricted store pages:

1. Duplicate each product you want to sell wholesale, and give the copy its wholesale price.
2. Put the copies in a new category, for example "Wholesale", and create a store page that shows only that category.
3. In the editor, open Pages & Menu, open the page's settings, and under Permissions choose Site members.
4. In your dashboard, go to Signup & Login Security and choose Only people I manually approve, so you decide who becomes a wholesale member.
5. Hide the wholesale page and its products from search engines.

Things to know before you build on it:

• The wholesale products are separate copies. Prices, photos, descriptions and stock have to be kept in step in two places.
• Retail and wholesale shoppers browse different pages, so a trade customer who forgets to use the wholesale page pays the retail price.
• Wix points larger B2B shops to a dedicated wholesale app.

Can I use a discount or coupon instead?

Wix Stores has coupons and automatic discounts under Marketing. They give a percentage or amount off, with conditions such as a minimum order or chosen products.

Coupons can't be limited to certain customers. Wix's limiting coupon usage options cover the products, an end date, the total number of uses and one use per customer, so a plain coupon code can be shared or guessed. Automatic discounts can be limited: Wix's automatic discounts help describes an eligibility setting where you choose a specific contact with a label. So a label-based percentage discount is possible without an app. It is one discount per rule, and it has no groups with different prices, no fixed price per product and no minimum order tied to a group, which is where the section below starts.

Where the built-in options stop

• Several trade groups managed in one place, on the same products retail customers buy, with no duplicates.
• Different groups with different discounts, such as 20% for resellers and 30% for distributors.
• A discount for one collection, such as 40% off the whole accessories range for trade.
• A fixed trade price for one product, such as 8.50 each, whatever the retail price.
• A minimum order before trade prices apply, such as a cart of at least 300.

Mark your wholesale customers with a contact label

Whatever you use, you first need a way to tell Wix who is wholesale. Contact labels are the simplest. Wix explains them in Creating and using contact labels:

1. In your dashboard, go to Contacts.
2. Click the More Actions icon, then Labels, then + Add Label. Name it, for example, "Wholesale", and click Done.
3. To label a customer, open the contact, click Labels, then + Add Label, choose "Wholesale" and click Add.

A customer has to be a site member to be recognised before checkout, so ask trade customers to sign up and log in, and approve them yourself.

An app that applies group prices

Full disclosure: I built Wholesale Prices & B2B Groups. You create a group, give it one or more contact labels and choose its pricing: a percentage off the whole store, off chosen collections or products, or a fixed price per product, with an optional minimum order subtotal. A logged-in member whose contact has the label then pays the group price in the cart and at checkout, and sees it next to the regular price on the product page. Everyone else sees your normal prices, and you keep one set of products.

What to know before you rely on it:

• The buyer must be logged in as a site member whose contact has the label. A trade customer who isn't logged in pays the retail price.
• The price line shows on the product page only, not in product grids or category pages. The cart and checkout always show the discount.
• Only one automatic discount applies per order, and the best price wins. Overlapping groups or a store-wide automatic sale don't add up.
• If the app can't check a customer in time, the customer pays the normal price and the sale goes ahead, so a slow check never blocks an order.
• Coupon codes a customer types in come off on top of the group price. We checked this in a live cart: the group discount and the coupon both showed, and the coupon was taken off the already reduced price. Only automatic discounts compete with the group price.
• The free plan has 1 group with one store-wide percentage. Collection and product prices, fixed prices, unlimited groups, a minimum order and a "log in to see your price" line for guests are on the paid plan.
• The product page price line needs a site built in the Wix Editor.

It's on the Wix App Market.

FAQ

Can I show wholesale prices only to approved customers? With the built-in setup, put wholesale products on a members-only page and approve members yourself. With the app, the group price shows only to logged-in members whose contact has the label; guests see the normal price.

Do I need duplicate products for wholesale? Not with the app. Group prices apply to the products you already sell. With the built-in setup, yes.

Does the group price show in product lists? No. The app shows the price line on the product page, and the cart and checkout show the discount. There is no slot for it in product grids.

Can a customer be in two groups? Yes, but only one automatic discount applies per order, and the best price wins. A coupon code the customer types in comes off on top.

Do I need a paid plan? One group with a single store-wide percentage works on the free plan. Pricing per collection or product, fixed prices, more groups and a minimum order need the paid plan, which has a 14-day free trial.

Wix pages last checked: 17 October 2026. App details: 31 October 2026.

Related guides

• Wix wholesale minimum order: different rules for wholesale and retail
• Minimum order and quantity limits on Wix: every option compared
• Wix Stores minimum order quantity, per product or category
• How to let customers choose a pickup time in Wix Stores (for wholesale bakeries, florists and food shops that collect orders by time slot)

A bakery, a florist or a farm shop needs to know when the customer is coming, and how many orders it can have ready for each hour. Wix Stores has a store pickup option, but as far as I could find it has no setting for the customer to choose a pickup time. Wix does let customers choose a delivery time slot for local delivery. Below is what the built-in options do, where they stop for pickup, and an app that adds a time picker with a limit per slot.

Does Wix Stores let customers choose a pickup time?

The pickup option is described in Wix's About shipping, delivery and pickup article: it lets local customers pick up orders in person from one or more of your physical locations, and you start by selecting Pickup in your shipping settings. The article describes no time or date choice for pickup. Wix's feature request page has a request for a pickup time that had 157 votes when I looked on 12 October 2026, so merchants are asking for it. Check the current Wix help pages before you rely on this, because Wix changes its checkout often.

What you can do without an app:

• Add your opening hours and instructions to the pickup option, so customers know when they can come.
• Ask for the time after the order, by phone, email or a message. It works at a few orders a day and gets slow beyond that, and nothing stops two customers booking the same hour.

Can customers choose a delivery time slot?

Yes, for local delivery. Wix's local delivery help article describes a Delivery time slots option: you pick the days you deliver, set when your delivery hours start and end, and add up to 8 time slots a day. Customers then choose their preferred slot from a calendar at checkout. You can offer same-day delivery, next-day delivery or delivery in two or more days, and set a cut-off time for same-day and next-day orders. To see which orders go where, add the Delivery time and Delivery method columns to the Orders tab.

That covers delivery. The help article describes days, hours and cut-offs. It does not describe a limit on how many orders one slot can take, and it does not apply to the pickup option, so a pickup-only business gets no time choice from it.

Setting up slots with a capacity for pickup

If you need pickup times and a cap per slot, the choices are a time picker app or a booking app. Booking apps are built for appointments, not for baskets in a store checkout. A slot app sits in the checkout delivery step and fills the gap.

What to look for in any of them:

• Does the picker appear for the pickup option, and does it show slots as full?
• Is the chosen time visible on the order, so you can prepare it?
• Can you set opening hours per weekday, a lead time (earliest slot) and a cut-off?
• What happens to the seat when an order is canceled?
• What does the customer see if the app is slow? A broken picker must not block sales.

An app for pickup and delivery time slots

Full disclosure: I built Pickup & Delivery Time Slots. You set opening hours for each weekday, a slot length from 5 to 480 minutes and how many orders each slot takes. In the checkout, under the delivery options, customers choose a day and a slot. A full slot is shown as Full and cannot be picked. The chosen time appears in the checkout summary and on the order page as "Pickup time" or "Delivery time", and the app's dashboard page lists upcoming orders by slot with how full each one is.

What to know before you rely on it:

• Your store needs a pickup option in the shipping settings. The picker appears when the customer chooses it.
• The time is required at Place order, not at Continue. The Continue button cannot be blocked, so the customer sees the picker, and Place order stays disabled with a message until a time is chosen.
• The time is also in the buyer note. The buyer's order confirmation email and Print order show it as a note line ("Pickup time: ..."), and the order page, the app's list and the prep list show it too.
• If the app's service is slow or down, the customer can continue without a time and the order is listed under "Orders placed without a time", so a sale is never lost. The same applies when every slot offered is full.
• Canceled and fully refunded orders free their seat.
• The free plan is pickup only, one schedule and the first 3 slots of each day, with a limit per slot counted in orders. Delivery slots, unlimited slots, blackout dates, lead time, a cut-off after which tomorrow's slots close, limits by item count and the printable prep list are on the paid plan, which has a 14-day free trial.
• It was tested on the one-page Wix Stores checkout. Try it on a test site and place a test order first.
• The dashboard is in English; the picker shows in eight languages.

It's on the Wix App Market.

FAQ

Can customers choose a pickup time in Wix Stores without an app? As far as I could find, no. The pickup option has no time choice. Local delivery has delivery time slots with a calendar, but it does not cover pickup.

Does Wix limit how many orders fit in one delivery time slot? Wix's local delivery help article describes days, hours and cut-off times, and does not mention a limit per slot. Check the current article, and test with two orders for the same slot.

How do I show the pickup time on the order? With an app, the chosen time is saved on the order. In the Wix dashboard open the order and look for "Pickup time". The same line is added to the buyer note, so the confirmation email and Print order show it as well.

Can I stop customers choosing today's slots too late? For Wix's own delivery time slots, you can set a cut-off for same-day and next-day orders. With the app on its paid plan, you set a lead time (the earliest slot is a set number of hours away) and a cut-off after which tomorrow's slots close.

Does it work for delivery too? On the paid plan you tick which delivery options also ask for a time. The free plan is pickup only.

What if the customer does not pick a time? Place order is disabled until they do. If the app's service cannot answer in a few seconds, they can continue without a time and the order is flagged on the dashboard.

Wix pages last checked: 31 October 2026. App details: 31 October 2026.

Related guides

• Minimum order and quantity limits on Wix: every option compared
• Wix shipping rate apps compared
• Add a handling, packaging or service fee at Wix checkout

Wix has no built-in auction feature. Wix Stores sells products at a fixed price, and the request to sell products by auction has been open on Wix's help center, with the status "collecting votes". To run an auction on a Wix site you either do it by hand with the tools Wix already has, or add an auction app. This guide starts with the built-in ways, what each can and can't do, and then the app I make.

What Wix does on its own

Wix's own help page for the request says Wix Stores doesn't support selling products by auction, and points to a third-party app as the workaround (Wix request page). What you can build from Wix's normal parts is a manual auction. Someone, you, has to do the work that an auction system does automatically.

Option 1: a Wix form for bids, and you run the auction

Add a form to the page for each item, with fields for name, email and bid amount. Wix Forms emails the site owner for every submission by default, and you can change who gets the notification (Wix guide). All submissions are also kept in a table where you can view, edit and export them as a CSV file (Wix guide).

How it works in practice: you close the form on the end date, read the highest bid, and email the winner.

What it can't do:

• Bidders can't see the current price. Submissions go to you, not onto the page, so it works as a sealed-bid sale, not a live auction. Showing the top bid means editing the page by hand.
• Nothing checks the bid. A bid below the current top, or a typo, still arrives. You sort it out afterwards.
• No end time. You have to remove or hide the form yourself when the auction closes.
• Fake bids. Anyone can type any email address.

Fits best: a one-off sealed-bid sale of a few items, where you are happy to do the admin.

Option 2: a product page plus manual updates

You can list the item in Wix Stores and change the price by hand as bids come in, or hide it when the auction is over. Wix lets you hide a product from the store with the Show in online store toggle, and mark it out of stock (Wix guide). Wix can't hide a product automatically when it sells out (Wix request).

What it can't do: it is a fixed-price sale, so the first person to check out wins at the price shown, not the highest bidder. Use it only for the winner's payment, for example by creating a product at the winning price after you've picked the winner.

Option 3: Pay Links for the winner's payment

Once you know who won, a Wix Pay Link is a quick way to collect. You create a custom amount link in your dashboard, and can set an expiry date and a payment limit. Each payment creates an order (Wix guide). Your site needs to be published and upgraded, with a payment method set up.

This solves payment only. It doesn't run the bidding.

Option 4: embed an outside auction system

Add Elements > Embed Code > Embed HTML (or Embed a site) puts code or a page from another service on your site. Wix says embeds show only over HTTPS, that some sites don't allow embedding, that the embed is an iframe that doesn't resize responsively, and that Wix doesn't support external code (Wix guide). The auction itself, the bidders and the payment then live on the other service, not in your Wix checkout.

Fits best: you already use an auction platform and just want it shown on your site.

When a manual auction stops working

Manual setups work for a few items. They get hard when you need:

• the price and a countdown visible to every bidder, updating live
• a rule for the smallest allowed bid
• protection against last-second bidding
• bids that can't be made under someone else's email
• one place to see every bid and who won
• an automatic email to the winner with a way to pay

That is the point to look at an auction app. The comparison of Wix auction apps lists the ones on the App Market.

What to check in any auction app

1. Do bidders have to create an account? Some apps ask visitors to sign up as site members, which puts people off bidding.
2. Does the countdown run to the second? And does it update without a page reload?
3. Is there anti-sniping? Look for an end time that moves when a bid arrives at the last moment.
4. How does the winner pay? In your own Wix checkout, or somewhere else? With your shipping rates and taxes?
5. What happens when the winner doesn't pay? Wix has no way to hold a card in advance, so every app needs a plan for this.
6. Can you remove a bid or block a bidder?
7. What does it cost, and are there fees on sales?

Our app: Live Auctions & Bidding

I make Live Auctions & Bidding, a Wix app built around that checklist (disclosed: it's mine).

• Guests bid with a name and email. A one-time email check on the first bid stops fake bids, and there is no sign-up.
• Price and countdown update live, to the second.
• Soft close: a late bid moves the end by a few minutes. Sealed bids for silent auctions.
• When time runs out, the highest bidder gets an email with a link to pay at your own Wix checkout, with your shipping rates, taxes and payment methods.
• A dashboard shows every bid, lets you remove a bid or block a bidder, and shows who won and whether they paid. Bidders are saved as contacts with an "Auction bidder" label.
• Pro adds a hidden reserve price, Buy now, max bids (the app bids up to a bidder's limit), scheduled starts and offers to the next bidder when a winner doesn't pay.
• The bidder page and emails come in 11 languages. There is no commission on sales.

The Free plan runs one auction at a time with unlimited bids. Pro is $11.99 a month, or $9.99 a month billed yearly, with a 14-day free trial. It has no reviews yet. See it on the Wix App Market.

Before your first auction

• Connect a payment method and run a test checkout, so the winner can pay.
• Write your rules where bidders see them: the end time, the payment deadline, shipping or pickup, and what happens if a winner doesn't pay.
• Place a test bid from a second email address, and read the emails bidders will get.
• Decide on the reserve and starting bid before you publish. Changing them after bids arrive upsets bidders.

FAQ

Does Wix have a built-in auction feature? No. Wix's help center lists selling products by auction as a request that is collecting votes, and points to a third-party app.

Can I run an auction with Wix Stores alone? Not as a real auction. Wix Stores sells at a set price, so the first customer to check out gets the item. You can use Stores or Pay Links to collect payment from a winner you pick yourself.

Do I need a paid Wix plan? To take payments, yes. Wix says your site needs to be upgraded and have a payment method for online payments, including pay links.

How do I stop people bidding in the last second? Use an app with a soft close, so a late bid extends the end time. A manual setup can't do this.

Can bidders bid without signing up? It depends on the app. Ours takes a name and email and checks the email once.

Last checked: 30 October 2026. Spotted something out of date? Write to support@kayabyte.dev and I'll fix it.

Related guides

• Wix auction apps compared (2026)
• Run a silent auction fundraiser on Wix