Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

December 27 2013


E-commerce Freebie on Noupe: 50+ Credit Card Flat Icons by Freepik


The year 2013 comes to its end. Christmas has already been and gone. Maybe you’ve spared yourself a few days to recover, but soon enough you’ll be thinking towards 2014 again. We have quite a few maintainers of online shops in our readership, who might right now be polishing their sites to deal with next year’s customers. It was with you in mind, that we sat down with our friends from Freepik to put together a set of flat icons with a focus on international payment systems. The 50+ icons we serve you today can be used freely for private and commercial purposes alike. The only twist is, that you can only grab them from here…

March 16 2012


The Evolution Of Online Shopping – 60′s to the 90′s

The wonderland called eCommerce. Today, some countries are busy doing most of their shopping online while others are starting to experiment with their online market. In either case eCommerce is here to stay. This article won’t shed any light on the future of eCommerce. No! Rather, I will be trying my best to collect in-depth data in order to help you understand how eCommerce has evolved. The journey has been more than just majestic.


EDI (Electronic Data Interchange) permits companies to carry out electronic transactions. Although the concept of eCommerce did not touch the daily Internet user till the era of 1990s yet some big players had started to use EDI as early as 1960. The railroad industry was among the first to understand the importance of EDI and start using the same. Other players in the transportation industry followed.


There is always a hero. Someone who comes out of nowhere and does something unusual. eCommerce has its own hero. Michael Aldrich is the man. It was the year 1979 when Aldrich was on a stroll in a supermarket with his wife. Suddenly, he was hit by an idea which changed it all for eCommerce. Aldrich connected a domestic TV and a computer with telephone lines so as to start selling groceries online via this model. How they were able to tackle various situations is a different story altogether, but at the end of the day they did come up with a model that helped them launch the business of online shopping.


Have a look at this rare PDF and then read along. It was the year 1981 when Thomson Holidays picked up 66 travel agents from around England and connected them in order to come up with what has been tagged as first B2B (Business to Business) online shopping. These agents were able to extract data online and understand what was available from the Thomson Brochure so as to serve customers instantly.


This was the year for France to jot down her name in the history books. France based telecom company invented Minitel which has been considered as the most happening pre-WWW online service. Even during its infant years users had the privilege to make online purchases, check phone directories, chat with each other and various other basic searches just like it happens in today’s Internet.

[via Wikipedia]


How would it sound if someone tagged you as the first ever home shopper on this planet. Well, Jane Snowball was tagged as the first ever home shopper when at the age of 72 she became Tesco’s customer. It was the year 1984 itself when the world’s first B2C (Business-to-Consumer) online shopping system was launched by Tesco. The online shopping system started the concept of Online Shopping Basket which was later renamed Online Shopping Trolley.

Also, it was April 1984 when CompuServe announced Electronic Mall which was almost like the eCommerce of today.


Next up was a Merchant Account launched in the year 1987 that helped software developers sell their software products online. SWREG was the name and it happens to be one of the oldest pieces of software that is still available.


Here we go. The year which marked the launch of the first web browser. The name of the browser was WorldWideWeb which was later renamed to Nexus so as to avoid the obvious confusion. Nexus was also the editor for programmers who coded websites. During those days Nexus was supposed to be the only medium to access the Internet in graphical format. The amusing part is that the browser was launched for the public by using Internet newsgroups as the medium of communication. This will help you understand that the communication system (on the Internet) of those days wasn’t as big as it is nowadays.


Back then NSFNET was the backbone of the Internet, but it wasn’t available for commercial use. It was the year 1991 when the NSF (National Science Foundation) cleared the way for the commercial use of NET. This was considered to be a major boost for the eCommerce industry and its future growth. Statistics state that the traffic on the backbone network of NSF jumped to over 1 trillion bytes per month in the year 1991 itself after it was opened for commercial use. By 1996 there were over 10 million hosts online and the Internet was now a global phenomenon.

It was the year 1991 itself when University of Minnesota launched “gopher”, the first point-and-click based browser that could be used to navigate files on the Internet. At times this has been tagged as the birth of Internet.  Gopher was originally designed to ease campus communication.

“The first Internet application my mom can use.” ~ Mark MaCahil, Team Lead of the computer programming team which launched Gopher.


A book called “Future Shop: How new technologies will change the way we shop and what we buy” was published in the year 1992. The book was considered revolutionary considering the fact that it talked about what will happen in the future of eCommerce and how the Internet will take shape.

“Snider and Ziporyn (the authors of the book) powerfully describe the glass highways of the future, which will not only benefit consumers but will also provide fantastic opportunities for schools, hospitals, businesses, and the average American as we enter the Information Age of the 21st century.” – Conrad Burns, Chair of U.S. Senate Communications Subcommittee


This could be tagged as the “Mother of all Years” for eCommerce as Netscape launched encryption certificate which became the trustworthy means of transmitting data over the Internet. Certificates gave the browsers a chance to trust a source before displaying its data and sharing personal information. Something that helped the end consumer shower more interest on the Internet and indirectly on eCommerce transactions.

This wasn’t all. The year 1994 also marked the launch of Yahoo! though the domain was registered later in the year 1995. This truly gave the Internet and eCommerce a completely new direction.


It was the year 1995 when NSF started charging a fee for registering domain names. I wish I was born before so that I could have registered some of the premium single word dot com domains in 1995! At that time the Internet had 12,000 domain names registered and the number jumped to over 2 Million in the next 3 years.

January 18, 1995 was the day when the domain was registered. The word Yahoo is an acronym for “Yet Another Hierarchical Officious Oracle.”

One must understand that by now a lot of other services that would later rule the web had started to appear. Some of these were Amazon, AuctionWeb (which later became eBay) and Verisign etc.


PayPal came into existence in the year 1998. The current PayPal system that we see is actually the merger of X.COM, a financial service company of the late 2000s, and Cofinity which happened to be a payment and cartographic company. It was the year 1998 only when Google entered the world of eCommerce and Yahoo! launched Yahoo! Stores online.

2000 and Onwards

