What is a marketplace?

According to Wikipedia, an online marketplace (or online e-commerce marketplace) is a type of e-commerce site where products or service information are provided by multiple third parties, whereas transactions are processed by the marketplace operator. Online marketplaces are the primary type of multichannel e-commerce.

To simplify, imagine that your application is taking payment from one customer, and you have to re-distribute the money (minus your commission) to one or multiple providers.

For example:

1. Customer Joe buys a design for £100 from yourdesigmmarketplace.com.
2. The design was provided by Bloggs.
3. The commission on all sold designs received by yourdesignmarketplace.com is 10%.
4. Bloggs should receive a payment of £90 to his bank account.

Prerequisite

• We will need to integrate our marketplace system in a Ruby on Rails application.
• We are looking for developer-friendly API / Gems.
• The marketplace is UK-centric, so it needs to allow UK sellers to receive their money.
• We know that the sellers are not going to be tech-savvy, so the solution needs to be as simple as possible for them.
• The application is at an MVP stage, so the cost needs to be decent.

What we found

Unfortunately, there wasn’t a clear cut option on which provider to use, and it will all depend the type of resellers you have. For example, we know that our client target base won’t be techsavvy, so the less friction, the better.

Stripe connect

Stripe made it onto the list. But, even if it’s the simpler solution to start accepting payments in your application, the fully-managed marketplace idea is not yet available in the UK.

If we were in the US, we could use Stripe Connect in combination with Stripe managed accounts. This feature let’s you create Stripe accounts on behalf of your sellers, and manage your marketplace payments directly via Stripe.

This feature is in Beta and is not available in the UK.

In the UK, you will have to use Stripe connect in combinations with Stripe standalone accounts. This means that our resellers would have to open a Stripe account themselves, before we can connect them to our own Stripe account. The money would then be transferred across to their Stripe account. Then Stripe will transfer the money on a daily basis to their bank account.

On top of that clunky process, you can’t send money to multiple connected accounts at once, so if you’re handling a basket with multiple items from multiple sellers, you will have to make numerous API calls.

Paypal Adaptive Payments

Similar to Stripe Connect, Paypal Adaptive Payments requires the seller to have a Paypal account, which is already more likely than them having a Stripe account.

Paypal Adaptive Payments allows you to slip a purchase payment, minus calculated fees, between multiple sellers. Please note that a traditional marketplace will use their Chained Payments solution, and it’s therefore limited to a maximum of 9 receivers.

Interestingly, we’ve had to develop that feature for our existing client, Patternbank and the integration was pretty straightfoward.

Mangopay

Disclaimer: We’ve only looked at the Mangopay Gem but never actually tried to integrate it, and our review is based on their documentation.

MangoPay seems to offer what we want in our scenario. It has an escrow type of functioning where when a buyer pays, it will hold the money, and when the item is delivered, the money will be transferred to the seller account.

I’ve found their documentation a bit confusing, and their pricing very high, but it’s definitely an option to consider.

CSVs, BACS and CHAPS are on a boat

Yes, you read that right, CSVs files are actually a viable option. Let me explain.
While we were trying to find solutions that would solve the money sending problem for us using shiny APIs, we kind of forget to look at the most obvious places: the bank themselves directly.
Most major banks will allow business bank accounts to send mass BACS or CHAPS payment via an uploaded CSVs. The only thing your application has to do is collect the sellers bank details and be able to generate a CSVs with the amount due for each seller and associated bank account.

If you plan to go down this route, please consider a few things:

1. Make sure you store the fees and percentages somewhere in your transaction line, at the moment the buyer is doing the purchase. This ensures that if you change these figures right before the money is sent, you will be able to calculate the correct sums. I know it’s only good practice, but you would be surprised at the amount of codebases we’ve seen that don’t respect this kind of basics method.
2. Since, for payment to the seller, you are only storing their bank details, you don’t need to be PCI compliant. Now, please don’t store this information clearly in your database, but have look at our encrypting secrets with Rails. At the very least you should use the attr_encrypted gem.

The downsides to consider are:

1. The CSV downloads and uploads will have to be a manual operation (maybe once or twice a month depending on your needs).
2. There is no real way to tell if someone has been paid inside the application.

What should we go for?

Well, we are still looking around for a perfect solution, but if we fail at finding it, I think we will go with a combination of Stripe payment for the card processing and CSV downloads for the payment.

If you think we’ve missed something, please let us know in the comments. And I truly hope this post will save hours of dull research to somebody.