How to price reseller services: markup, price lists and customer-specific rates

How to price reseller services comes down to two separate decisions: what markup you add to your wholesale cost, and whether every customer pays from the same price list, from a list aimed at their type of customer, or from a price agreed with them alone. Markup and margin describe the same profit with two different percentages, so working out one from the other is a common place to go wrong. Changing a price later needs its own plan, because a markup you edit today can reach a renewal a customer already expected to cost less. The rest of this guide works through each of those in turn, then what the mechanics look like inside ResellerHQ.

What is a markup, and how is it different from a margin?Copy Anchor Link

A markup is added to your cost; a margin is taken out of your price. Shopify states the two formulas plainly: margin is "(Selling price - COGS) / Selling price x 100" and markup is "(Selling price - COGS) / COGS x 100" - the same subtraction on top, divided by two different numbers underneath (Shopify, published 16 September 2026).

Shopify's own worked example shows how far apart the two can land. An item that costs $40 and sells for $50 earns $10 of profit: "$10 profit / $50 selling price x 100 = 20%" is the margin, and "$10 profit / $40 cost x 100 = 25%" is the markup (Shopify). Same item, same $10, two different percentages, because one divides by the smaller number and one by the larger.

The gap between markup and margin widens as the percentage grows, and it is simple arithmetic once you have both formulas: a price is cost multiplied by (1 + markup), so margin always works out to markup divided by (1 + markup).

A 100% markup is a doubled price, not a 100% margin; at a 100% margin the cost would have to be free. If you are told to "hit a 30% margin," the markup that gets you there is higher than 30%, not the same number with a different label.

Domains are where this catches resellers out in dollar terms, not just in percentage: the markup on a domain can look generous while the actual dollars of profit are small, because the wholesale cost itself is small. How to start a domain and email reselling business works through that with published wholesale and retail prices; the lesson carries over to anything with a low unit cost, including a single rented phone number or a single mailbox seat.

How to price reseller services for different customers: one price, a list, or an agreement?Copy Anchor Link

These are three different answers to "what does this customer pay," and a reseller usually needs more than one of them at once.

One price for everyone is a single markup (or a single fixed price) that every customer sees, with no per-customer exceptions. It is the least to set up and the easiest to explain, and it suits a business where customers buy similar things in similar quantities. Telnyx's own number pricing page shows this as its base case: a US local number is "$1.00" a month "Pay as you go," the same for anyone buying fewer than 50 a month (Telnyx) - one number, one price, whoever is buying it.

A price list by customer type adds rules on top of a default markup for the groups that should pay differently: a higher-volume customer, a different product mix, a different currency. Telnyx's own page shows the mechanic in its simplest form, as a sequence of brackets rather than one flat rate. It states that "if you purchase more than 50 local or toll-free numbers per month, you'll automatically receive a discount," and tiers the price per number per month from there:

(Source: Telnyx.) Each "Next" bracket is counted on top of the numbers before it, not from zero - so this is a published rule for a volume tier, not a one-off negotiation. The same shape of tiering shows up a level further up the chain at Vendasta, where a reseller's own subscription tier earns progressively better wholesale pricing: its page describes "BETTER" wholesale pricing at the Professional tier and "EVEN BETTER" at Premium, before the reseller marks anything up for its own customers (Vendasta). A price list by customer type works well once you can describe the exception as a rule - "agencies get this rate," "ten or more seats get this rate" - rather than something true of one account only.

A price agreed with one customer is a rate that would not make sense written as a rule for everyone, because it belongs to that one relationship: a volume commitment, a renewal a customer has already budgeted around, or a concession tied to a contract term. Namecheap's own FAQ describes exactly this shape one layer up the chain: ordinary API pricing is the same for everyone, but "once you get 50+ domains in your account, we can set a special pricing for your account which will be working for renewals as well as new registrations" (Namecheap) - a rate for one account, not a tier anyone can read off a published list.

Most resellers end up running all three at once: a default list for everyone, a handful of rules for the groups that are genuinely different, and an agreed price for the few accounts that negotiated one.

How do you change a price without surprising a customer who already has something?Copy Anchor Link

A markup is easy to edit and a renewal is easy to forget, which is how a reseller ends up raising a price on a customer who had no warning it was coming. The question to answer before you touch anything is whether the new price should apply the next time something is bought, or only once what a customer already holds comes up for renewal.

