Comment by jacquesm | Hacker News Reader

Comment by jacquesm | Hacker News Reader

Parent Full thread

An IPSP is a third party payment processor. You are essentially suggesting that you wish to become one.

What you are about to do is to layer one IPSP on top of another so you control the stream of funds. Because you outsource the bulk of the problems to the IPSP below you you will have a relatively easy time of it.

If your merchants are going to use your platform (it is hard to say exactly what you will run in to without knowing a whole lot more about your project, but I understand you do not want to put all your cards on the table) then you will want to keep the balance you hold for them as low as possible to reduce the risk in case something goes wrong.

I'm actually working on a very long post (more like a small book) regarding the whole internet payment process, likely it will too much time for you to wait until it is done.

Ideally you would make a deal with an IPSP to see you as an affiliate, and get every merchant their own account with the IPSP. That way your exposure is limited and in case of conflict it will be between the merchants and the IPSP you pick.

Some, but not all IPSPs support this kind of functionality, the 'split' is usually either a fixed amount per transaction or a %age of the total sales volume.

You will have to figure in a two to six week 'holdback' period which is used to create a reserve in case of massive chargebacks due to fraud, it is also a major source of income for IPSPs and a major source of trouble in case one goes under.

How can I redesign my business model and at the same time not put myself in the higher risk category? These are the things I want to achieve:

1. I want to make sure the buyer is authentic and has the available funds

2. Once the merchant wins the auction, buyer cannot back out and the deposit authorized earlier goes to the merchant.

> I want to make sure the buyer is authentic and has the available funds

Now you are getting into 'escrow' territory, which is yet another level of difficulty.

> Once the merchant wins the auction, buyer cannot back out and the deposit authorized earlier goes to the merchant.

That sentence makes absolutely no sense!

I think you have 'merchant' and 'buyer' switched in the first part.

The normal way this is done is that the auction requires the buyers to put up a 'can execute' before the auction.

For online auctions this is rarely done, the more common method is that the #2 gets it if the #1 does not perform.

His/her bid then counts as retracted and they're banned from further bidding.

Its actually a different kind of auction where the buyers role and the sellers role are switched. Maybe I could explain the business model to you in detail over here: http://etherpad.com/FhFO67ihv2 ?

That comes up blank for me.

But I get what you're saying, you get buyers that want to buy stuff from merchants, they deposit some amount of money with you, then the merchants can go in to a 'reverse auction' (that's what this model is called), the winner is the one that puts in the lowest bid.

You really should make such stuff clear up front when you ask for advice.

This is yet another kettle of fish, with its own associated problems.

You really don't want to be in between here, after all the chances of rip-offs increase enormously, or you will have to go through a lengthy accreditation phase with each merchant where you verify that they can deliver the goods.

In a normal auction the bigger problem is the buyers not being able to pay up.

If there is a performance related issue (such as work for hire) then you have even more things to contend with, such as deadline management, fallbacks and so on.

Authorize.net has "Authorize only" transaction types, and you can "Capture" within 30 days. But how do I transfer this deposit to merchant without putting ourselves in the higher risk category?

Have a look if they are pre-auth or actual charges, that's a huge difference (both to you and the buyers).

For instance, if there are no 'takers' then you end up having to refund but the charges are gone.

A hard to catch fraud angle here is a person laundering money putting charges on cards for deposits, then having a 'white' merchant receive the deposits with ridiculously low bids.

You really don't want to be in between here, after all the chances of rip-offs increase enormously, or you will have to go through a lengthy accreditation phase with each merchant where you verify that they can deliver the goods.

We have sort of solved that issue. The only issue left to be solved is authorizing a deposit against the buyers account before the auction, and then transfering this amount to the merchant at the end of the auction. This deposit is not only going to be part of the price of the merchandise. Any idea on how this model could be improved?

You could use a 'pre-auth', but that only works for 3 to 5 business days, after that the pre-auth is revoked by the issuer.

Longer terms you will have to simply charge the account and then do a refund.

So this very much depends on the timing of your auctions.

Also, there cannot be a merchant account for all the merchants because initially I wont know who the winning merchant is going to be.

That does not make any sense at all... merchants don't win auctions, buyers do.

Reply on news.ycombinator.com