Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Integrating PayPal into E-Commerce Applications with ASP.NET

E-commerce applications require user-friendly mechanisms for payment. Although e-commerce sites usually use full credit card processing gateways, offering PayPal for payment provides an option for those who don't want to send credit card information across the Internet.


advertisement
f you run a Web shop that uses direct credit card processing and you want to integrate PayPal, you'll find that using PayPal as a processing service is not as straightforward as using a payment gateway. In this article, I'll describe how you can minimize the external PayPal interaction and work the PayPal payment into your order processing workflow to provide a seamless interface using ASP.NET and C#. Payment processing on the Web is a big industry and there are myriad services and providers allowing you to process credit cards and bank cards over Internet connections. If you're running your own e-commerce applications, you generally want to use an API so the payment processing can be directly integrated into your own application. This makes sure that the user of your application sees a consistent Web interface. As far as the user is concerned, they never leave your site; your Web back end makes the remote calls against the payment processing service and returns the success or failure of the request.

Payment processing for credit card providers provides two types of interfaces: an API- or HTML-based payment interface. The API allows direct calls from within another application and HTML-based access whisks users off to the provider's site, which handles the payment detail entry and processing and returns users back to your site. For a professional-looking site, API-based interfaces are a better choice. But HTML-based interfaces are often cheaper and in some cases—like PayPal—are unavoidable, as it is the only interface offered. Why PayPal?
On my own Web site's West Wind Web Store, I use API-based processing with Authorize.NET to perform payment processing. This works great: it's fast and provides an integrated mechanism with seamless integration. I sell software products online and from time to time, there are customers who are still squeamish about using their credit cards online—often customers from Europe—who would rather use an alternate payment mechanism. So a while back, I looked at integrating PayPal into my store's software.

PayPal may not be the first choice for order processing in a custom e-commerce application, but it does provide another payment option for your customers. Some customers (at least in my business) have a hard time finding the right payment mechanism and PayPal has been the answer in a number of cases.

PayPal is quick to set up, doesn't have any startup costs, and doesn't require reams of paperwork, like other merchant services.
I've been surprised how many orders I get in my store through PayPal. When I originally hooked this up a few months back, I thought of it as a novelty and another bullet item for the store's software, but there are quite a few people left in this world who don't trust the Internet (or Internet vendors, for that matter) with their credit cards. PayPal is nice in that they provide the ability to keep the credit card from any vendor at all—you only have to worry that PayPal itself stays safe and honest.


On the merchant front, I've found a lot of people using PayPal functionality as their main payment mechanism instead of merchant services. A lot of small operations or personal sites don't want to deal with the hassles of setting up merchant services. I can't blame them—most merchant providers, or at least the resellers, are crooks trying to make a quick buck off the unsuspecting vendor. Getting set up also takes some amount of paperwork and often can take weeks. Luckily, that seems to be changing somewhat with better and more consistent gateway services appearing with reasonable prices (my experience with MerchantPlus and Authorize.Net has been a real joy). Still, with PayPal, you hit the ground running as soon as you have configured your account and provided a bank account. You can be up and running on the same day. On the down side, PayPal is a purely HTML-based Web interface. If you need to integrate payment processing into a non-browser-based application, PayPal is not an option because PayPal works exclusively through the Web browser interface. So if your business also takes phone orders and has an offline POS system, PayPal is a hassle because you'd still have to enter orders on the Web. PayPal also has rather high sales percentages that are much higher than merchant accounts (unless you are super high-risk). Always be sure to do the math when comparing merchant providers. A little time up front may save you a lot of money in the long run—percentages are what often make or break your sales margins.

PayPal as the Middle Man
PayPal acts as a middle man between the buyer and seller so that the buyer never has to expose payment information to the seller directly. Instead, the buyer registers a credit card or bank account with PayPal, maps the account to an e-mail address, and then uses PayPal to make purchases. The advantage here is that the seller never gets the buyer's payment information and therefore can't abuse it (accidentally or otherwise) in any way. So what do you need to accept payments? The nice thing about PayPal is that it's easy to sign up to accept payments. If you already have a PayPal account for buying things online, you are already set up to receive payments. All you need is to have a bank account so payments can be deposited into it. That's it!

