Testing the IPN verification is important. Keep in mind that IPN works by having PayPal call back your application at a specific URL. This means that if you're testing and you want to use the debugger locally, you have to work on a publicly accessible IP address that an external client (PayPal) can reach. If you sit behind a firewall, proxy, or even a DHCP connection, it's not going to work. To make things worse, I couldn't get IPN to work with the SandBox; it only worked for me on the live site. The SandBox account had no IPN configuration options, which means you have to run live transactions to test/debug IPN. Make sure you place SMALL orders and don't accidentally order your most expensive items. The PayPal commission might kill ya!
If you can't access a public IP to debug, you have to work the old fashioned way with messages dumped into Trace or Event logs or by sending yourself e-mail with status messages from within the IPN code. IPN is great, but plan on spending some time debugging this interface half blind if you don't have an open IP Address.
Testing PayPal transactions is an interesting proposition. PayPal wisely doesn't allow you to send money to yourself, so you will need more than a single bank account to test a PayPal operation.
To facilitate testing, PayPal provides the PayPal SandBox. The SandBox is a separate PayPal area that works just like PayPal, but deals with pretend money. Transactions made in the SandBox are not applied but the system behaves as if payments were processed. The SandBox also requires you to set up an account with bank information just like a full account, so the setup process is just as involved.
You can set up a SandBox account from the PayPal Developer Network through the Merchant Tools page on your account.
There are minor differences in the way the forms display in the SandBox and in an actual application, mainly due to differences in the way test accounts are set up.
Another testing option is to use two real accounts and use really small transactions. Because the behavior of the SandBox is slightly different from the real thing, it's a good idea to run a few real tests once you're getting close to release. I also couldn't get the IPN to work with the SandBox account, so to test the IPN, I had to use two real accounts.
Keep in mind that each transaction takes a commission and a transaction fee, so even a 25-cent transaction may end up costing 50 cents. That may be acceptable, but be aware of this before you go hog wild with test transactions on a live account.
Credit Card or PayPal
PayPal is like other credit card processors but with fewer pros and cons. Credit card processing tends to require considerably more paperwork to set up. You need a bank and a compatible merchant provider, who often impose strict rules on who gets accepted for card processing. The signup process can be extensive, with background checks, sending critical financial information and credit checks, and so on. In short, the credit card process requires some commitment of time and effort for you to submit this information. Many merchant and gateway providers also charge a setup fee to get started, sometimes hidden by making you pay this amount when the account is closed. PayPal, on the other hand. requires none of this; all you need is a verified bank account and you're off and running. Where merchant providers can often take many days or weeks to get set up, you can be up and running with PayPal in one day.
Most credit card processors work with a gateway provider like Authorize.NET, PayFlow, LinkPoint etc., to provide the actual Web interface. The advantage of these services is that they typically provide an API that allows you to process credit cards from within your application code. Essentially, you make requests against the server with the credit card information and the server responds with a confirmation or failure notice that contains all the relevant information. There's none of the back and forth and callback requirements that PayPal requires, which makes it much easier to integrate an API into a business object layer. These APIs also don't require a Web browser, so you can plug them into desktop applications as well as Web applications.
Credit card processors and PayPal both charge percentages plus transaction fees. If you have good credit, you can get better rates with a merchant provider, but PayPal's generic rate is an acceptable middle-of-the-road discount rate. PayPal's transaction fees are high for low dollar amount transactions, but it's not an issue for larger transactions. Merchant services charge monthly fees for use of the gateway and billing fee statements, etc., so be sure you compare your real monthly costs carefully if shopping by price.
PayPal and Consumers
PayPal is quite popular with consumers. If you cruise some discount stores online, you will invariably see a PayPal payment option. There are still a lot of people who don't trust the Internet enough to give out their credit card information, especially in consumer-related areas. PayPal offers a familiar and safe alternative because customers don't give the merchant their payment information.
On my site, I've been surprised how many people opt to use PayPal. Since adding PayPal, about 15-20% of my monthly sales volume comes from PayPal.
In this article, I've pulled together all the pieces you need to integrate PayPal into your own e-commerce front end seamlessly. The process is straightforward once you understand the interaction of the various pieces that PayPal provides and with the helper classes provided, integration into your own ASP.NET-based applications should be a snap.
You can find source code for this article here.