0
votes

I am working on a software that is to be used by businesses which make about $0.5mil revenue per year. I would like to incorporate into the software the option for my users to accept card payments from their clients. So far it seems I have the following options:

  1. Manage multiple merchant accounts on behalf of my clients, however this has a few drawbacks. I would, for example, like to charge some small fee to cover the costs (about 0.1%) which I cannot accept if the payment to my user doesn't go through some stage that I can control where I can deduct the fee and send it my way. Also, about 50% of the mentioned revenue is paid for by credit or debit cards so a volume of $250,000 might not be enough to cover the fees set by the account provider.

  2. Send everything through a merchant account that I control and then distribute the funds to the users. This, however, seems like a very small scale solution at best with the average number of payments per user per day being around 15.

The end result should be that the user enters a price in the software, this gets sent to a card reader where the user's client inserts their card and makes the payment. The amount charged includes all the fees associated. The amount paid will then be sent to some merchant account where my fee will be sent to me and the merchant fee will be deducted, the rest will be sent to my user's account. The whole point being that the user doesn't have to bother with setting up merchant account or card reader and simply gets a card reader from us which connects to the software and can immediately accept payments.

I sincerely hope I am missing something but I would appreciate any help with finding a way how to charge clients of my users and take some small fee.

1
Might Paypal's Adaptive Payments work for this scenario? developer.paypal.com/docs/classic/adaptive-payments/…Pekka
Paypal's Adaptive Payments gets one thing right - multiple recipients allowing me to deduct the fee. However, they also need both the recipient (my user) and the sender (my user's client) to have paypal accounts which is a problem and furthermore, they only support online payments rather than payments using a card reader. Since my users conduct business in store and their clients pay in person, it would not be reasonable to expect an online payment.Denis Balko
Hmm, I think there's credit card processors these days that do even very small volumes (at a cost, of course). If you set up an account for yourself you'd likely be drowning in tax paperwork. Can't make a recommendation as to who to pick, thoughPekka
Thanks, just FYI I am currently looking into circumventing merchant accounts completely and using Payworks to accept cards and send money to one general Stripe account and then using Stripe Managed Accounts to distribute these payments minus the fees I leave in the account to the respective receivers. If it turns out to be a successful approach then I will put it up here as an answer, but there is a lot of testing to be done on that.Denis Balko

1 Answers

1
votes

So as it turns out, the best way to do this is using Stripe after all. If anyone is ever concerned, this is how I solved the problem.

Stripe is currently rolling out Managed Accounts of their Stripe Connect which can be used to effectively manage Stripe accounts for my customers. Therefore, once a user registers for my payment program, I create a managed account for them without the user knowing at all. For incoming Stripe payments I can then use the destination property as the id of the account where the money should go and specify an application fee which will be charged to my own account.

From there on the only problem to solve is that Stripe only supports online payments which can be overcome by using for example Payworks, however so far their service has been pretty terrible so this may be a weak point in the system.