Coder's Block and Braille on Drive-Up ATMs
Q. Why do they have Braille dots on drive-up ATM machines?
A. Since the Braille is required on the ones that are installed in walk-up locations, it is cheaper to only make one model.
At first the above question seems ridiculous, but once you get into "real world" economics, the true answer seems quite logical, doesn't it?
Did you ever get Coder's Block? It's like writer's block - you sit down knowing that you intend to work on something, and, well, for one reason or another, nothing happens. I generally don't ever get this at work -- the pressure of having to produce and being on the time-expense report means that although my performance might go up and down, at least I'm always producing.
However, I do get this when I am working on my own projects, and I've got a bit of it now. I'm working on a prototype "Link Purchase" system that includes an affiliate commission program, and I'm at the part where I need to integrate PayPal payments with IPN (Instant Payment Notification) that will be used to update a paid PayPal transaction into a database, and I'm like "going in circles". I'm trying to make it as generic as possible so all the values can be stored in a configuration file and thus it can be re-used for virtually any type of product or service sale via PayPal. I've got a sandbox account and credentials, and I am basically "ready to go", but...
I keep downloading sample PayPal ASP.NET code (much of which is in VB.NET -- which "could" be part of the problem!), playing with it, and then abandoning it and scouring the Web looking for more. I'm sure I'll break out of the Coder's Block rut, but I wonder what advice experts may have on this subject!
I'm a big fan of "Don't reinvent the wheel" and so far I've found some pretty good open-source implementations of Paypal with IPN notification, but for some reason, they don't seem to want to "fit" this situation. If you have used a particular implementation that you like, feel free to comment here and we'll feature it.
N.B. Rick's link in his comment got chopped by Blogger, so I'll reproduce it here. Definitely one of the better descriptions of how to handle IPN, too. His advice about not using Sandbox and just doing your testing with very small prices is right on the "money".
Pete,
ReplyDeleteMy company played around with IPNs a little while ago, and after about 3 months of trying to "get it right" just ended up scrapping the IPN section of the code. I'm not really sure how "generic" you'll be able to make your code, because there are a LOT of very specific things you need to do with it to make sure you're getting the right information, since there are so many things IPNs are used for - they're NOT just payment notifications, you get them for complaints, refunds, whenever your customer changes their underwear, etc.
Basically, we had a bunch of what we call "data tables" for all the various statuses, a "payment" table which was tied into our own e-commerce solution, and then a "notifications" table where we stored EVERY IPN we got. We used a sproc that found the most recent one for a given payment to figure out what status the payment was actually in.
Also, I read later that its actually best to use both IPNs and PDTs to ensure completely accurate information.
Its been a while since I worked on it, but if you like, you can email me at dan@dandoes.net and I might be able to give you a few ideas.
Also,
ReplyDeleteMost of the existing IPN-related code I found before I ended up writing my own sucked in one way or another. I spent a good day or so looking. I also subscribe to the "don't reinvent the wheel" mantra, but at the same time I generally have a problem with using other people's code because I can usually make something better myself. I know that maybe that sounds narcissistic, but thems the ugly truths!
I agree about having a problem using other people's code, but have also found that fixing it can be a good educational experience, since at least you've got some sort of codebase to "start with". Thanks for the useful comment.
ReplyDeletePeter,
ReplyDeleteYeah I know those doldrums. Usually it's not being blocked but being procrastinated though for me. There are several things that I should do for writing up things and I have all the material and I just can't get myself motivated to start... happens.
Re: PayPal: Have you looked at my article from a few years back:
http://www.west-wind.com/presentations/PayPalIntegration/PayPalIntegration.asp
Bottom has a bit on IPN.
I think the problem you might be seeing too is that the Sandbox is unreliable with IPN. If you're testing IPN try using a live account with penny purchases.
Rick, thanks for reminding me. I knew that I had seen your article about paypal and it was in my mind subliminally to go look for it.
ReplyDeleteHere's my advice for abstraction:
ReplyDeleteIdentify a common workflow for your different processes (sale, return, etc. - one workflow each). Code to the workflows using the provider model. Build each concrete implementation to that provider model. What I've ended up with in the past was a Transactions table with a relationship to the Orders table on OrderID.
Although, I would recommend PayPal Website Payments Pro. Cleaner than IPN, and the customer will finish the order at your site instead of PayPal.
Peter,
ReplyDeleteI've successfully used the coding of IPN and PDT from the commercestarterkit (www.commercestarterkit.org) and implemented it's functionality into a few sites that. I've also combined it with a remotepost class, which builds a html form and sends it off to paypal.
it all works very well together, and the IPNHandler and PDTHandler in the CSK are pretty generic. It also works really well with the sandbox (with the obvious IPN not working if using localhost/127.0.0.1)
colin