As they say, what followed after Google is history. Be it the dot com bubble or the Web 2.0, the Internet has experienced exponential growth (with its own pitfalls) that has shaped the lives of many. As we know it, the Internet continues to grow with major and minor eCommerce companies launching their own set of stores. Today, we can literally buy anything via the Internet. That is the wonderland of eCommerce.

February 28 2012


Is Paypal Good for Your Online Business?

PayPal is definitely the most well-known online user payment service in the world. With its start somewhere in 2000 thanks to and Confinity merging, PayPal quickly became a leader of the market and expanded very fast among eBay users. That is probably why PayPal was bought by eBay in 2002 for just under $1.5 billion.

But PayPal means much more than that today. Tens of millions of users tend to pay with PayPal faster than with their credit card. The company functions as an acquirer and processes payments for online vendors, auction sites and many commercial users – all these for a small usage fee. With such a reputation to handle, we might surely ask ourselves how likely it is for PayPal to be the best payment processor for our online services. If you own a design agency, I am sure you have thought of this at least once.

Today we will put in balance the negative and positive sides of using PayPal for a business and we will try to come to a conclusion by the end. I look also forward to hearing your opinions about the great service PayPal is, but let’s wait for that until the end.

What is PayPal NOT?

Well, although it seems like one, PayPal is definitely not a bank. It offers the basic services of a bank, but is has not been classified as one, although it is under rules and regulations which govern a financial institution in the USA. A bank usually uses people’s deposits for its own purposes, while PayPal does not. They only store the deposits in their accounts and do not redistribute any of it. Although PayPal is not considered a bank in the US, it has been regulated just like one by the CSSF in Europe.

In order to be able to talk about the advantages and disadvantages of PayPal, it would be a good idea for me to tell you some quick facts about it:

  • PayPal has more than 230 million accounts registered and allows customers to send, hold and receive money in 190 countries in the world. PayPal features support for 24 different currencies.
  • PayPal allows people to start their own businesses and work as a third-party service in the transactions they make.
  • There is a specific limit of money a user can receive per year. If you want to have an unlimited account, you will need to provide personal information and verify the account.
  • PayPal has a service called Students’ Account, which permitted parents to give students money on a debit card.

The good

PayPal has some clear advantages over any competitor on the market. First, it is very easy to set up and is very elegant. It doesn’t take more than few minutes to set up an online shop with support for PayPal. The “add to cart” and “view cart” buttons can even be customized by the designers themselves. The service is also very easy to use and the payments very easy to execute. There is no doubt about the fact that paying with PayPal could not be easier. Moreover, there is no setup or monthly fee.

Let’s face it, one of the most important assets of PayPal is its brand and name recognition. Being a company with excess of $2.2 billion in annual sales revenues, PayPal is no doubt the star player of the market. Although people are still reluctant to pay on the internet, they definitely trust PayPal the most if needed to process money online. Moreover, because it functions as a third-party service, PayPal makes sure the customer’s credit card and bank account number do not get in the stores’ databases. Security is extremely important and PayPal seems to take care of it as well as possible.

While many other services sustain themselves by asking for monthly or yearly payments, PayPal asks for money only from the users who sell. This makes PayPal feel like your friend because when you don’t sell anything, you don’t pay anything. Can it be more convenient?

Image by 401K.

With so many users having a PayPal account, there is a huge potential customer base for everyone who uses PayPal for online selling. A good example is eBay. The majority of the sellers do not offer support for MasterCard or VISA, therefore buyers need to have a PayPal account in order to buy something – and this doesn’t affect eBay at all, because as said before, PayPal has a huge customer base.

While businesses use PayPal for commercial purposes, individuals can also use it for personal purposes. PayPal offers multiple account options and a single person can opt for one of them. Each account option offers different privileges and have different rules. There is no fee for transactions between two PayPal users with a personal account for example.

The fact that PayPal offers support in so many countries is another strong asset. Giving the option to use 24 currencies and handle international payments is something not many other services can do. Another impressive feature is the option to pay through credit and debit cards directly, which means the transaction fee is also minimal, set at 3.9 percent for any amount up to $100,000.

If you thought this is all, you are in for another surprise. Although it is not a bank, PayPal works as a great accountant. You can see every payment, withdrawal, every inbound transaction – all these with a single click. It is very easy to find every transactions in the history panel and you can even download a spreadsheet file with details for a period longer than one year. Printing is not a problem for PayPal either.

As mentioned before, PayPal is an eBay service, therefore buying from the American online store has never been easier.

The bad

As any other service, PayPal has its own disadvantages too. One of them might be the fees charged for non-PayPal payments. Although PayPal claims they help small sellers, the hidden fees show no signs of it. The fees might be from 1.9 to 2.9 percent plus $0.30 per transaction – this can get very costly. Some of PayPal’s rules are also very strict due to different regulations. The slightest suspicion about your account might get it suspended and it takes a long time for PayPal to investigate and reopen your account. You might find yourself with your money locked for longer periods than expected.

Talking about customer service, maybe the worst thing about PayPal is the difficulty to solve issues and investigate cases. There have been many issues over time with trying to contact customer service. Even when you manage to get a hold of them, sometimes it just seems there is no one at the end of the line and some emails only get automated responses. There have also been reports of accounts being automatically charged without the knowledge of the user.

Although a quite secure service, PayPal seems to lack high-quality customer support.

Image by protohiro.

There is not even the chance of a third-party jury. When being investigated by PayPal, your account and funds get frozen and the only thing you can do is wait. There is no documentation provided to the user and it doesn’t seem like PayPal puts much consideration into resolving peoples issues.

The verification process is also a hassle. Users have to provide several important pieces of private information such as bills, bank account numbers, social security numbers, address proof and so on. Some users might not even be comfortable with offering such information, but they have to in order for PayPal to lift the funds receiving limit.

Although most eBay sellers have to use PayPal, it seems the protection for them is not excellent. There have been reports of funds refunded to the customer even after the seller has shipped the item! This can become a deal breaker especially when the customer service is not as good as it should be.

Who else?

