Taking Credit Card Payments Online: What’s Involved?

Advertisement

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).

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 complance1 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 Integration2:

Screenshot3

  • 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 CPI4 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.

Screenshot5

  • 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 Gateway6 (formerly Select Junior).

Screenshot7

  • 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.

Authorize.Net (Worldwide)

Authorize.Net8 is one of the larger payment gateways, with more than 300,000 sites currently using it.

Screenshot9

  • Accept a Variety of Payments
    Authorize.Net 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
    Authorize.Net 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
    Authorize.Net also offers developer tools for creating payment solutions, as well as reseller accounts to developers and service providers.

2Checkout (Worldwide)

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

Screenshot11

  • 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 Checkout12 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.

Screenshot13

  • 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

PayPal14 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.

Screenshot15

  • 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.

Summary

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 PayPal16 for a related case study for the issue covered in this article.

(al) (ik) (vf)

Footnotes

  1. 1 http://www.pcicomplianceguide.org/
  2. 2 http://www.sagepay.com/products_services/sage_pay_go
  3. 3 http://www.sagepay.com/products_services/sage_pay_go
  4. 4 http://www.barclaycardbusiness.co.uk/epdq_cpi/
  5. 5 http://www.barclaycardbusiness.co.uk/epdq_cpi/
  6. 6 http://www.rbsworldpay.com/products/index.php?page=ecom&sub=business&c=UK
  7. 7 http://www.rbsworldpay.com/products/index.php?page=ecom&sub=business&c=UK
  8. 8 http://www.authorize.net/
  9. 9 http://www.authorize.net/
  10. 10 https://www.2checkout.com/
  11. 11 https://www.2checkout.com/
  12. 12 https://checkout.google.com/sell/
  13. 13 https://checkout.google.com/sell/
  14. 14 http://paypal.com
  15. 15 http://paypal.com
  16. 16 http://playnice.ly/blog/2011/03/23/web-apps-credit-cards-merchant-accounts-and-paypal/

↑ Back to topShare on Twitter

Leigh Mason is the founder of Silkstream, a UK-based web agency. Leigh and his team have been actively involved in ecommerce for over 10 years and currently manage numerous successful ecommerce websites for their clients.