Two vendors who sell at scale through resellers handle this by protecting what a customer already has, in writing. Google's reseller agreement spells out a grace period for its own price changes: "any price change will become effective: (i) 30 days after the Price Change Notice Date; or (ii) for certain term commitment orders with fixed price commitments, on renewal of the order" (Google Workspace reseller agreement) - so a fixed-price term a customer already holds is left alone until it is due to renew anyway, and everything else gets 30 days' notice first. Microsoft's July 2026 Microsoft 365 price increase worked the same way from the customer's side: "Existing customers remain on current pricing until renewal" (Microsoft Licensing), even though the new list price applied to new orders straight away.

Both examples point at the same two decisions:

1. Whether existing items follow the new price or keep the old one. New purchases almost always follow a new price immediately; what is debatable is a renewal of something bought under the old one.
2. How much warning a customer gets before the change reaches them, and in what form. Google's answer is a minimum number of days; Microsoft's is "not until your own renewal," which can be months away for an annual term.

Neither of those is automatic. A reseller who wants to raise a markup without surprising anyone needs to know, before saving the change, how many customers and items it touches, and needs a way to tell those customers in advance if that is the plan. What that looks like inside ResellerHQ is next.

What does this look like in ResellerHQ today?Copy Anchor Link

Customer pricing is where all of this lives in ResellerHQ, and the short version is that your wallet is always charged the wholesale price, while a price list, an agreed price or a price fixed on an item sets what the customer pays for the same purchase.

A price list is a markup with rules for the exceptions. markupBps is the markup over wholesale for anything no rule covers, in basis points - 2000 is 20% - and rounding rounds the worked-out price up to a whole dollar, the next amount ending in .99, or not at all. A rule can narrow by product, a domain ending, a country, a licence plan, a volume tier, or whether it is a first purchase or a renewal, and the narrowest rule that fits an item sets its price. Your first list is the default, and every customer without a list of their own is priced from it (customer pricing).

What sets a price, in order, is five levels, and every sale records which one applied:

1. override - a price fixed on the item itself: one domain, one licence, one number.
2. contract - a price agreed with that customer, while it is in date.
3. list (held) - the last price they paid for that item, when their list holds renewals.
4. list (rule) - a rule on their price list.
5. list (markup) - the list's own markup, or none when there is no list at all, so the customer pays wholesale.

Putting a customer on a list is a single PATCH /customers/{id} call with a priceListId, or the same change from the customer's own page in the dashboard. An agreed price for one customer is a set of contract rules on PUT /customers/{id}/contract-rules, each shaped like a list rule and each able to carry startsAt and endsAt; a contract rule that fits a purchase and is in date beats everything on the customer's list, however narrow the list's own rule is. A price fixed on one item is set with a PATCH on the domain, licence or number itself, as customerPrice, and it beats both the list and any contract rule for that one item from then on. All three can be set from the dashboard as well as the API, for a customer who already has an account (customer pricing).

Where the customer's price shows up: the catalogue routes - domain search, the domain check, the licence plans and the number offers - all return the customer's price alongside your wholesale price when you pass a customerId, so you can show it before anything is bought. POST /price-lists/quote works out what a customer would pay for items at prices you give it, without buying anything, which is the way to preview a volume tier. Every purchase and renewal made with a customerId records a sale: what it cost you, what the customer pays, and the level and rule that set it. An invoice copies each sale's price at the moment it was made, so it reads the same for good even after a list changes, and GET /sales/summary reports your profit and margin from those recorded prices, not from whatever the list says today.

Avoiding the surprise described above is two tools working together. POST /price-lists/{id}/impact takes the change you are considering and answers with how many customers and items it touches and, for a sample of up to 50, the unit price of their next renewal now and after the change - contract rules, item prices and held renewals are all accounted for, so anything already protected shows no change. Saving a change that moves a price sends a price_list.updated webhook naming what changed and who it affects, which is the moment to tell customers. Setting a list's renewals to hold (instead of the default, follow) keeps every existing item renewing at what it last sold for, even after the list's markup moves; only first purchases follow the new list. What is not built yet: a future effective date or a built-in notice period for a list change - it applies from the next purchase or renewal as soon as you save it, so giving customers notice today means telling them yourself and making the change on the day it should start (customer pricing).

A reseller mixing all three models from the earlier section can do it from one account: no list at all for wholesale, no-markup customers; a default list with volume rules for most customers; and a contract on top for the few who negotiated terms of their own. The wallet side of this - what gets charged, held and captured when an order is placed - is covered in prepaid wallet billing for resellers. Once the markup is set, pricing what you resell: cost, markup, margin and the invoice at the end of it works through the arithmetic that comes after it - seat costs, break-even, recurring revenue and the notice a price increase needs - with a free calculator for each sum.