How PayPal Works
PayPal is not a payment gateway and they don't provide a direct API interface to their service, except for very large/high volume customers. Instead, like the HTML-based services mentioned earlier, the buyer has to go to the PayPal site, log in, and accept the payment request. This process can be automated by configuring PayPal to return to specific URLs in the case of success or failure and providing a callback confirmation URL that allows you to verify that PayPal processed a payment on your behalf. This configuration is done via POST data or query strings passed to the PayPal pages.

The PayPal process requires a browser-based Web interface and you must redirect from your site to PayPal to process payments.
PayPal supports a variety of order and inventory management features, but in an e-commerce site scenario such as mine, all of this is handled by my own Web application—all I want PayPal to do in my Web store is process the final order amount.

As you might expect from this description, this process is fairly involved if you want to completely integrate the payment into your application. The process goes like this:

  1. The user picks items in the store's Web site.
  2. The user fills out order information and goes to the store's order page.
  3. The store provides the order total.
  4. The user accepts the order of multiple items and the final amount.
  5. The user selects PayPal as the payment type.
  6. The user gets redirected to the PayPal site.
  7. The PayPal site takes the user through the payment process.
  8. On success, PayPal redirects the user's browser back to the store's order confirmation page.
  9. On failure, PayPal redirects the user's browser back to the store's order form (and redisplays order information).
  10. The store confirms with PayPal to process the order and PayPal confirms that the order went through.
 
Figure 1. Integrating PayPal: The process of integrating a PayPal payment involves several pages and HTTP POST-backs.
Figure 1 shows the general flow of the process.

This process looks pretty complicated and although there is quite a bit of back and forth, it's pretty straightforward once you understand the flow. You need two pages on your site to make this work: the Order page and the Instant Payment Notification Callback page. Order Page
The order page form is the jump off and return point. In my example, it's called OrderForm.aspx. This page needs some internal logic to redirect to PayPal if PayPal is selected as the payment type. I'll provide you with a helper class that makes this a snap by simply setting a few properties.

The same OrderForm.aspx also serves as the return page from PayPal on completion. When you redirect to PayPal, you provide URLs for successful and cancelled operations, and these URLs point back to this page with special query string parameters (such as: OrderForm.aspx?PayPal=Success). I like to use a single page here to keep the PayPal-specific logic in one place, but you can also use separate pages. Unlike credit card processing, it's somewhat difficult to keep PayPal logic inside of business objects because this interaction relies on the HTTP mechanisms and page callback, so some of the routing logic ends up embedded as part of your Web UI layer (ASPX code-behind). The helper class abstracts most of the internal knowledge but some operational code still squeaks into the ASP.NET page.

For my Web store application, it also makes sense to return to this page in order to complete the order process. The order form can simply pick up right where it left off before redirecting to PayPal. In short, returning makes PayPal integration easy with minimal changes to the existing processing. It's important to understand that a return from PayPal does not guarantee that the order went through. It's easy to spoof the return URL you sent to PayPal because it's visible on the query string (or if you POST in the POST buffer). Therefore, a user could simply type in the confirmation URL directly and you should not yet confirm the order. You can manually check for orders on the PayPal site or wait for PayPal's confirmation e-mails, which let you know for sure that the order was processed in a manual way.

Instant Payment Notification Callback Page
To automate the confirmation process, PayPal can optionally ping you at another URL with order completion information. This is where the second Instant Payment Notification (IPN) confirmation page shown in Figure 1 comes in. IPN uses a Web-based callback mechanism that calls a pre-configured URL on your site. The IPN must be enabled on the PayPal site and when enabled, the IPN sends a confirmation to you at this URL after the order is processed. PayPal expects a return from you within a certain timeframe (a few minutes) and returns a response to confirm that the customer has paid. To do this technique, you have to POST the data back to PayPal by echoing back all the form data that PayPal sends to you. The IPN is optional, but it's a requirement if you need to confirm your orders immediately with your customers. For example, on the West Wind site, new software purchases are confirmed by sending an e-mail with download URLs to obtain the software almost immediately. For credit card transactions, the e-mail is sent immediately as part of the Confirmation.aspx page. When the order is verified and complete, e-mail confirmations are sent. For PayPal orders, this cannot be done through the confirmation page, so the confirmation page just displays the completion notice. The IPN return page is then used to send the final e-mail confirmations for the download links.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap