If that is the case I would build the tiered pricing based on the number of exhibitors (or participants) each tier can handle. You should be able to closely est

If that is the case I would build the tiered pricing based on the number of exhibitors (or participants) each tier can handle. You should be able to closely estimate what your processing fees are going to be for a set number of registrations. The problem with this method is that some of your customers will most likely be purchasing tiers that are out of line with their registrations. For example if you have 3 tiers: one tier for 100 exhibitors, one for 500, and one for 1000, then your customers will be bound to registering for tiers that may be out of line with the number of exhibitors they plan on having. You may be able to offset this a little two ways. First if you know your target market well enough that you know approximately how many exhibitors are at each conference you could plan your tiers based on those numbers. The other way, although it requires development on your behalf, but is a little more customer friendly, would be to do away with tiered pricing, and build a cost estimator into your app. Your customers could come to the site, fill out all the information including an estimate of number of exhibitors they will have, then your app would give them an estimate of the cost. You verify their payment for the estimated registrations, but do not charge them at this point, then when all the exhibitors have registered, you bill them based on their actual number of registrations.