Ask HN: Payment processing within my app, without losing (too much) money? | Hacker News Reader

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

6 pointsslater6 comments

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.

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?

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com