If for some reason you just don’t want to go with PayPal, then there are some other alternatives out there, although none of them is really that impressive. Google Checkout is an alternative, although it is still an inferior product. The main difference is that Google’s service charges fees depending on the sales volume, while PayPal does not. Checkout also offers fewer features than eBay’s service.

A second one could be MoneyBookers, a very well-known British-based service. They have a customer base of around 10 million accounts, although we do not know yet how many of them are active. They offer services to everybody with an email address and they have a flat fee per transaction.

Besides Google Checkout and MoneyBookers, there is not much else worth mentioning. The other few alternatives, Amazon Payments, OboPay and Paymate are really small and, when people deal with their money, they are not willing to work with companies without a powerful brand.

Bottom line

PayPal is obviously not the perfect solution for buyers and sellers, however it is definitely the best one available right now. They lack support, true, but it’s the most secure online payment service and the one offering the most features. Although PayPal seems best suited for medium-sized businesses, there are not many alternatives out there.

If we look at it from the buyers’ perspective, then there is definitely no better alternative out there. Let’s face it, every service has its own problems; it is just a matter of finding the one with the least of them.

Until next time… what do you think about PayPal? Did you ever have problems with it as a seller/buyer? What is your experience with their customer support and how long did it take for your case to be investigated?

September 05 2011


Getting Started With The PayPal API

Advertisement in Getting Started With The PayPal API
 in Getting Started With The PayPal API  in Getting Started With The PayPal API  in Getting Started With The PayPal API

PayPal is the most popular platform for receiving online payments today. The ease of opening a PayPal account and receiving payments compared to opening a merchant account with a traditional payment gateway is probably the number one reason for its popularity, with a close second being the comprehensive API that PayPal provides for its payment services.

Disclaimer: PayPal’s API is among the worst I’ve ever had to deal with. Inconsistencies, sometimes poor or conflicting documentation, unpredictable failures and account changes, and major differences between the live and sandbox versions all conspire to make the PayPal API quite a pain in the arse to work with. Over the years, I’ve taken my lumps from working quite a bit with the PayPal API, and I’ve published the results of my hard-learned lessons as a commercial PHP PayPal API component on the source-code marketplace Binpress.

In this post, I will break down some of the techniques and approaches to working with the PayPal API, in order to make integration and troubleshooting simpler and easier.

 in Getting Started With The PayPal API

The Different Payment Options

PayPal offers a variety of payment options, which might be confusing at first:

  • Express Checkout
    The premier PayPal service. Express Checkout allows you to receive payments without having a merchant account and without having to meet special requirements other than verifying your account (either via a bank account or a credit card). Previously, you could receive Express Checkout payments from PayPal users only, but PayPal has since added a credit-card option for non-PayPal users, making this service accessible to practically anyone with a major credit card. Note that the Express Checkout process occurs on PayPal’s platform and thus can never be fully integrated in your website’s experience.
  • Direct Payment
    The Direct Payment method allows you to receive credit-card payments directly through an API call. This enables you to host the payment process on your website in full, which might make for a more complete shopping experience for your customers. The Direct Payment method has several variations that enable you to authorize a payment and complete it at a later date: the appropriately named Authorization and Capture methods. These variations are a part of the Website Payments Pro API, which is available only to US, Canadian and UK accounts.
  • Recurring Payments
    This allows you to set up a recurring transaction (i.e. a subscription payment).
  • Mass Payments
    This allows you to transfer money to multiple accounts at once.
  • Adaptive Payments
    Here is another API for sending funds to multiple recipients, with some differences from the Mass Payments API. (Did I mention that the PayPal API is confusing and a bit redundant?)

This list is not comprehensive, but it covers the main payment options (see the API documentation for more).

Making API Requests

PayPal supports two main formats over HTTP: NVP and SOAP. NVP is short for Name-Value Pair, and SOAP stands for Simple Object Access Protocol. I will cover the NVP approach, which I prefer to SOAP’s relatively verbose and complex syntax.

Each of the API methods has different parameters, but they all share some basic parameters, which are used to identify the API account and sign the transaction. These include:

  • USER
    Your PayPal API user name.
  • PWD
    Your PayPal API password.
    The version number of the NVP API service, such as 74.0 (the most recent as of this writing).
    Your PayPal API signature string. This parameter is optional if you use a certificate to authenticate.

The last required parameter is METHOD, which declares which API method we are calling.

Requests are made over HTTPS. We’ll use cURL to build our basic request, and then encapsulate the process in a class:

class Paypal {
    * Last error message(s)
    * @var array
   protected $_errors = array();

