

Ask HN: Payment processing within my app, without losing (too much) money? - slater

Example: Let's say I'm building a show/exhibition management app, allowing you to manage floor space, exhibitors, course participant registration, etc. To register a booth, a potential exhibitor will have to pay a fixed amount of money, let's say $100 for simplicity's sake. Except that with each payment, I as the service provider will lose n% of that payment in processing fees, depending on which payment gateway (Paypal or otherwise) I choose. Which results in me not being able to pay my app's customers the full amount due to them. The same scenario comes up for the show participants' payments, if I want to have that billing process administrated through my app, too.<p>So my question is, do I just tack on the % as a service fee to my customers, resulting in my customers only receiving, say, $95 instead of the $100 for booth registration? Or are there other ways to tackle this issue?
======
terrellm
A friend of mine has a similar type of software where he is somewhat of a
middle man. He charges the company $x base + y% of the transaction. His
customer is required to have their own merchant account and his service just
processes through their merchant account. The $100 would never run through his
account.

Depending on the nature of your business, another idea would be to charge a
convenience fee to the exhibitor, but having exhibited at tradeshows for many
year I would find that annoying. However, it wouldn't stop me from exhibiting.
Annoyances are par for the course for anyone who has ever exhibited at a
tradeshow managed by someone like Freeman.

If a customer is shocked that they will only receive $95 of a $100 transaction
for the value you add, then it may be time to re-evaluate how you communicate
your value or find a new customer.

------
jeffmould
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
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
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.

------
eof
Well how do you make money? At some point you have to be charging more than
they are receiving, right?

