3 ms·

Sorry my coffee hasn't kicked in yet, but I am a little confused here. How do you intend to make money on your app or is this a free service? If your app is a

Sorry my coffee hasn't kicked in yet, but I am a little confused here. How do you intend to make money on your app or is this a free service? If your app is a paid service service, then you have two choices. First you can build in the processing fees to your monthly fee (or however you plan to charge). You can base your fee on the expected number of registrations and go from there. The other choice would be to charge an administrative fee on top of each registration to the exhibitor or participant. The problem with this method is that if I am an exhibitor why am I going to pay $X through your service versus going directly to the show and paying $Y? Short answer is that you somehow need to build the cost of the payment processing into your pricing. Whether that is through an added administrative fee or built into your monthly pricing.

slater 16y ago
Sorry, I should have mentioned that this will be a paid service, billed monthly. I wanted to come up with a tiered, flat fee, except that won't work with the above scenario. If I price my app at, say, $100 per month, the minute one paying client's in-app processing fees cost more than that, I'm losing money. I suppose I could bill my customers the incurred fees at the end of each billing cycle, but that would probably put off some customers, as they would be left scratching their heads as to why they have to pay $100 per month, then get ANOTHER bill for fees.
- jeffmould 16y ago
  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.
- nkurz 16y ago
  I'm a fan of interchange-plus pricing for credit card processing, and your suggested approach of just adding it as a fee makes fine sense to me: $100 plus credit card fees with no markup. It's honest and transparent. If for some reason that is too complicated for your market, $100 plus 5% reads as simple even if it ends up costing them a bit more.

slater 16y ago

Sorry, I should have mentioned that this will be a paid service, billed monthly. I wanted to come up with a tiered, flat fee, except that won't work with the above scenario. If I price my app at, say, $100 per month, the minute one paying client's in-app processing fees cost more than that, I'm losing money. I suppose I could bill my customers the incurred fees at the end of each billing cycle, but that would probably put off some customers, as they would be left scratching their heads as to why they have to pay $100 per month, then get ANOTHER bill for fees.

jeffmould 16y ago
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.
nkurz 16y ago
I'm a fan of interchange-plus pricing for credit card processing, and your suggested approach of just adding it as a fee makes fine sense to me: $100 plus credit card fees with no markup. It's honest and transparent. If for some reason that is too complicated for your market, $100 plus 5% reads as simple even if it ends up costing them a bit more.