    * API Credentials
    * Use the correct credentials for the environment in use (Live / Sandbox)
    * @var array
   protected $_credentials = array(
      'USER' => '',
      'PWD' => '1297608792',
      'SIGNATURE' => 'A3g66.FS3NAf4mkHn3BDQdpo6JD.ACcPc4wMrInvUEqO3Uapovity47p',

    * API endpoint
    * Live -
    * Sandbox -
    * @var string
   protected $_endPoint = '';

    * API Version
    * @var string
   protected $_version = '74.0';

    * Make API request
    * @param string $method string API method to request
    * @param array $params Additional request parameters
    * @return array / boolean Response array / boolean false on failure
   public function request($method,$params = array()) {
      $this -> _errors = array();
      if( empty($method) ) { //Check if API method is not empty
         $this -> _errors = array('API method is missing');
         return false;

      //Our request parameters
      $requestParams = array(
         'METHOD' => $method,
         'VERSION' => $this -> _version
      ) + $this -> _credentials;

      //Building our NVP string
      $request = http_build_query($requestParams + $params);

      //cURL settings
      $curlOptions = array (
         CURLOPT_URL => $this -> _endPoint,
         CURLOPT_VERBOSE => 1,
         CURLOPT_SSL_VERIFYPEER => true,
         CURLOPT_CAINFO => dirname(__FILE__) . '/cacert.pem', //CA cert file
         CURLOPT_POST => 1,
         CURLOPT_POSTFIELDS => $request

      $ch = curl_init();

      //Sending our request - $response will hold the API response
      $response = curl_exec($ch);

      //Checking for cURL errors
      if (curl_errno($ch)) {
         $this -> _errors = curl_error($ch);
         return false;
         //Handle errors
      } else  {
         $responseArray = array();
         parse_str($response,$responseArray); // Break the NVP string to an array
         return $responseArray;

Note that I use a CA certificate file for SSL certificate validation. You can obtain the file from the cURL website or any trusted source. Update the path to the certificate file according to where you’ve placed it.

The response returned will be in NVP format as well, and I reformat it into an array before returning it. A parameter named ACK signifies the status of the request: Success or SuccessWithWarning when the request succeeds, and Error or Warning when the request fails.

A request could fail for many reasons, and there are different reasons for each API method, which are covered in detail in the manual. We’ll go over some further down in this article and look at ways to handle them. Keep in mind that the parameter values are case-sensitive, so code against them accordingly.

Express Checkout

One of the most popular APIs is the Express Checkout API, which enables you to receive payments without opening a Website Payments Pro account (which is available only to verified US accounts) or hosting the actual transaction yourself (which requires additional security).

The Express Checkout process works as follows:

  1. We request a checkout token from PayPal using the transaction details;
  2. If successful, we redirect the user to the PayPal endpoint using the received token;
  3. The user completes or cancels the payment on the PayPal platform and is redirected back to our website;
  4. We complete the payment either when the user is redirected back or via an Instant Payment Notification (IPN).

Scr Ukexpresscheckout-cut in Getting Started With The PayPal API

1. Getting the Checkout Token: SetExpressCheckout

We initiate the Express Checkout process by passing the order details to the PayPal API, and we receive a token string that identifies it. This token would be used in the next step to redirect to PayPal.

Here are the required parameters:

    This is the API method that we’re using (i.e. SetExpressCheckout).
    The URL that the user will be redirected to after the payment process is completed.
    The URL that the user will be redirected to after having cancelled the payment process.
    The transaction’s total amount. This must have two decimal places, with the decimal separator being a period (.). The optional thousands separator must be a comma (,).
    The total cost of the items in the order, excluding shipping, taxes and other costs. If there are no extra costs, then it should be the same value as PAYMENTREQUEST_0_AMT.

We can pass additional parameters to add more information about the order, some of which have default values:

    The payment’s currency, as a three-letter code. The default is USD.
    The total shipping costs for this order.
    The total tax amount for this order. This is required if per-item tax is specified (see below).
    The order’s description.

We can also add details about individual items in the order:

    The item’s name.
    The item’s description.
    The item’s cost.
    The quantity of an item.

The variable index m identifies the item. (Use the same variable for all details of the same item.)

There are many other optional parameters, which can be found in the API documentation.

We’ll use the function that we wrote above to build the SetExpressCheckout request:

//Our request parameters
$requestParams = array(
   'RETURNURL' => '',
   'CANCELURL' => ''

$orderParams = array(
   'PAYMENTREQUEST_0_AMT' => '500',

$item = array(
   'L_PAYMENTREQUEST_0_NAME0' => 'iPhone',
   'L_PAYMENTREQUEST_0_DESC0' => 'White iPhone, 16GB',
   'L_PAYMENTREQUEST_0_AMT0' => '496',

$paypal = new Paypal();
$response = $paypal -> request('SetExpressCheckout',$requestParams + $orderParams + $item);

2. Redirecting to PayPal Using the Checkout Express Token

If the request is successful, we’ll receive a checkout token in the TOKEN parameter of the response.

if(is_array($response) && $response['ACK'] == 'Success') { //Request successful
      $token = $response['TOKEN'];
      header( 'Location:' . urlencode($token) );

The user now goes through the purchase process on PayPal’s website. When they confirm or cancel it, they will return to one of the URLs that we’ve specified in the request.

3. Completing the Transaction

Assuming the user confirms the transaction, they will be redirected to our website by PayPal. At this point, we should use two relevant API methods: DoExpressCheckoutPayment will complete the transaction, but before that we might want to get additional information on the buyer using GetExpressCheckoutDetails.

PayPal will redirect the user back from the purchase with the checkout token, which we will use to call those methods. The token will be available in the URL query parameters via the token parameter. We will check for its existence in the confirmation URL and then send our API requests if we find it.

The GetExpressCheckoutDetails method requires only the checkout token. DoExpressCheckoutPayment requires a couple of additional parameters:

    This is the payment action. It should be set to Sale unless we’ve specified a different action in the SetExpressCheckout method (possible values include Authorization and Capture).
    This is the unique identification for the PayPal account. This, too, is returned in the URL query parameters (in the PayerID parameter) and can also be retrieved from the details returned by GetExpressCheckoutDetails.
if( isset($_GET['token']) && !empty($_GET['token']) ) { // Token parameter exists
   // Get checkout details, including buyer information.
   // We can save it for future reference or cross-check with the data we have
   $paypal = new Paypal();
   $checkoutDetails = $paypal -> request('GetExpressCheckoutDetails', array('TOKEN' => $_GET['token']));

   // Complete the checkout transaction
   $requestParams = array(
      'PAYERID' => $_GET['PayerID']

   $response = $paypal -> request('DoExpressCheckoutPayment',$requestParams);
   if( is_array($response) && $response['ACK'] == 'Success') { // Payment successful
      // We'll fetch the transaction ID for internal bookkeeping
      $transactionId = $response['PAYMENTINFO_0_TRANSACTIONID'];

Direct Payment

The Direct Payment API allows you to receive payments directly on your website or application, giving you complete control over the checkout process. PayPal tends to push users to register and use a PayPal account, which is understandable, but this conflicts somewhat with our interest to make the payment process as simple and clear as possible for our customers. For this reason, full control over the checkout process is preferred and gives us more options to optimize sales and generate more sales.

Scr Ukdirectpayment-cut in Getting Started With The PayPal API

The process is a bit simpler than that of Express Checkout, because the entire interaction occurs on our website, and we need to perform just one API call to process a normal payment: DoDirectPayment.

A couple of more API requests are required if you want to perform a transaction that is billed at a later date (for example, when you ship the product or confirm availability). These would be the Authorization & Capture API methods, which I will not cover in this post, but be aware that this option exists.

DirectPayment Parameters

DirectPayment requires different parameters than Express Checkout, as to be expected. While the transaction details parameters are similar (with different key names, to make it more interesting), the method also requires credit-card and address information.

DirectPayment’s basic parameters:

    This is DoDirectPayment.
    This is the IP address of the payer. In PHP, we can retrieve it using the superglobal $_SERVER['REMOTE_ADDR']. You’ll have to do a bit more work to get the IP when dealing with set-ups that have a proxy between the PHP process and the outside network (such as nginx).
    This is the type of action that we want to perform. A value of Sale indicates an immediate transaction. A value of Authorization indicates that this transaction will not be performed immediately, but rather will be captured later using the Authorization & Capture API mentioned earlier.

Credit-card details:

    The credit-card type (Visa, MasterCard, etc.). See the API documentation for the full list.
  • ACCT
    The credit-card number. (Don’t you love these abbreviated key names?) This must conform to the particular format of the card’s type.
    The expiration date, in MMYYYY format (i.e. a two-digit month and a four-digit year, as one string).
  • CVV2
    The “card verification value,” or security code, as it’s sometimes known.

Payer information and address parameters:

    The payer’s first name and last name, respectively (in separate fields). You can also provide an email address in an EMAIL parameter, but it’s not required.
    The city, state, country code (as a two-letter code) and zip code parts of the address, all required.
    Two lines for the address (only the first is required).

This address will be used in the address verification system (AVS). You’ll receive a specific error code if a transaction has failed due to an address verification failure.

The payment details parameters are the same as the ones for Express Checkout, but with slightly different names (AMT, ITEMAMT, CURRENCYCODE, SHIPPINGAMT, TAXAMT and DESC) and without the PAYMENTREQUEST_0_ prefix. Refer to the previous section or the API documentation for specific details on those.

Similarly, the item details parameters are similar to those of Express Checkout. These include L_NAMEm, L_DESCm, L_AMTm and L_QTYm, giving you granular control of item details in the order summary. The m integer variable is used to account for multiple items (replace with 0, 1 and so on for numbered items in the order). See the API documentation for a comprehensive list of item details.

Performing the Transaction

Sending the request using our function is very similar to GetExpressCheckoutToken. We pass all of the parameters into the request function as before, with the method set to DoDirectPayment.

$requestParams = array(
   'PAYMENTACTION' => 'Sale'

$creditCardDetails = array(
   'CREDITCARDTYPE' => 'Visa',
   'ACCT' => '4929802607281663',
   'EXPDATE' => '062012',
   'CVV2' => '984'

$payerDetails = array(
   'FIRSTNAME' => 'John',
   'LASTNAME' => 'Doe',
   'STATE' => 'NY',
   'CITY' => 'New York',
   'STREET' => '14 Argyle Rd.',
   'ZIP' => '10010'

$orderParams = array(
   'AMT' => '500',
   'ITEMAMT' => '496',
   'SHIPPINGAMT' => '4',

$item = array(
   'L_NAME0' => 'iPhone',
   'L_DESC0' => 'White iPhone, 16GB',
   'L_AMT0' => '496',
   'L_QTY0' => '1'

$paypal = new Paypal();
$response = $paypal -> request('DoDirectPayment',
   $requestParams + $creditCardDetails + $payerDetails + $orderParams + $item

if( is_array($response) && $response['ACK'] == 'Success') { // Payment successful
   // We'll fetch the transaction ID for internal bookkeeping
   $transactionId = $response['TRANSACTIONID'];

There are plenty of parameters, but all relatively simple.

Error Handling

In a perfect world, this section would not exist. In reality, you will be referring to it quite a lot. PayPal can fail a transaction for a multitude of reasons, not all of which you can control.

The $response variable we returned from our paypalApiRequest() function could contain a different value than Success for the ACK parameter. That value could be:

  • Success
    Indicates a successful operation.
  • SuccessWithWarning
    Indicates a successful operation, and that messages were returned in the response that you should examine.
  • Failure
    Indicates a failed operation, and that the response contains one or more error messages explaining the failure.
  • FailureWithWarning
    Indicates a failed operation, and that messages were returned in the response that you should examine.

This gives us two success statuses and two failure statuses. The mock code above tests for the Success value only, but we could change it to check for SuccessWithWarning as well; and keep in mind that we need to find out what the warning is. A common scenario is that a Direct Payment charge will have been performed successfully, but the credit-card company responds that the transaction has failed, for whatever reason.

Errors from PayPal are returned in four parameters in the response:

    A numeric error code, which can referenced against PayPal’s error code list (there are quite a few).
    A short error message describing the problem.
    A longer error message describing the problem.
    The severity code. (I couldn’t find any useful documentation on this, and it doesn’t really matter, so let’s put it aside.)

The 0 part of these parameters is an incrementing integer for multiple error message (1, 2, etc.).

Here are some common errors you’ll run into:

  • 10002
    Authentication or authorization failed. This usually indicates invalid API credentials, or credentials that do not match the type of environment you are working in (such as a live or sandbox environment).
  • 81***
    Missing parameter. There are quite a few of these, all starting with 81. Each refers to a specific required parameter that is missing from the request.
  • 104**
    Invalid argument. This indicates that one of the supplied parameters has an invalid value. Each argument has specific errors, all starting with 104. A common one is 10413, which means that the total cost of the cart items does not match the order’s amount (i.e. the total amount parameter, AMT, does not equal the items’ total plus shipping, handling, taxes and other charges).

How Do We Handle These Errors in Practice?

PayPal error messages vary and could contain private information that you do not want your users to see (such as an invalid merchant configuration). That being the case, showing PayPal error messages directly to users is not advisable, even though some of them might be useful.

In most cases, I would do the following:

  1. Set up a white-list array of errors that can be shown safely (such as a missing credit-card number and expiration date);
  2. Check the response code against that array;
  3. If the error message is not white-listed, then display a generic message, such as “An error has occurred while processing your payment. Please try again in a few minutes, or contact us if this is a recurring issue.”

If an error falls outside of the white-listed array, I will also log it to a file on the server and send an email to the administrator, with the full details so that someone is up to speed on payment failures. In fact, logging PayPal requests and responses is good practice regardless of errors, so that you can monitor and troubleshoot payment failures (I provide this option in the commercial component that I mentioned at the beginning of this article).

Ready To Get Started With The PayPal API?

In this post, I’ve covered two of the most widely used API methods, as well as error handling with the PayPal API. This should be enough for you to get started using the most popular payment platform online.

The PayPal API has many more methods and processes, more than can be covered in any one post. Once you get up to speed on the basic methods, learning the others should be relatively straightforward (even if somewhat exhausting). I hope this guide has given you a good head start on using the API. If you have questions or comments, I would love to hear from you in the comments!

Front cover: Image source


© Eran Galperin for Smashing Magazine, 2011.

April 11 2011


Taking Credit Card Payments Online: What’s Involved?

Advertisement in Taking Credit Card Payments Online: What’s Involved?
 in Taking Credit Card Payments Online: What’s Involved?  in Taking Credit Card Payments Online: What’s Involved?  in Taking Credit Card Payments Online: What’s Involved?

If you’re looking to integrate a credit card payment solution onto your website, the following steps are a guide to applying for, enabling and taking payments online. At first glance, the prospect of integrating a payment solution on a website can seem unwieldy, what with the vast array of payment options and technical acronyms. This article breaks down the entire process into bite-sized pieces, helping you understand the process much better.

Apply For An IMA

When taking any kind of credit card payments connected to a bank account, you must apply for a merchant account with a bank. If the payments will be taken online, you’ll specifically need an Internet Merchant Account (IMA). In addition to banks, in many locations there are dedicated merchant account providers you can use.

Even if you currently take “card-not-present” payments (such as for mail orders) or use in-store payment terminals (such as chip-and-pin), you still have to speak with your bank about taking payments via your website (ask your bank for an additional IMA ID).

As a broad overview, your bank acts as the “acquirer,” which confirms available funds, authorizes transactions and exchanges funds with the issuing bank of the credit card (e.g. Visa, MasterCard), i.e. the card holder’s bank. The funds are then transferred to your account (the merchant), minus the applicable fees. The issuing bank’s charges are called interchange fees, and your bank’s fees are the acquirer’s fees. As the merchant, you should be informed of any fees prior to signing the merchant services agreement with your bank and payment service provider (more about this further down).

MASTER-VISA-CIRRUS in Taking Credit Card Payments Online: What’s Involved?

Your acquiring bank will expect your website to operate within a strict set of rules in order for them to comply with their own security procedures and government legislation (more on that later, too). Some credit card providers have developed the technology to allow card holders to authenticate themselves online. MasterCard’s is called MasterCard SecureCode, and Visa’s is called Verified by Visa.

It’s worth noting that it is possible to process Internet payments manually, using your regular point of sale system. This isn’t recommended, though, partly due to security reasons, and partly because it can quickly become too much work to manually process payments taken through your website (do you really want to have to key in a thousand individual cards if you suddenly have a huge uptick in sales?). Also, some merchant agreements may specifically prohibit this type of payment processing. Even if you do decide to process payments manually, you’ll still need an Internet Merchant Account, because it’s where the transaction is initiated that counts, not where it’s eventually processed.

Select A PSP

In addition to an IMA, you will need to use the services of a payment service provider (PSP). Commonly, PSPs handle the pages on a website where customers submit their payment details. PSPs provide a “virtual” cashier, or point-of-sale terminal, that collects card details, screens for fraud and securely passes the details to your acquiring bank for processing. PSPs are sometimes referred to as payment gateways.

The PSPs offer various packages and rates to suit the requirements of different merchants. The main difference between packages comes down to whether you want to host the secure payment pages on the PSP’s servers or on your own server. Some PSPs also provide tailored solutions.

It’s worth noting that some PSPs also provide IMAs, and some acquiring banks provide PSP services.

Payment-Processing Companies

As is often the case, there are alternatives to the approach outlined above, especially if you want to avoid the challenge of technically implementing one of these solutions. One alternative is to use the services of a payment-processing company. This option eliminates the need to apply for an IMA and PSP separately. The application process of a payment processing service is usually a lot less stringent than that for an IMA, which results in a faster set-up, especially if you have little or no trading history.

The disadvantage is that your customers will be sent to the processing company’s website in order to make their payment. Also, settlement periods can take much longer (up to 60 days), and your overall cost may be slightly higher than if you had gone with an IMA and PSP.

Not all payment-processing companies operate like this, though. Some companies, including PayPal and Google Checkout, remit payment immediately in most cases, directly into your account. In other words, as soon as the payment is made by your customer, the money is deposited into your merchant account.

A Sample Checkout Process

Here’s a step-by-step example of a common credit card payment process for any website:

Step 1: The Basket

Your customer has added a product to their basket and is ready to proceed to checkout. The basket page on your website should be SSL encrypted to bolster the customer’s confidence (but that’s for another article).

Step 2: The Checkout

The customer proceeds to the next page of your website: the checkout page. You can have various options here: account log-in page, shipping options, etc. But for the purpose of this example, let’s assume the first stage of checkout is simply a page that requires the customer to submit some personal details, such as contact info and a billing and shipping address.

Once the required fields are submitted and validated, the details are first securely sent to your back-end database, then wrapped up and securely passed to your PSP’s website. The customer is also redirected to the PSP’s website.

Let’s pause for a second and look at what’s happening here. Your customer’s data should be encrypted when sent to the PSP, not stored in plain text. So, you make a function call to your PSP’s API, requesting the transfer of data. The API’s function will usually require a set of parameters that include the merchant’s ID, a unique order reference, the transaction’s total charge and currency, and all of the billing and shipping mentioned above.

The function will then either return an encrypted version of your data, ready to be posted to the PSP’s payment pages, or hold onto the data and return a secure key in receipt that verifies that particular set of data against the transaction. You would store this key along with the order details and then redirect the customer to the PSP’s payment pages.

Step 3: Payment

Your customer arrives on the PSP’s secure payment pages. Technically, keeping the customer on your website at this stage is possible (if the PSP has this option), but let’s keep this simple. If the PSP’s pages duplicate some of the fields on your own checkout page (like the billing and shipping address), then these fields can be pre-populated.

Once all of the card holder’s data has been submitted and payment has been made, your customer is seamlessly returned to your website.

OK, some stuff is also going on in the background here, too. First, the card holder’s details are authenticated by the PSP using a variety of security procedures. Next, the card holder’s total charge must be authorized and the funds allocated to the merchant. Technically, the merchant should not take payment directly, but rather take a deferred payment until the goods have actually shipped (see the regulations on distance selling below).

Your PSP would then send the status of the transaction’s outcome to your website, along with the unique order reference (to identify the order) and any other pertinent data, including security-related confirmations such as CV2 and postal code checks.

You should make sure that your e-commerce store follows the PCI complance guidelines for storing, accessing and managing sensitive credit card data. This Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that all companies that process, store or transmit credit card information maintain a secure environment.

It applies to all organizations or merchants, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data. So, if any customer of that organization ever pays the merchant directly using a credit card or debit card, then the PCI DSS requirements apply. This server security standard is required by almost all major credit card providers, or you risk the potential for steep daily fines. (Thanks to Brian and Rebecca in the comments for pointing it out!)

Step 4: Order Confirmation

On returning to your website, the customer is presented with a confirmation page indicating whether the payment has been authorized or declined.

The PSP passes variable data (such as an order reference) back to your website, which you use to look up the order data on your database and present the appropriate content.

PSP Checklist

Check that your PSP provides the following features:

  • SSL encryption on all payment pages,
  • Authentication procedures,
  • API to securely post data from your website,
  • Call-back API to indicate payment confirmation (which should contain multiple status descriptions),
  • Option to pre-populate fields on payment pages,
  • Feature to customize payment pages to match your layout and branding,
  • Redirection back to your website upon payment completion.

Gateway Comparison

Below is a comparison of a small selection of gateways. The list is in no particular order and is in no way a recommendation of any particular one.

Sage Pay (UK and Ireland)

Here is a summary of Sage Pay Go with Server Integration:

Payment-1011 in Taking Credit Card Payments Online: What’s Involved?

  • Separate test and live servers
    A simple yet convenient way to test your integration prior to going live. Once you are happy that everything is working as intended, all that’s required to go live is a change to the server’s URL in your code.
  • iFrame support
    Gives the appearance that your payment pages are actually on your website (an SSL certificate is required if you opt for this). Keeping customers on your website rather than sending them to the gateway’s website in order to complete payment could increase your conversion rate.
  • Extensive payment page customization
    If you do send users to Sage Pay’s website to complete their payment, you can customize the page so that it looks more like your website. However, the templates are created in XML, which makes them more complicated than the standard HTML templates of some other solutions.
  • Manual approval process for template changes
    This part of the integration process is slightly inconvenient. Every time you amend your custom payment page, you have to manually submit it to Sage Pay and then wait (usually no more than 24 hours) for it to update the template.
  • Initial post done by server, not the browser
    None of the order details are exposed in the HTML page. The customer’s order data is posted using cURL over SSL. A redirection URL is returned to direct the user to the payment pages. Arguably, this is more secure than posting data in the HTML page. I also like the way that payment page URLs are returned, which saves them from being stored and possibly having to be amended.
  • Call-back
    When Sage Pay’s server responds to your server with details of the payment outcome, there’s a function to validate the data by matching secure keys.
  • Account Parameter Configuration
    Numerous account parameters are stored in the admin control panel. One in particular is the “Valid IP address,” which specifies several IP entries from where the initial data registration must originate.

Barclaycard (UK)

It’s a common misconception that you need to bank with Barclays in order to use its ePDQ CPI payment solution. If you do not bank with Barclays, you can still apply for its IMA and PSP solution. Cleared funds will be transferred to your chosen bank.

Payment-102 in Taking Credit Card Payments Online: What’s Involved?

  • Testing
    As of this writing, no test server is available with the ePDQ solution. You can post test variables though the ePDQ, which flags a test transaction, but these details are not processed to simulate a successful end-to-end transaction. To get around this, we created a test page that emulates the call-back response, which is basically an HTML form containing an order reference and status field that’s posted to the call-back page.
  • Data posted via browser
    There’s a big difference between how data is sent with ePDQ and how it is done with Sage Pay. For example, only a handful of data is initially sent to ePDQ for encryption (via a socket connection). Upon receipt, the encrypted string along with the remaining data is posted via the browser within the form, as opposed to the data being sent via the server.
  • Call-back
    ePDQ’s server posts a call-back response that contains only the transaction status and your unique reference (order ID). While this is sufficient to update your database, there’s no way to check where the call-back is coming from. We can emulate this in our test phase (mentioned above), but ePDQ does require the call-back script to be stored in a password-protected directory.
  • Account parameter configuration
    Quite a few account parameters are stored in the ePDQ configuration area, including an “allowed URL” (where the initial call must originate) and a “Post URL” (where the call-back script resides). There are also “POST” user names and passwords for the call-back directory.

WorldPay (Worldwide)

As with ePDQ, you don’t need an RBS bank account in order to use its WorldPay Business Gateway (formerly Select Junior).

Payment-103 in Taking Credit Card Payments Online: What’s Involved?

  • Separate test and live servers
    As with Sage Pay, WorldPay has separate URLs for the test and live servers.
  • Data posted via browser
    Data is also sent via the browser, either as a POST or GET. I wanted to see if you could send the customer’s data to the gateway without a clunky JavaScript form post, but while it’s technically possible for the GET to be intercepted en route, WorldPay has the mandatory key signature field that counters this threat by matching the received values against those contained in the signature.
  • Call-back
    Like ePDQ, WorldPay’s server posts a payment response containing the transaction’s status and your unique reference (order ID). While this is sufficient to update your database, there’s no way to check where the call-back is coming from.
  • Payment page templates
    The payment page templates are fairly flexible because you can create a Y and C (success and failure) HTML page that closely matches your website. WorldPay has “smart tags” for data such as order ID and merchant name that must be included on your custom page. A slight difference here is that your website’s return URL must be included in the template.
  • Account parameter configuration
    Quite a few account parameters are stored in the installation area: a payment response URL for the call-back script and a payment response password for the call-back script’s directory password. However, there doesn’t appear to be a setting for “allowed URLs” or IP addresses to validate the origin of the merchant’s data. (Worldwide) is one of the larger payment gateways, with more than 300,000 sites currently using it.

Payment-104 in Taking Credit Card Payments Online: What’s Involved?

  • Accept a Variety of Payments lets you accept all major credit cards, eChecks, gift cards, and signature debit cards.
  • Payments Within Days
    Payments are made quickly, generally within days of the original transaction.
  • Fraud Prevention Tools has tools in place to identify suspicious transactions, both through built-in tools and add-on products.
  • Free Support
    They have live tech support and account support, plus online user guides and documentation.
  • Developer Tools and Reseller Accounts also offers developer tools for creating payment solutions, as well as reseller accounts to developers and service providers.

2Checkout (Worldwide)

2Checkout offers a number of payment gateway services, and has been handling e-commerce payments for more than 10 years.

Payment-105 in Taking Credit Card Payments Online: What’s Involved?

  • Hosted Payments
    2Checkout offers hosted payments, with simple plug-n-play code for integrating their payment gateway into your existing website and shopping cart software. They collect, store, and encrypt the credit card information your customers submit, all in accordance with industry standards.
  • Recurring Billing
    They can handle recurring billing options for subscriptions or similar purchases.
  • Co-Branded Payment Pages
    Co-branded payment pages are used “so that they customer recognizes the hand-off from your site to ours.” This could be viewed as a good or a bad thing depending on the image the e-commerce site is looking to convey. Some customers are reassured by being redirected to a larger payment processor, while others are sometimes put off by it.
  • Variety of Payment Methods
    They accept 15 different payment methods, including Visa, MasterCard, American Express, Diner’s Club, and even PayPal.

Google Checkout

Google Checkout removes much of the hassle of setting up online payments by removing much of the barrier to entry. If you have a Google account, you can have Google Checkout set up within a few minutes.

Payment-106 in Taking Credit Card Payments Online: What’s Involved?

  • Variety of Integration Options
    Google Checkout has some of the most versatile integration options out there. Sure, you can just set up a “Buy Now” button or two, but they also offer integration with custom shopping carts, pre-integration with existing shopping cart systems, a store gadget (that you can set up with a Google Spreadsheet), email invoices, and their own shopping cart solution.
  • Google is a Recognized Brand
    Google is recognizable all over the world, and is a trusted brand for the most part. This can be especially valuable to smaller, unknown businesses who might not have their own good reputation to ride on.
  • API Developer’s Guide
    Developer’s can have a field day with the developer API for Google Checkout. It means you can customize the Google Checkout experience to your heart’s content.
  • Protection from Chargebacks
    Chargebacks can be a big problem for some businesses, especially those in higher-risk industries. Google Checkout offers a Payment Guarantee that protects an average of 98% of all Google Checkout transactions. If your transaction falls under their guarantee, and there’s a chargeback, you won’t lose money.


PayPal started as a solution for eBay sellers to accept credit card payments but has turned into a major player in the online payment gateway industry.

Payment-107 in Taking Credit Card Payments Online: What’s Involved?

  • Recognizable Name
    PayPal has become almost as big a household name as Google. Some consumers have gone so far as refusing to do business with online retailers who don’t accept PayPal.
  • Solutions for Every Kind of Business
    PayPal now provides a range of solutions for businesses, including fully-featured merchant accounts like those you’d find at a bank (Payflow Payment Gateway). Their Website Payments accounts provide most of what a gateway provides, including the ability to keep customers on your site through the entire transaction (with the Pro account). And of course PayPal also offers simple “Buy Now” buttons if that’s all you need.
  • Immediate Payment
    PayPal pays immediately for most transactions, which means that your payments go directly into your PayPal account when they’re made. (This is not always the case for certain businesses, or for accounts with a history of high returns.) In some countries, PayPal offers signature debit cards that can be used like a credit card and give you immediate access to your PayPal funds from any ATM.
  • Easy Integration
    PayPal offers a number of developer tools, both for facilitating payments and for accessing account information and reporting. Various PayPal payment processing products have different levels of difficulty when it comes to integration, but at the easiest end of the spectrum it involves just inserting a bit of code.


Taking credit card payments online is a fairly straightforward process, but you should understand what your options are and how each option suits your business objectives. The solutions available range from simple pieces of JavaScript for “Buy now” buttons (PayPal and Google Checkout do this) to self-hosted secure payment pages. Some solutions are attractive for their ease of integration, some for their price and others for their flexibility. Hopefully, this article has helped you choose a payment solution for your website.

Note: Thanks to Cameron Chapman for her much appreciated improvements and research for this article. You might want to take a look at the article Web apps, credit cards, merchant accounts and PayPal for a related case study for the issue covered in this article.

(al) (ik) (vf)

© Leigh Mason for Smashing Magazine, 2011. | Permalink | Post a comment | Smashing Shop | Smashing Network | About Us
Post tags: credit card, payments, paypal

September 15 2010


How to Sell Digital Goods with CodeIgniter: New Premium Tutorial

In today’s tutorial, you’ll learn how to create a small web app to sell digital items (eg. eBooks) securely and accept payments from PayPal. Become a Premium member to read this tutorial, as well as hundreds of other advanced tutorials and screencasts.

How to Sell Digital Goods with CodeIgniter: New Premium Tutorial

Join Net Premium

NETTUTS+ Screencasts and Bonus Tutorials

For those unfamiliar, the family of Tuts+ sites runs a premium membership service. For $9 per month, you gain access to exclusive premium tutorials, screencasts, and freebies from Nettuts+, Psdtuts+, Aetuts+, Audiotuts+, Vectortuts+, and CgTuts+ For the price of a pizza, you’ll learn from some of the best minds in the business. Become a Premium member to read this tutorial, as well as hundreds of other advanced tutorials and screencasts.

Other Awesome Premium Tuts you may Like

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!