The Web has a full ecosystem of payment processing services. We have detailed the use of two of the major players: Google Checkout and Amazon Flexible Payment Services. These two companies provide excellent solutions for payment processing. The primary benefit of building your application for these services is that they are extremely developer friendly. Libraries are available in many languages and their documentation is complete and well tested.
Most payment processors follow a similar design as the two we've discussed. One of the oldest services on the web, PayPal, offers a variety of payment services-everything from "Buy Now" style buttons to shopping cart integration.
We will not implement a PayPal payment processor here, but will discuss the general approach to building one. Unfortunately, the PayPal payment APIs are not particularly friendly for Python developers. They have not yet published official Python tools, though they do offer implementations for PHP, Java, Ruby, ASP, and ColdFusion. Some attempts to implement PayPal APIs as community Python projects do exist, but their success has been limited.
One of the difficulties with PayPal is that they offer so many different services and APIs that it's difficult to evaluate the right one for your e-commerce application. Further complicating matters, some of PayPal's more advanced tools require merchants to pay monthly service fees in addition to standard per transaction costs.
The PayPal service that is most similar to the payment processors we've built in this chapter is called Express Checkout. It works by the same pattern we've seen before: show the user their shopping cart with a checkout button, authorize payment at PayPal's site using a PayPal account, and return to our application for a confirmation page.
Instead of submitting a form directly to the payment processor, PayPal's Express Checkout service requires you to process a form in a back-end view. This view makes a call to PayPal's API and sends an HTTP Redirect to the customer's browser. The PayPal API call obtains a token, which you add to the redirection URL when you return the redirect response. This token is used to identify the order throughout the payment process, similar to Amazon's FPS, and it will be included when PayPal redirects to your site taking the user's payment.
When the customer returns to our application, we can make another call to the PayPal API with the returned token to obtain details about how the checkout went. We can then create or update our Order object or other Django models as needed.
Other PayPal services follow totally different patterns. PayPal offers advanced functionality, such as processing the entire payment through your web application. This method means the customer never leaves your site and makes you responsible for managing their data. Some organizations may prefer this approach, but it does present unique complications and potential for security disasters.
If we were to implement the entire payment processing directly on our site, we need to ensure that we handle all requests via HTTPS with an SSL certificate and that our web servers are tightly secured. An unsecure web server could open the potential for security risks because all of the processing is handled by our server. Even though we do not need to store credit card information or other payment details, there is always potential for our processing to be snooped or otherwise intercepted.
For small to medium sized organizations, the traditional objective is to look professional in the way they handle payments. Some may find that an offsite payment service such as Google Checkout, FPS, or PayPal Express Checkout appears amateurish. This is an unfortunate viewpoint, however, because using such services mitigates a substantial amount of risk from online payments. It also simplifies the design, development, and maintenance of payment solutions, which saves both time and money.