Advertising
  1. 1

    Our US-based Volusion cart required a payment processor who was willing to accept that our bank was based in Hong Kong (HSBC) since our parent company is located there. That only left one provider: WorldPay.

    HUGE WORD OF CAUTION: WorldPay won’t deposit your funds into your bank until 30 days have passed. Even more troublesome, it is their policy to send your customer an email telling them a transaction has occurred, even though WorldPay’s involvement is otherwise invisible to them. This can only lead to confusion and misunderstanding.

    I can only speak of our experience with WorldPay and don’t know if these are standard practices with all of their clients.

    4
  2. 2

    Can anyone recommend a Quality solution to be used in Spain?

    1
  3. 3

    I’m surprised at the lack of mention for PCI compliance. This server security standard is required by almost all major credit card providers, or you risk the potential for steep daily fines. Other than that omission a great article and it helps provide a concise overview of what needs to happen to process credit information.

    12
    • 4

      looks like we posted simultaneously… :-)

      0
      • 5

        Vitaly Friedman

        April 11, 2011 9:23 am

        Thank you, guys, the article is now updated.

        2
        • 6

          I don’t suppose there is any chance of an article dedicated to PCI compliance is there? The topic is incredibly confusing, and scary for a small start-up business.

          It also seems that their is no cheap way to comply (less than £30/month), unless I have missed something. This seems quite a large sum for a small business.

          1
    • 7

      Also, don’t forget that it is illegal to open up a another web site in an iframe for transactions unless you are PCI compliant. The article should really have this part removed or updated.

      -2
  4. 8

    informative article, however there is no mention of PCI Compliance which is a huge issue if you’re developing an e-Commerce site in a corporate setting.
    For example, the last sentence in Step 3 that says “You would then store this data along with the original order in your back-end database.” would be a huge no-no.

    14
    • 9

      Why aren’t you allowed to store credit card data (not counting the CVV2 code) as long as your site is PCI compliant?

      That being said, the article never suggested you store credit card data, it said you store transaction information returned to you buy the PSP which is an absolutely must in order to match up orders between your server and your PSP’s.

      -2
      • 10

        If you look at PCI, it is permissible to store card data provided that it is stored securely encrypted and that no track or cvv data is stored (50,000 ft view). It is not necessarily allowed to store it on a publicly accessible server, which in many cases would be the web server with the database on it as well.

        Storing card data is well beyond the scope of most articles. You’ll actually be hard pressed to find any article on how to store card data because nobody wants to be accountable for it being messed up. There are a variety of best practices articles out there. The key management requirements alone are enough to make most look for alternate options.

        Right now the best approach would be to use a secure vault storage for card numbers. This is where the payment gateway stores card numbers and gives the website a customer ID that they can reference for future billing of a customer. Authorize.net, NMI and some others have this capability. The benefit of this type of system is huge as a merchant doesn’t need to worry about the complex security requirements of storing card data and the PCI scope and liability is significantly reduced.

        2
        • 11

          PayPal provides the same functionality as the other payment processors you have mentioned in an API method called DoReferenceTransaction, although it’s use is restricted to users who have been a) using the processor for at least 1 year and b) who have been rigorously verified.

          I was unaware that you couldn’t store card data on a publicly accessible server. Something sounds like semantics to me here, though – what constitutes a publicly accessible server? Any server that has a connection to the internet sounds like a publicly accessible server to me. How are you supposed to store credit card data if you can’t store it on a server with an internet connection?

          -1
          • 12

            When you use the PayPal API you accept – i.e. handle – credit card details on your server and pass them on to PayPal in the background. Even though you do not store the card details, you transmit them – which is enough to be required to be PCI compliant. Storing is only one of the actions which require PCI compliance – transmitting is another one. This is whyt som many open source solutions and self hosted paid solutions are problematic when it comes to PCI compliance. Most do at least the transmitting. It is far better tyo then use an ecommerce solution which transfers the payment transaction to the payment service provider, such as Sell Anywhere Links or ShopFactory, or an online solution which is PCI compliant in the first place, such as Volusion.
            Some open source solutions split the card number in parts, and transmit them separately to supposedly become PCI compliant. But they fail in regards to PCI compliance as well unless they are in a PCI compliant environment, as handling the credit card number is enough to force them into PCI compliance. Splitting=handling=PCI complaince required.
            In regards to the server – a server which stores credit card details must not be directly accessible via the Internet – so it must sit behind a firewall for example, and there must be no direct path to the server. This usually means you need another server which you log into, and from which you can then log into the server with the card details, which in itself must also be protected by a firewall, and which must not be accessible via http, for example.

            0
          • 13

            That’s very true, if the merchant’s website is submitting CC data. Most often times (especially for merchants looking to ‘dip their toe in the water’ with e-commerce) it’s a good idea to let the PSP send, process and store CC data. This removes the PCI compliance onus from the merchant – although it may not look as slick from a user’s perspective!

            0
          • 14

            In a Data Centre scenario you typically only have your Web Servers on the internet; Data servers are in the backend network unaccessible from the Internet.

            0
    • 15

      Sorry, I should have been clearer. I should have said: store the payment outcome status and reference – not the credit card details. In my example the payment is made upon the PSP’s website. All card numbers (often called primary account numbers or PAN) would not be stored, processed or transmitted on the merchant’s website.

      According to the Security Standards Council, if a merchant uses a payment gateway to process their transactions on their behalf and therefore does not store, process or transmit a PAN, PCI DSS requirements do not apply.

      More information on this can be found here: https://www.pcisecuritystandards.org/merchants/index.php

      5
  5. 16

    Tiana Mae Design

    April 11, 2011 9:15 am

    If you’re a small business, another way to take payments online in a flash is to sign up for FreshBooks. They have a very seamless way to a) invoice clients and b) set up all the steps for online payment (above) in a very simple, very efficient way.

    I’d highly recommend FreshBooks for any entrepreneur who is just starting up a small business.

    -4
  6. 17

    I use Drupal + Ubercart, and it can work well with CyberSource, Authorize.net, PayPal, etc. Very nice solution.

    0
  7. 18

    I’ve used 2Checkout.com and PayPal. Here’s what I know, 2Checkout.com, while it is plug-n-play (yet hardly as simple as that sounds), it requires you to maintain 2 product databases (one on their server and one on yours) and is EXPENSIVE – >5%/transaction, yet it doesn’t have a monthly fee.

    I’ve also used PayPal – both website payments standard or professional and I strongly recommend it, both because their API is very powerful, your customers will recognize and trust their name, and because they are quite cheap. 2.9%/transaction, but it can go to 2.5% and 2.2% rather quickly if your business generates a reasonable amount of monthly revenue. While they’re testing servers seem to constantly have bugs arising in them which can be irritating, when you’re finally finished testing the API is excellent and provides for the utmost flexibility when you are designing the payment process (specifically with website payments pro). However, in order to make integration truly painless, you’ll need to download Angel Eye’s payments pro PHP class – http://www.angelleye.com/paypal-payments-pro-php-class/

    With that PHP class in hand, PayPal is the ideal solution, in my opinion, because you can design the checkout experience from start to finish.

    4
    • 19

      I too have integrated both PayPal standard and Pro and found both to be great. You can do a lot with their basic account from simple buy now buttons to shopping carts. The other great tool is PayPal’s developer sandbox. You can view complete transactions as both the customer and the merchant all with fake money and emails, etc.

      I would mention that it took me a long time to organize and find the proper information about developing with the Pro solution. Their docs are fairly scattered and unorganized imo, though, I found their forums to be very helpful.

      0
  8. 20

    2checkout is just awful. Huge commissions (once was over 12%), delayed payouts and they will CLOSE your account and take all your funds if you don’t make a sale in 6 months.

    7
  9. 21

    This article is literally perfect timing for me. Just today I’ve been working on a donate page for a charity website which is something I’ve never had to do before and trying to investigate the various options. PayPal looks especially good for charities as they offer a discounted fee (1.4%) for charities. It might be worth mentioning the fees that each of them take, if at all.

    The other thing is with the charity site I’m working on, we want to have a system of setting up a regular monthly donation online, with gift aid too. I don’t know much about financial things, or about SSL and making pages secure so it’s all a learning experience. This article is really useful and I’ll be looking back over it this week. Thanks.

    Also, if anyone has had any experience doing charity sites and setting up regular monthly donations, it would be great to know what systems you used and what worked best for you. Something like Google Checkout or PayPal is looking good to me right now.

    0
    • 22

      I’ve used Razoo for a non-profit site I built – they’re great to work with. You do have to pay 2.9% on transactions but setup is painless and anyone can donate using either your Razoo page or a Donation Widget which you can drop into a sidebar on your website. They’re Verisign-compliant and take care of all the back-office stuff. Your client gets a check mailed to them once a month. Here’s their NPO page … http://www.razoo.com/p/for_nonprofits

      Good luck!

      0
  10. 23

    Yes – PCI compliance is HUGE deal, you don’t want to expose yourself or your client to the liability and fines that can come from doing this wrong.

    If you don’t understand PCI compliance and yet are dealing with ecommerce and credit cards you need to find a trusted resource asap. This is truly an area where this industry could use some certification of folks who know what they are doing as opposed to all those who guess and assume untold risk.

    One of the best gateways/merchant account providers around to deal with when it comes to ecommerce and online transactions online is: Braintree
    http://www.braintreepaymentsolutions.com/

    A number of leading companies use them: 37Signals, GIthub, Engine Yard, Brightcove, Living Social

    They have an excellent resource on PCI compliance as well:
    http://www.braintreepaymentsolutions.com/services/pci-compliance

    3
  11. 24

    You completely failed to mention state taxes. Charging correct state taxes can be very complicated. You have to charge by exact address, not by zip code. Zip codes and districts do not line up. You have to charge state taxes in any state your company has a nexus in. There are services that you can link into your shopping cart software but they are pretty expensive.

    3
  12. 25

    I’ve used Authorize.net before and have had zero problems. I would recommend them.

    0
  13. 26

    PCI has definitely changed things for us as developers. Most notably, the decisions of which shopping cart application, payment gateway and hosting solution to use has become more complex. Do they need to accept and transmit the payment info from their site or can we use a 3rd-party hosted payment method (e.g. Authorize.net SIM, PayPal, USAePay, Google Checkout, etc.)? Do they need automatic recurring billing, e.g. for subscription sites? Does transaction data need to integrate with their back end accounting systems? Do customers need to have access to previous order and payment data? Although the banks and payment providers don’t appear to yet be breaking down the doors of non-PCI compliant merchants, we think it’s prudent to be better safe than sorry…

    0
  14. 27

    There is a huge number of payment gateways out there. The best ones are the ones that put the money straight into your bank account – but that means you must have a merchant account.

    PayPal helps getting around it – at a cost: The money is stored in their account – you earn no interest and getting access to the money requires pulling the money out of your PayPal account. The advantage is you can accept credit cards without jumping through any hoops.

    Integrating the whole buying or donation functionality into a website can span the whole bandwidth from being really complex – to dead simple.

    For example with Sell Anywhere Links all you do is add a simple link to any existing webpage or email to start accepting orders and donations – such as http://www.megan.giveandhelp.org. On the other hand you have solutions which are less flexible but create the complete website with integrated shopping cart, such as ShopFactory or Volusion and others. Just do a search for shopping cart software online. In all cases you will require a way to actually accept the payments, though.

    While everyone is always focussing on credit cards – there are many manual payment methods available such as pay by check, pick up and pay and so on. So even if you can’t accept credit cards, selling online is not out of your reach.

    PCI is an issue which is often misunderstood – and many open source solutions are simply not PCI compliant because they handle credit cards in non compliant ways in no compliant server environments. Any website which handles credit cards must be PCI compliant – which means also the data centres they are housed in. Many open source solutions accept credit card data directly on the merchant server and pass them on to the payment service – which renders them NON-compliant, unless the server is PCI compliant and is housed in a PCI compliant data centre and the merchant complies with PCI requirements.

    However this problem goes completely away, if you send your customers to an external payment gateway which accepts the credit card payments in a PCI compliant manner on their own website. This means credit cards are never handled on your server – and you don’t have to be concerned about PCI compliance. A small disadvantage with this: The payment gateways are usually not as tighly integrated into your website, but that is a small price compared to achieving PCI compliance, which can cost north of $20,000 -per year, depending on your size and the number of orders you get.

    Whatever provider you chose: make sure you know how long it will take before you actually get your own hands on the money. If you are dependent on cash flow, picking the wrong payment service provider can be a real problem. We are talking about 30 days and more – enough to bring quite a number of companies to their knees, if they or wholly dependent on the online cash flow.

    3
  15. 28

    Storing card data is well beyond the scope of most articles. You’ll actually be hard pressed to find any article on how to store card data because nobody wants to be accountable for it being messed up. There are a variety of best practices articles out there. The key management requirements alone are enough to make most look for alternate options.

    Other thing is PayPal provides the same functionality as the other payment processors you have mentioned in an API method called DoReferenceTransaction, although it’s use is restricted to users who have been a) using the processor for at least 1 year and b) who have been rigorously verified.

    0
  16. 29

    Definitely very good article, working on an e-commerce website at the moment and this will definitely come in handy :) Thank you for sharing.

    0
  17. 30

    Hi,

    Does anyone knowhow of à cc validation ms or php script. I like to use cc as extra guarantee info, not planning to cash money, yet.

    I just want to filter out the dummy cc numbers and check if the cc is valid with selected card type.

    0
    • 31

      Hi Alex,

      There’s a fairly simple (sic.) method for calculating this:
      Working from right-to-left
      1. Starting with the 2nd last digit in the credit card number, double every 2nd number.
      2. Add all these digits together, along with all the ODD numbers (The ones you didn’t double) together.

      The result should be mod10.
      If you have a remainder, the card number is invalid.

      Example:
      If the credit card number is: 4435346124683347 (random)
      The result of doubling would be: 8,6,6,12,4,12,6,8
      This should give you: (8),4,(6),5,(6),4,(1+2),1,(4),4,(1+2),8,(6),3,(8),7 = 80
      This would be valid as 80 mod(10) = 0

      You should also check the length and starting digit(s) to validate the number pertains to the correct card type.

      MASTERCARD
      Starts with: 51-55
      Length: 16

      VISA
      Starts with: 4
      Length: 13 or 16

      There’s a lot more out there, but this should give you a good point to start from.

      Dave

      0
  18. 32

    Authorize.net has a great system (CIM) that allows your website’s users to store their credit card info on Authorize.net’s highly secure PCI-compliant systems, so you can allow them to checkout multiple times without re-entering their data, yet your system and database never have access to the sensitive info. greatly simplifies things and reduces the expense of creating and maintaining all of those security layers. We love it at our shop!

    0
  19. 33

    You should never, EVER store credit card data unless you *absolutely* have to. PCI compliance does not make your customers’ data safe. The much better option is to have nothing to steal by not storing it at all. Lots of payment gateways will allow you to hook into their API so that you pass the payment information to them, they reply back with a yes/no response based on whether or not the transaction went through, and you never have to store a customer’s credit card information. It’s foolish, it’s dangerous and you’re just asking for trouble.

    4
  20. 34

    I never store CC info – just removes a whole potential area of risk.

    SagePay in the UK regularly suffer downtime, other UK alternatives are EWAY or Worldpay

    0
    • 35

      I’ve found SecureTrading to be the best UK based processor by far, 100% guaranteed uptime. Left sagepay for them and never looked back =]

      0
  21. 36

    Paypal can freeze your account for 180 days, reroll transactions if customers have ANY complaint, etc. etc.

    Google for “Paypal sucks”.

    3
    • 37

      to funnybunny.. yes.. about paypal.. i too have this experience, so i do not understand why everybody are so happy about paypal.. do they ever study the possible situations before take this risk ?

      1
  22. 38

    thanks for this nice article ..
    but i just want to mention that most of those ( worldwide ) providers does not support or deal with Syrian customers.
    for example 2co block any transactions from / to Syria.
    and there is also another good gateway provider which i personally deal with which is missing from the list : moneybookers.com which is really a worldwide service provider.

    thanks

    1
  23. 39

    PCI Compliance is only going to get bigger and Developers need’s to be responsible for their clients.

    The 2 mains PCI compliance are SAQ A & SAQ C. In very basic terms. If you use a service like paypal where you DO NOT TOUCH any credit card details you only need to be SAQ A. If you use a merchant account like authorize.net where by a customer enters any credit card data into your form’s you will need to be SAQ C. Achieving SAQ C is big for small firms ie logging, documentation, server scans etc…

    So the best way to forward for small business use a service like paypal OR if your merchant account allows you to embed an iFrame. This way you do not touch the credit card details.

    Hope this helps.

    1
  24. 40

    I do not understand the happiness about the PayPal integration. For myself ( i am experienced php oop developer) it is real pain to integrate paypal into a web project. The german docs are very confusing and there is quite too much information at the same time. There is no “Step by Step” Tutorial, no explanatory notes about the differnent Payment Methods etc. So, i hate PayPal, its very frustrating.

    1
  25. 41

    Full Disclosure: I’m a cofounder of Spreedly.

    I’m very happy to see the conversation around PCI compliance here. It’s a tricky topic and one that is often thought of way too late when considering accepting credit card payments.

    Spreedly has a new product in private beta called Core. Core eliminates a merchant’s need to store, process or transmit card data. The upside of this is that it removes the bulk of scope for PCI compliance and qualifies merchants for SAQ A. The real nice part about our approach is that you retain control of the presentation (no hosted payment pages) and have a broad choice of payment gateways. You can even work with multiple gateways if your needs require it.

    If this is relevant to your needs/interests, please visit https://spreedlycore.com/ to learn more.

    3
  26. 42

    Currently for my own projects I am using another PSP => http://www.e-ls.com (ELS International)

    They have all PCI DSS requirements complied, as well as they offer to work only with one agreement (and without IMA.. like paypal or google), not like others (3-way agreements, so you need to speak with bank etc.. that would be a much longer paper process).

    They offer as well as iframe support, and also the “Reverse Proxy” what completely hides their solution under your own domain and with your custom design. So even in status bar (like it is with iframe) there always will be only your domain.
    And they also provide some automatic fraud protection and detection tools.
    And the very best – they offer the recurring payment options (called also like credit card subscription or rebill), so you can make any logic on your own imagination.

    One other thing that they now works only with VISA and MasterCard, so there is no Cirrus or Amex at the current moment, but .. i hope it will change.

    0
  27. 43

    There’s one extremely important note that was left out: Always be careful with policies regarding digital deliverables, aka “intangible” items (especially on Google Checkout & PayPal). Many people don’t know that they most companies have zero protection against intangible fraud.

    1
  28. 44

    Great article. I have been looking for a list of payment methods. E-commerce can be tricky when it comes to choosing payment processing or gateways to implement.

    0
  29. 45

    I’m stunned that nobody has mentioned Amazon Payments https://payments.amazon.com

    They have an ‘easy button approach’, but they also have a very rich API exposed as well.

    0
  30. 46

    Some PCI information I have learned:

    PCI Compliance is not mandated by law. It is not “illegal” to accept credit cards without being PCI compliant. Also, the credit card companies do not enforce PCI compliance on merchants, instead, it is up to the merchant’s bank to enforce compliance. Also, even if credit card data never enters your system, if you are handling it or transmitting it, you must be PCI compliant or face possible hefty fines (again no direct legal ramifications). However, if you never store credit card data, on harddrives, in RAM (some session data may be temporarily stored in ram), in a database, etc. Then your PCI requirements are drastically lowered to a quarterly self-assessment questionnaire (assuming fewer than so many transactions). PCI compliance does not apply only to software, but to a business as a whole and includes securing things such as your network, databases (database server cannot be directly accessible from WAN), applications, and having in place secure procedures such as restricting physical access to card data and logging all access.

    1
  31. 47

    wow, didn’t know about the whole PCI thing. thanks for pointing that out. What shopping cart/agteway would you guys recommend for using on a WordPress corporate website. We are looking at adding monthly subscription services to our regular marketing offering. Therefore the gateway needs to support recurring billing.
    Any thoughts?
    Thanks in advance.
    Luke

    0
    • 48

      I have used Braintree Payment Solutions in the past for a gateway and I like them. They have a library for all the popular languages and its very easy to integrate. They also are offering to get you PCI compliant for free. As for a cart for wordpress, I’m of the opinion that wordpress is a blog not an ecommere engine so you should try using something that is meant to be ecommerce such as Magento or Open Cart. Magento is somewhat geared more toward developers and too slow to run on anything but a dedicated server if you have over 3000 products, but it is VERY flexible and customizable. They also offer a paid solution that is PCI compliant and there are tons of extensions already made, many of which are free. Magento is open source and there is a free community edition.

      0
  32. 49

    You’ve missed AlertPay, which is a nice addition if you have clients in Asia. They seem to trust AlertPay more than PayPal.

    1
  33. 50

    Disclosure: I’m a designer at Jotform.

    Great in-depth article but i think it would be better if you mentioned 3rd party applications that uses these gateways as well. Many form builders utilize integrations that offer an easier setup for receiving payments/donations including the front-end code. Of course, it wouldn’t be wise to run an eCommerce site solely relying on these services, but they get the job done for most small businesses and charity organizations.

    We also provide such services here at Jotform. You can visit our website at http://www.jotform.com if you’re interested.

    0
  34. 51

    Great article. I will definitely help me to choose the right payment gateway.

    0
  35. 53

    Thanks for the article. And I have chosen master card and visa for my payment. It gives me the pleasure of good international communication.

    0
  36. 54

    You also missed Shift4.COM, who can handle debit cards and has a gift card program. For websites you can use their i4Go product that can insure that credit card info is never present in your system, which goes a long way towards providing PCI compliance.

    -1
  37. 55

    That you very much for this, Cards over the internet can be confusing enough to never make that first step. *Steps Cautiously*

    0
  38. 56

    What about moneybookers ? It is also a viable option

    0
  39. 57

    Thanks for this post Leigh, but I have a quick question… Maybe I missed it I’m not sure, but which of these providers is good for people with “bad or poor credit?” I have heard of 2checkout and Google checkout and PayPal but they all do credit checks when you choose merchant accounts – at least that’s what I was told, was I misinformed?

    Regards, and a well written article again Leigh,

    Jeremiah

    0
  40. 58

    There are also smaller payment providers, such as PayLane http://paylane.com/, who is more flexible to merchant needs.

    0
  41. 59

    Don’t forget to think about fraud protection. Online consumers don’t show ID or provide a signature like they do when they use their credit cards offline, so you need to protect yourself.

    For example SafeCharge…(yes, I work there) is highly secure and Level 1 PCI-DSS compliant, and offers an advanced risk platform.

    1
  42. 60

    rongdhonugraphics

    May 11, 2011 2:11 am

    Thanks for sharing an excellent post…

    0
  43. 61

    Also, if you are looking for a credit card processor to easily tie into your invoicing solution, try Blinksale / Blinkpay. blinksale.com/blinkpay.

    Come give it a shot. I am happy to help you get started! patrick at blinksale dot com

    0
  44. 62

    I have a mastercard. And I feel much freedom with it for international payment. There are many ways and I told it before that they have many restriction. So its upon you.

    0
  45. 63

    I’m using mastercard and found no problem in any area of the world. It is the best way for worldwide payment and receive. All the method have restriction and facilities too.

    0
  46. 64

    There are growing number of “providers” who allow to accept credit card payments. Some, like Square even uses iPnone as a card reader etc. As for me, I’m using Alertpay to deal with card payments.

    0
  47. 65

    PCI compliance is a must for anyone reading this article and thinking of taking card payments online. This is no joke – we got a 10k fine for not being PCI compliant by VISA (site obviously got hacked). There are some cheap solutions offered by the major banks. If it costs a few extra $/£ per month, just do it…… PCI compliance will be mandatory in the future.

    0
  48. 66

    Thanks for the helpful info, I was wondering if anyone could point me in the right direction with some research I am conducting for a software company investigating which PSP to use.
    – What I am trying to find out is a list of the acquiring banks connected to each PSP (e.g. Wirecard, Datacash, Sagepay etc.). Some PSPs have this information available on their website however some such as Wirecard merely state 100+ acquiring banks connected without actually providing a list of which. I have tried going directly to the PSPs but they are not always forthcoming with the info.
    – My reason for wanting to know the specifics of the acquiring banks is that I am inputting them into a database, once I know the acquiring bank I then find out which card types that bank accepts (e.g. Visa, JCB, Maestro) and then which currencies are available for merchant services (e.g. which they can accept and which they can settle in)

    If anyone has any advice on how I might acquire this info I would be most greatful.

    0
  49. 67

    The master card is a freedom. I am using payoneer mastercard for my all online payments dealings. The most interesting thins is I just load my cart and go to ATMs and simply get my money. :) This is the main fun of online banking or using mastercards or such online payment methods. Thanks for the post.

    0
  50. 68

    I am using mastercard provided bu Payoneer Inc. Its really awesome. Just feel like a bird to withdraw my money. Almost all of the banks support master card. i just punch the card in and take a look of my account summary and withdraw it. Its really awesome in every look.

    -3
  51. 69

    Another way to avoid the storage of sensitive PAN info is to use tokenization – it eliminates encryption by replacing the credit card info completely. You can read more about it here: http://resource.onlinetech.com/simplifying-pci-compliance-with-tokenization/

    0
  52. 70

    PCI compliance is equally as important as everything listed here – without it you face very high fines accured daily. Get with a processing company that dots all of the i’s for you and crosses all of the t’s to make sure your online finances are secure, protected and in compliance. otherwise, an informative article.

    0
  53. 71

    The ‘Web apps, credit cards, merchant accounts and PayPal’ link is dead.

    0

↑ Back to top