Recieving and making online payments

[rmbarnes82]

Hi,

This isn't exactly a PHP specific post, but does relate to web development so I posted it here because I didn't know where else to post it.

I am looking to develop a site which will have two types of customer: one selling goods (seller) and one buing goods (buyer). Both buyers and sellers would have virtual 'account' containg 'credits' for use on the site.

The buyer would use some kind of online payment provider (e.g. worldpay) to buy credits for use on the site. When the buyer purchases something on the site the cost of the item (in credits) would be transferred from the buyers virtual account to the sellers.

The seller would then have the abillity to 'cash out' credits from thier virtual account, transferring them to real money in thier bank account. This is where the problem lies - how do I make a payment to the sellers bank account?

Thanks alot.

Robin

[bpat1434]

What you're talking about sounds a lot like an escrow service. Basically, what I'd do is set up a time-frame for me to be able to pay them back. Give them 24 hours, or something. Then when credits from a buyer are transfered to the seller, shoot an email to yourself (or update a database listing) telling you that you have to send $XX to the seller.

You specifically can't make a payment to their account, but you can send money. Paypal, as far as I know, does not allow scripts to send money. If they did, it'd be a huge security issue. So you'll have to send the money by hand.

By the way, moving to Echo Lounge...

[rmbarnes82]

Thanks for the reply, was hoping to make this automated, but looks like it may not be possible.

I think there are also security implications to a PHP script automatically shipping money from my bank account to another person's bank accout....

I will just as you say have a cash out request db (money wont be sent to seller for every purchase, only when they cashout), then send money via bank transfer manually.

[etully]

Paypal, as far as I know, does not allow scripts to send money. If they did, it'd be a huge security issue.

Why would that be any more of a security issue than doing it manually in a web browser? And how would Pay Pal know it's a script rather than a human being?

Of course, if you use Pay Pal, then you'll have to pay their fees which can be significant.

[bpat1434]

Umm... how is it secure? Paypal won't know if it's a script, this is true.

Let's look at their situation:
1.) PersonA goes to site and purchases from PersonB
2.) PersonA sends $$$ to ThirdParty via PayPal
3.) ThirdParty recognizes (via PayPal's IPN) payment, dispatches email to PersonB
4.) PersonB sends purchased item
5.) PersonA notifies ThirdParty item is received and correct (condition and everything)

At this point here we have the two different routes to take: Automated vs. Manually.

Automated
Script sends out money from ThirdParty account to account of PersonB. PersonB is emailed status of the transaction.

Manually
ThirdParty receives email, manually logs in to PayPal, verifies they have the funds, manually inputs destination address, verifies amount, sends money. Notifies PersonB of transaction.

So, the big issue is verification. Let's say that PersonB knows that your script is waiting for an email with specific keywords. PersonB imitates PersonA (because they'll know eachothers email for obvious reasons) and sends an email saying that the item has been received. The script transfers the funds to account in name of PersonB. PersonB immediately removes funds to bank account, closes PayPal account, disappears with $$$.

I'm sure it's possible to secure it, but is it worth securing it that much to not do it manually? At least that way you can be sure you are in control the entire time. The third party is actually involved, rather than just a body to watch money come in and out. It also makes the third party accountable. It's all about covering your butt and making sure there's accountability in the system. If any part of your system is automated, there's no accountability. You are responsible for what happens, but if you write your license right, you can't be held liable. So it just makes sens to go ahead and make it manual requiring confirmation. It may take an extra 20 minutes per day, but hey, it's worth it in the long haul.

[etully]

For the warm fuzzies, you're right. manual is better - but as far as actual security is concerned, manual is exactly as secure as automatic.

Your example is different than what the OP described but that doesn't change anything. Let's use your example for a minute.

In your example, PersonA sends an email to third party saying they received the goods (condition and everything) and then, based on that email, either (A) the script tells Pay Pal to deliver the money or (B) the third party goes to Pay Pal to manually deliver the money.

You presented a threat model that, in your example, PersonB could spoof an email. But couldn't PersonB accomplish that same fraud if the funds transfer was handled manually? That is: PersonA buys from PersonB, PersonB sends a spoof email to 3rd party saying everything was delivered perfectly, 3rd party goes to Pay Pal and manually delivers the money. B closes the Pay Pal acct and disappears with the $$$. In other words, in your example, handling the transfer manually doesn't add any additional security.

The only reason that fraud is possible in your example is that payment hinges on a mere email from A saying that the product was delivered successfully. And email is horribly insecure as you easily pointed out. So in a real world product, you would never transfer funds (manually or automatically) based on words in an email. Of course, the OP wasn't suggesting that they were going to do that.

In a real world product, the 3rd party has a login screen for both buyers and sellers. The only person who can state that the product was delivered successfully is PersonA. And if the 3rd party has a login screen with a username and password, then PersonB cannot pose as PersonA to flag the transaction as complete.

So as you said, the entire process relies on verification of PersonA stating that they received the goods. But how you verify PersonA has nothing whatsoever to do with how you are going to transfer the funds later.

Transferring the funds manually adds the illusion of extra security. It's a nice warm fuzzy but it's not really even a little bit more secure. You talked about covering your butt. If fraud does get committed, what defense is the 3rd party going to use? "No no, it's not my fault. I'm not liable because I transferred the funds manually at Pay Pal." The fact that 3rd Party transferred the funds manually doesn't help cover their butt one iota. If they got tricked because they didn't do a good job of verifying (authenticating) PersonA, it's not going to matter that they transferred the funds manually - that doesn't cover their butts.

The illusion is created partially because doing it manually takes more effort - it seems to make sense: if it takes more effort, then it must be more secure, right? The truth is that the security of the entire system lies in how strong you make your web site (that is authenticate PersonA), not whether the owner of the 3rd party web site has to take an extra 20 minutes a day to process the funds transfer manually.

Transferring the funds manually or automatically are exactly equal from a security perspective.

[bpat1434]

I hear your points, and agree but also disagree. Think about it. If you have a script that does the automatic transferring of money, there's more than 1 way to work around it. They could go in and take ALL of the money from your paypal account. It's not the security of the email. That was an example, and a good example of insecurity. But if you have to manually go in and transfer funds, your credentials aren't stored anywhere online. Your information is secure in your head / papers (or where ever you keep them). So no one person can go in and hack your script and get into your paypal account unauthorized.

But that doesn't alleviate the issue of paypal being hacked and you getting phishing emails and all that. Now, it's not the security of your site (although technically anything dealing with money should be behind SSL) but the security of the script. If PayPal allowed you to send money via a PHP/Perl script, there'd be an API for it. There's a reason they don't. They'd be exposing not only their servers to frequent attacks, but your scripts to attacks. That's a whole lot. And if just one person was able to reverse engineer your code to work so that your funds get directed to their account, it's a long process to get that money back. And if you say "Oh, well I had a script up that transferred money automatically" Paypal will say tough nuggies, you didn't secure your script behind SSL, using the proper filtering techniques, etc. etc. Paypal can't be held liable for someone stealing from your script. So it'd be tough to get that money back. Now, if you do it manually, you can appeal and say you were duped and would request that the funds be reverted. Plus, if you're smart enough to set this up, but stupid enough to not look hard at the emails, then maybe you shouldn't set this up ;) (not you personally, just a general anyone statement.)

Anyway, I say it's insecure to let a script transfer your funds from your account to someone else via PayPal without your intervention. That's my opinion. Take it as you wish. But think long and hard about your security situation. Are you on a shared server? Do you have a dedicated IP to use? Do you have SSL? Are you willing to put your own information on the line just to make your life that much easier? Me personally, no. But that's an individual decision.

Like I said, I heard your points, and they're valid. But I still contest that it's insecure and not a great idea to allow your script to accept AND transfer funds. Kinda that whole division of powers thing (think Executive & Legislative branches of US government (Checks & Balances)). Just an opinion.

[Weedpacket]

let a script transfer your funds from your account to someone else via PayPal without your intervention.

Not via PayPal, but I do have scripts that transfer funds from my account to others'. They're sitting on my bank's servers. :) I mention this because the bank is responsible for securing them and their operation - and it's the entity that will have to pay out if they fail. They have the responsibility, they have the liability.

Now, if you had a hand-tooled script that interfaced with some sort of API exposed by PayPal, and it was broken, who would be liable for the damage? Hint: unless someone had got behind the API and perverted PayPal's systems, it won't be them.

[bpat1434]

Yes, but usually don't you have to log in to your account to do this? That is unless you set up automatic payments? Even then you know how much is going out when and to whom. So the risk is smaller there.

Now, if you had a hand-tooled script that interfaced with some sort of API exposed by PayPal, and it was broken, who would be liable for the damage? Hint: unless someone had got behind the API and perverted PayPal's systems, it won't be them.
Thank you for further supporting my point.

[etully]

bpat1434: I also hear your points clearly. I would agree that automation done badly is insecure. I was just trying to make the point that it's the "done-badly" that's the problem, not the automation itself. I would also agree with you that it's unwise for an average programmer to write their own automated payment scripts - but when done correctly, automation itself does not introduce any security holes.

[Roger Ramjet]

Way back in the day we used to have to use PGP to manage domain registrations with Nominet for things like changing glue record dns. Now PGP seems to have dropped below the horizon, but I think it would work here.

Users have to register, so when they do they register a PGP key with you. Then when they send the confirmation email it is encrypted via PGP and you can verify it is from them and process it automatically.

The other way is for them to log in to your site and do the confirmation a la Ebay where you have to login and tell ebay that you have despatched the goods etc.

[dougal85]

You can set it up so you are forwarded to pay pal and then you just enter your password and confirm it.

That's the best I've seen with pay pal. I'm not familiar with others.