Handling multiple 3rd party e-commerce transactions

Question

I am currently planning to develop a web-app which will allow a 3rd party to list and sell their own products on it.

While I have experience with developing e-commerce solutions I personally do not want anything to do with the actual payment system myself (legally rather than technically) so that any transactions are between the buyer and the seller, with myself just as a 3rd party.

I am hesitant to use Paypal as I want to seem professional, plus I don't trust or like them. I also do not want to use any banking or merchant account as ideally I would need one for each customer (rather than having a centralized one) which would lead to excessive fees placed on the seller.

What is the best way of doing this? I possibly would be willing to accept some part in the transaction (preferrably low-risk) if absolutely necessary. I am looking to minimize fees and overhead as much as possible.

This will be a UK based site initially, but with potential worldwide access. It will also be developed in (probably) PHP but that should be tangential to the issue.

Thanks for any insight!

Answer 1

hi meep3d

http://www.wisegeek.com/what-are-the-different-methods-for-handling-ecommerce-transactions.htm

http://www.developer-resource.com/ecommerce-benefits.htm

view that both links.I think this will help you surely

Answer 2

Hi Meep3D,

we run www.hitmeister.de a large marketplace in Germany. What you are planning sounds like what we do, quite exactly...

On our system, the contract is between the buyer and the seller. All funds run through our accounts though, making us an intermediary in the transaction. The client can pay through direct debit, credit cards, paypal etc. The seller can only receive the money via bank transfer. We hold the money in escrow until the transaction is complete.

Getting this setup for Paypal and direct debit was not a big problem. Credit card operators generally do not like these arrangements, as you are turning into a (semi-)acquirer. They will do it though, if you talk to them.

Hope that helps

Answer 3

Is your business to get merchants paid by their customers (or help them get paid) or is it to attract customers to them and process and transfer related information? I agree the former is a big legal and CR mess. Who wants to handle calls or emails from random irate people about their purchases and payments? Better to be in the latter business of attracting customers and pushing information.

If it is just the latter, then ask each merchant for a URL template or checkout link on the form that they use to establish service. By URL template I mean a URL with variable components like the amount of the transaction, customer id, etc... Use this template to redirect the customer to the appropriate system when it is time for them to pay the merchant. This way the small merchants can use paypal but the bigger merchants with their own systems or, something other than paypal, can also be supported.

Bill each merchant for whatever it is you do for them.

If it can work this way business-wise then the main technical problems are analysing the major payment services input requirements (paypal, google payments, maybe a merchant cc system or two) to understand what your site needs to feed their site (this might be URL templating or it might be more) and creating related wizards for easy setup by the merchants. The advantage is that if you do this right you will also support most in house merchant systems because they will need to collect that same basic information.