Integrating PayPal Payments into E-Commerce Applications with ASP.NET
E-Commerce applications require mechanisms for payment. Although more commonly than not e-Commerce sites will use full credit card processing gateways, giving PayPal as an additional option of payment provides additional payment options for your customers, especially those that don’t want to pay by credit card over the Internet. If you run a Web shop that uses direct credit card processing and want to integrate PayPal seamlessly, you’ll find that using PayPal as a processing service is not as straight forward as using a payment gateway. In this article I describe how you can minimize the external PayPal interaction and work the PayPal payment into the order processing workflow to provide a seamless interface using ASP.NET and C#. However, the principles used here should be applicable to any Web programming environment.
Payment processing on the Web is a big market and there a myriad of services and providers that allow you to process credit cards and bank cards over Internet connections. Most of these services are using credit card processing that automates the process of credit card validation. These providers usually provider either HTML or API based interfaces to process credit cards. HTML based interfaces provide you with a URL your application can redirect to on the provider’s site, which then handles the actual payment processing. API based interfaces allow your application talk directly to the provider’s services so that the payment processing can be integrated into your own application.
If you’re running your own E-Commerce applications you generally will want to use an API so the payment processing can be directly integrated into your own application. This makes sure the user of your app sees a consistent Web interface – as far as the user is concerned they are never leaving your site, but rather your Web backend is making the remote calls against the payment processing service and simply returning the success or failure of the request. HTML based payment interfaces generally look unprofessional as the user is whisked off to some other site for payment processing. Using external HTML processing often also requires you to handle inventory and order management through the payment provider which can be hassle especially if your e-commerce app already handles this. Still HTML based interface are popular because they can often be driven from non-data driven site and thus mitigate all the order management to the processing provider’s servers which can be beneficial for small sites.
Why PayPal?
On my own Web Site’s West Wind Web Store I use API based processing with Authorize.NET to perform most payment processing. This works great is fast and provides an integrated mechanism that provides seamless integration. We sell our software products online and from time to time there are those customers that are still squeamish about using their credit cards online – often customers from Europe – that would rather use an alternate payment mechanism. So a while back I looked at integrating PayPal into my store 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) are notoriously difficult in finding the ‘right’ payment mechanism and PayPal has been the answer for me in a number of cases, which is why I eventually sat down and integrated it into my Web Store application.
I've actually 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 more of a novelty and another bullet item for the store software, but there are quite a few people left in this world who don't trust the Internet (or the vendors for that matter) with their credit cards. PayPal is nice in that respect in that they provide the ability to keep the credit card from any vendor at all - now you just have to worry that PayPal stays safe and honest.
On the merchant front too I've found a lot of people actually using the 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 merchant services it seems. I can't blame them - most merchant providers or at least the 'resellers' are crooks trying to make a quick buck of 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 actually). Still, with PayPal you hit the ground running as soon as you have configured your account and provided a bank account.
On the downside, PayPal is a purely Web based interface. If you need to integrate payment processing into a non-Browser based application, PayPal is not an option since PayPal works exclusively through the Web browser interface. So if your business also takes phone orders and has an offline POS system, PayPal will be a hassle as you'd have to enter orders on the Web. PayPal also has rather high sales percentages that are generally much higher than merchant accounts (unless you are super high risk). Be sure you do the math. 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 acts as a middle man between the buyer and seller so that the seller never has to expose his payment information to the seller directly. Instead the buyer registers his credit card or bank account with PayPal and maps his account to an email address and then uses PayPal to make purchases. The advantage here is that the seller never gets the buyers 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 you use for buying things online, then you are already set up to also receive payments. All you need 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. Rather, like the HTML based services I mentioned earlier, the buyer has to go to the PayPal site, login and accept the payment request. However, this process can be automated to some extent by configuring PayPal to return to specific URLs in 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 QueryStrings passed to the PayPal pages.
In my Web Store I want PayPal to process only my final order amount. PayPal supports a number of order and inventory management features, but in an e-Commerce site scenario such as mine, all of this handled by my own Web application – all I want PayPal to do is process the final order amount.
Payment processing on the Web is a big market and there a myriad of services and providers that allow you to process credit cards and bank cards over Internet connections. Most of these services are using credit card processing that automates the process of credit card validation. These providers usually provider either HTML or API based interfaces to process credit cards. HTML based interfaces provide you with a URL your application can redirect to on the provider’s site, which then handles the actual payment processing. API based interfaces allow your application talk directly to the provider’s services so that the payment processing can be integrated into your own application.
If you’re running your own E-Commerce applications you generally will want to use an API so the payment processing can be directly integrated into your own application. This makes sure the user of your app sees a consistent Web interface – as far as the user is concerned they are never leaving your site, but rather your Web backend is making the remote calls against the payment processing service and simply returning the success or failure of the request. HTML based payment interfaces generally look unprofessional as the user is whisked off to some other site for payment processing. Using external HTML processing often also requires you to handle inventory and order management through the payment provider which can be hassle especially if your e-commerce app already handles this. Still HTML based interface are popular because they can often be driven from non-data driven site and thus mitigate all the order management to the processing provider’s servers which can be beneficial for small sites.
Why PayPal?
On my own Web Site’s West Wind Web Store I use API based processing with Authorize.NET to perform most payment processing. This works great is fast and provides an integrated mechanism that provides seamless integration. We sell our software products online and from time to time there are those customers that are still squeamish about using their credit cards online – often customers from Europe – that would rather use an alternate payment mechanism. So a while back I looked at integrating PayPal into my store 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) are notoriously difficult in finding the ‘right’ payment mechanism and PayPal has been the answer for me in a number of cases, which is why I eventually sat down and integrated it into my Web Store application.
I've actually 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 more of a novelty and another bullet item for the store software, but there are quite a few people left in this world who don't trust the Internet (or the vendors for that matter) with their credit cards. PayPal is nice in that respect in that they provide the ability to keep the credit card from any vendor at all - now you just have to worry that PayPal stays safe and honest.
On the merchant front too I've found a lot of people actually using the 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 merchant services it seems. I can't blame them - most merchant providers or at least the 'resellers' are crooks trying to make a quick buck of 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 actually). Still, with PayPal you hit the ground running as soon as you have configured your account and provided a bank account.
On the downside, PayPal is a purely Web based interface. If you need to integrate payment processing into a non-Browser based application, PayPal is not an option since PayPal works exclusively through the Web browser interface. So if your business also takes phone orders and has an offline POS system, PayPal will be a hassle as you'd have to enter orders on the Web. PayPal also has rather high sales percentages that are generally much higher than merchant accounts (unless you are super high risk). Be sure you do the math. 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 acts as a middle man between the buyer and seller so that the seller never has to expose his payment information to the seller directly. Instead the buyer registers his credit card or bank account with PayPal and maps his account to an email address and then uses PayPal to make purchases. The advantage here is that the seller never gets the buyers 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 you use for buying things online, then you are already set up to also receive payments. All you need 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. Rather, like the HTML based services I mentioned earlier, the buyer has to go to the PayPal site, login and accept the payment request. However, this process can be automated to some extent by configuring PayPal to return to specific URLs in 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 QueryStrings passed to the PayPal pages.
In my Web Store I want PayPal to process only my final order amount. PayPal supports a number of order and inventory management features, but in an e-Commerce site scenario such as mine, all of this handled by my own Web application – all I want PayPal to do 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 the application. The process goes like this:
- User picks items in our store Web site
- User fills out order info and goes to our store’s order page
- We provide the order total
- User accepts the order of multiple items and final amount
- User selects PayPal as payment
- User gets redirected to the PayPal site
- PayPal site takes user through the payment process
- On Success PayPal redirects back to our order confirmation page
- On Failure PayPal redirects back to our order form (redisplays order info)
- Finally we need to confirm to PayPal that we want to process this orderand PayPal confirms to us that the order went through.
See full detail: http://www.west-wind.com/presentations/PayPalIntegration/PayPalIntegration.asp
Comments