Forum Moderators: coopster
The problem... if there is one... is with my merchant. I collect all the customer data and then send it to the merchant for verification. If the card is accepted, the merchant "tells" me by forwarding to an acceptance page of my choosing and sending me some POST data. Then on that page I deduct the inventory and ship out the product. What occured to me, is what if someone simply sends bogus POST data to that acceptance page? It seems like an obvious problem. Any help would be appreciated.
Sam
If you are manually verifying payments through the merchant interface, it won't be an issue anyway.
Do customers actually visit this page themselves? If not, it shouldn't be something to worry about.
We're not running the cards manually. The site sends a bunch of hidden form fields to the merchant (all on a SSL page), and the merchant either forwards the user to MY accept or deny page based on whether the card went through. Seems to me, that any slimeball could:
1) Go to an e-commerce site
2) Pick out something really cheap
3) Read the source of the page before it authorizes and see all the hidden form fields going to the merchant.
4) Click authorize.
5) Note the page that is returned on acceptance.
Then the next time:
1) Send the appropriate POST data directly to the acceptance page as noted in #5 above with whatever it was they wanted to get for free.
Am I missing something?
My own merchant allows me to encrypt the information that is sent to them for authorisation, so it is more difficult (impossible?) for the client to send false data to my merchant Once a transaction is authorised they return my client to an order verification page on my site with an encrypted token in the URL, so again it is more difficult (impossible?) for the client to fake that a payment has been successful.
I put "impossible" in brackets with a question mark because it's not possible as far as I know to trick the system but someone would undoubtedly say that I was being naive if I said that it was completely impossible! ;)
1) Send the appropriate POST data directly to the acceptance page as noted in #5 above with whatever it was they wanted to get for free.
I'm still not seeing why this would be a problem. OK, so the transaction would "appear" to have been authorized, but an _actual_ authorization would not have been performed through the gateway.
This is something you'd easily spot, surely?
If you ship goods relying solely on your own authorization notification, without checking the gateway authorization records then yes, you are open to fraud, but doing so is a bit silly.
[edited by: FalseDawn at 7:39 pm (utc) on Aug. 25, 2006]
I have another merchant account with another site that uses Authorize.net, and like the previous reply said, they DO encrypt their data in both directions, so there is no chance of receiving a "phony success". I kind of wished I had gone with them instead of YourPay. This system just seems too wide open to me and I'll leave it at that.
Sam
