As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Should be available to non-U.S. companies, easy to setup, reliable, cheap, customizable, etc. What are your experiences?
You can't really answer this kind of question with a "I like 'insert provide name here'" type answer because like so many things it is a balance and the reasons for choosing a payment processing solution tend to be complex.
Volume / Value
The most important factor in choosing a secure payment clearance service (the people who will connect to the banking networks and clear the money for you - will refer to them as SPCS) is how many widgets will you be selling at what cost. The pricing models of all the SCPS providers is based around this equation. This dictates the economics of using the service, which is nearly always the most important factor.
For example, in the UK securetrading.net have a large annual fee and high minimum transaction values (been a while since I've seen the exact numbers and they don't make it immediately obvious on the site, but this is for illustration only anyway) making it one of the most expensive solutions to use if you are selling high value low volume. Most smaller clients will fall into this model. High value is really anything over a couple of dollars. Low volume is typically anything less than tens of thousands of units per month. However, if you are running a donations service in the aftermath of an international environmental disaster (relatively low value very high volume) then they become one of the cheapest.
Factor in to this the setup costs (relatively high), and the cost to tie the service into the site (in SecureTrading's case it's very easy to do, but still a lot harder than adding a PayPal button) and you start to build up a true picture.
On the flip side, a service such as PayPal has very low setup costs (no fee to pay, and trivially easy to integrate), but relatively high transaction costs. It is great for high value / low volume transactions.
The Bank
There are two main categories of payment clearance service - Bureau and Bank Acquired.
In the UK at least NetBanx, SecureTrading and WorldPay offer both bank acquired and bureau services. ProtX and SecPay offer only bank acquired services. PayPal and its ilk operates slightly outside both definitions (see Protection below).
A Bank Acquired service plumbs into your normal banking merchant account and clears the funds straight into it. As well as charging you for this service, your bank will also take a slice, typically this is more than the SPCS provider will charge and so it actually is the bank that becomes the deciding factor.
Some banks will only work with their preferred provider. In the UK, most banks want you to have a separate Internet Merchant Account even if you already have a Merchant Account with them.
I always tell clients to shop around, as this will make a huge difference to how much their e-commerce venture can bring in. All banks are not created equal.
Bureau services effectively act as your bank at the same time as providing the clearance service. They were popular in a time when banks hadn't grasped the concept of the Internet and would prefer transactions be chiseled into stone tablets if they got their way. Often the choice between a bureau service and a bank acquired service is made for you based on circumstances.
Trading History
In many countries (including the UK), most banks won't give you a merchant account until you have been trading for a particular period of time (2 years in the UK). Your only option is then a bureau service.
Cash flow
Most bureau services will hold onto your cash as security against "charge backs".
If you sell me a Ferrari and I am horrified to learn that you've sold me a small metal toy rather than the 1.5 tonnes of Italian automotive passion I was expecting, I will complain to my credit card company who will refund me and then chase your merchant services provider for a refund. They will have to give them the refund and then chase you for the money.
It's therefore in their interests to hold on to your money for a period of 4-6 weeks to protect against this. If you sell services or goods with no capital outlay (software for instance), then you can afford this. If on the other hand, you really are having to pay your luxury car importer to provide you with stock, then cash flow becomes very important and you're going to need a bank acquired service where you can be paid immediately.
Protection
One major downside to PayPal and similar services is that it is not covered under the same regulations that govern credit cards.
Simply put, if you buy something on a credit card your card provider is liable for ensure you get what you paid for (broadly speaking, in most countries, does not constitute legal advice etc.) and if you have a problem with your purchase they will refund you very quickly and then will go and chase the person that you paid.
This is the kind of protection you hear about when Leo Laporte advertises American Express on his podcasts. It is a "Good Thing"TM. You don't have that protection with PayPal because when you use your credit card on PayPal, you are actually buying PayPal's service. So, even if you are mis-sold a product, the person you paid for the service (PayPal) didn't mis-sell, they provided the service you paid for. This breaks the chain.
PayPal don't have a legal obligation to protect you in the same way, and their record on refunding ripped off customers is less than spangly. I'm guessing they have "Caveat Emptor" writ large on the walls of their head office. :)
I'm not dissing PayPal, they are way ahead of the curve on many other security features, but just another factor to bear in mind.
End to end integration
Different services differ in their ease of integration. Oh boy do they differ. I'm sitting on some work right now to do an HSBC integration. I'd rather have a root canal. Some of the systems make big assumptions about the way you have to work with them, and are poorly designed or inflexible. Retro-fitting them to an active site can be very painful. Some of them are beautiful and easy to work with (and not necessarily less secure). The biggest difference is how you choose to integrate though.
Most services integrate by allowing you to redirect to a secure site where your customer fills in his / her details. They are finally redirected back to a page on your own site with the results of the transaction. This works well in most cases and is easiest to integrate.
When you buy something on Amazon, you don't get redirected to WorldPay, or PayPal however. If you want end-to-end integration, most services now will let the communication happen behind the scenes. Your own site has to have a decent secure server certificate of course, and the integration is necessarily more complex.
Reputation
It used to be that PayPal was used on dinky sites. You wouldn't catch Amazon using it. That perception has changed a lot, and in fact in some senses PayPal does security better than most. If your audience expects to see PayPal and you give them some other service then you may lose custom, or vice versa. These days many merchants offer a choice to customers.
UK Providers
WorldPay. Well established. Bureau and bank acquired. Relatively high transaction costs and annual costs. Fairly easy to integrate. Owned ultimately by Royal Bank of Scotland.
SecPay. Bank Acquired. Low per transaction cost and low annual cost and flexible payment models.
ProtX. Bank Acquired. Low per transaction cost and low annual cost, flexible payment models. Can be quite demanding to integrate.
HSBC. Bank Acquired. Low per transaction cost. High set up and annual costs. Very inflexible to integrate.
SecureTrading. Bureau and Bank Acquired. Low per transaction cost but high setup and annual costs. Was a doddle to integrate last time I used it (9 years ago!)
NetBanx. Bureau and Bank Acquired. Haven't used since 1996 so can't comment!
And of course PayPal, Google Checkout and Amazon FPS are well worth looking at and worth a whole answer on their own!
Summary
Told you it wasn't that simple! Usually, as developers, we're not in the position to choose for ourselves, and these decisions should be driven by the business needs of our employer / client.
Most e-commerce projects would start with PayPal or similar. When the business gets enough orders that they could save money by switching to another service, then they've got enough money to pay for the switch.
Disclaimer: I am UK based, and have performed many integrations with a whole slew of these services over the years, however the market changes all the time and things may have changed and your mileage may vary! I am not a lawyer or accountant, and if you take my advice it's not my fault :)
I'd say paypal or GoogleCheckout.
Google Checkout is either 2% + .20USD or free depending on how much you spend on adwords. If you spend a dollar on adWords, your next $10 on Google checkout is free.
Paypal is 1.9% to 2.9% + $0.30 USD (2.9% for up to $30,000/month, 1.9% for more than $100,000/month)
Without factoring in the 20/30 cents, Paypal is just barely cheaper if you sell more than $100,000 per month, and spend nothing on adwords.
http://www.authorize.net/ works well. This type of solution would allow your customer to enter his/her credit card directly.
I've been researching Google Checkout. If you require subscriptions (recurring payments) like I do - Google Checkout has it but it is still in beta. So depending on when you want to go live and your needs - you may want to use something else.
esellerate
if it is Digital stuff that you are selling, I recommend http://www.esellerate.net/ .
they have nice support for website payment, delivery of serial numbers upon sell and even have API so you can integrate the buying process into your application in case it is a desktop application.
Well by cheap do you mean processing fees or month fees? Also is this for micro or normal transactions? PayPal in my experience is an all around good choice because it offers both starter to professional level payment processing services that fit most needs.
I've looked at WorldPay and SecPay in the past; you need to know your onions to use them competently, I think - if you want really nice integration, at any rate.
Google Check-out isn't available to non-US companies. I didn't realize this until the last stages of my research, so I found it quite annoying (considering it was very easy to work with and very well documented).
Unfortunately in order to make things as convenient as possible for your end users, you're pretty much stuck with having to support Paypal. No one else comes close in terms of registered users.
I've used CyberSource in the past, and had a good experience.
They support several interfaces including SOAP, work internationally and have a pretty good web interface.
I'm not sure whether it's cheap though.
http://www.cybersource.com/products_and_services/global_payment_services/credit_card_processing/
Epoch is pretty large and available in US and EU:
http://www.epoch.com/en/index.html
I have no idea about their conditions though.
I'd have to go with paypal. I've used it in the past, and its really quite painless. All you need to do is create an account, and it's automatically available to you.
Try AlertPay, they have very competetive fees.
alertpay looks great low fees (compared with paypal), supports more countries , developers center
Related
what are the best security features (settings,modules) provided by drupal according to credit card transaction?. Do you have any additional prevention techniques .If possible post important and necessary setting points also please.
Most importantly, don't handle the CC data at all. There are several payment processors which provide a payment API and handle the CC processing for you. That way, you don't need to worry about PCI DSS or about escaped CC#s (and the resulting PR brouhaha) when your database is compromised.
(it may seem I'm dodging the question here, but every time we've done a calculation of costs in process cards ourselves/have a processor do it, the roll-your-own approach would bring high initial costs and considerably higher maintenance costs, plus higher risks. OTOH, payment processor will cost you something, but takes this risk+PCI DSS off you)
If you want to handle credit cards transactions with drupal or any other technology you need to comply to the Payment Card Industry Data Security Standard (PCI DSS).
I agree with Piskvor. If you're not 100% sure what you're doing, I think you're better off using existing code that has been tried and tested by the community. Have a look at Pay module.
I'm working on a project where we collect payments from users using credit/debit/PayPal payments.
The service is taking payments from users on behalf of a 3rd party organisation.
Once we take the payment, minus fees, we want to transfer the amount to the organisations bank account.
For now, what we can do is pay the organisation using Online Banking BACS bank transfer.
But I would like to know if there is a way to do this automatically using an API.
If we need to somehow register the 3rd parties bank account details before making transfers, this is fine.
We just want to automate the whole process, since at the moment the transfer is a manual step.
Are there any gateways or APIs I can use for this? In the UK?
As this is still un-answered I'll throw my hat into the ring.
For the benefit of non-UK users, the UK has a central clearing system called Bacs, which is run by the major banks in the country. However, companies can also makes submissions directly to that clearing system, by using Bacs Software.
There are a number of companies that sell on-premise and online services/APIs that allow you to send money directly via Bacs (and collect Direct Debits).
DISCLAIMER: I currently work for a software company (Bottomline Technologies) which sells a Bacs API - I won't mention the product name and to see alternative companies you can simply Google for 'bacs software api'
Hope this helps
You are going in the wrong direction. You should talk to payment processors (which may or may not include your bank) about the business considerations, which probably are more important than the technological considerations. Generally you can expect something somewhat reasonable that you will (after fiddling with it enough) be able to convince to work. It doesn't matter whether this involves some sort of api library, soap calls, or other communication method.
If you honestly consider having the technological considerations more important than the business considerations, then just go with Paypal and don't write your own shopping cart stuff at all. This is easier to use and will do more of the heavy lifting for you, but which will also probably charge you more.
Once you create a real shopping cart and start handling payments yourself (i.e. taking in CC information and sending it to a payment processor), you start getting into a mess of legal and technical concerns involving PCI compliance and the like, which will apply regardless of your choice of payment processor*.
*This is US-specific, but I bet the UK has something similar.
It would be very useful to have feedback on the various API and services that let you bill the customers, so it's possible to compare :
Security;
Quality of API;
Commercial reliability;
Number of languages that can use it;
General usage of them;
Ease of set up;
Economic price;
Technical price.
I thinking here of course of PayPal, Google Checkout but bank credit card based systems as well.
Braintree (and to some extent, other lesser payment gateways)
Pros
You're in complete control of the billing system
You can do more complex payment setups
Widely supported for multiple programming languages; ActiveMerchant support
Some of the best support you'll ever see for e-commerce
Cons
You probably have to deal with PCI DSS security compliance
Potentially a lot of extra work (which may very well still be worth it)
Google Checkout
Transaction Fee: 2.9% + $0.30
Pros
Very low transaction processing fees
Fantastic if you're already using Google for advertising
Google handles a lot of the messy stuff involved in billing, like chargebacks
There's now support for subscriptions (in beta though)
Cons
Google's API is different enough from other systems that you usually have to use a library specifically designed for Checkout (e.g., no ActiveMerchant support)
Paypal
Transaction Fee: 2.9% + $0.30
Pros
Widely understood API; tons of stuff available for dealing with it
Essentially supported by everything
Cons
Lots of people are very vocal about not wanting to do business through PayPal due to bad experiences
Neutral
Tends to be popular with the young adult demographic who don't have credit cards and with eBay users
Amazon FPS
Transaction Fee: 2.9% + $0.30, lower for bank accounts and balance transfers
Pros
Probably your best bet for micro-transactions
A good choice for payments for physical goods
Cons
I don't know enough about the system to say for sure
If you want to accept credit/debit card payments online, you're going to need two things:
an Internet Merchant Account (a business bank account which can accept such payments; there's usually quite a bit of business compliance, risk and anti-fraud attached, but if you're a serious business with an existing business account, talk to your bank)
a Payment Services Provider (who provide you with, for example, an API or a hosted checkout solution, and who act as the go-between for your web site and your IMA, which will typically only provide very limited options)
There is, of course, a fast growing trend of alternative payment services; PayPal, Envoy, MoneyBookers, Neteller, uKash, etc. Those are definitely worth exploring, because they tend to provide a certain degree of risk-free/guaranteed payment, and they dramatically widen the numbers of customers you can reach - think in terms of people who aren't old enough to have cards, or who aren't able to get them due to debt problems or the like.
Perhaps the easiest combination is to find a Payment Services Provider who can handle the whole lot - set you up with an IMA (or rather, underwrite your risk with a bank so they'll be happier to give you one), provide payment processing services, maybe a bit of fraud protection and risk management on top, chargeback management, and then handle all those possible payment methods, including things like 3D Secure (Verified by Visa/Mastercard SecureCode) which can be a real headache to integrate with.
If you're going to be getting into the business of handling online payments, even if it's just an occasional thing, then you'll need to knuckle down and do a bit of serious research into what you need, what you don't need, and what you're willing to pay, 'cause payment service providers obviously charge for this stuff, and it'll be a serious business partnership.
For once, Wikipedia seems to have an appallingly lightweight list, so you may want to Google "payment services provider".
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This question has been asked before (link) but I have slightly different requirements. First, I'm in Canada so that rules out Google Checkout and probably a few others. I just need a basic service that provides "Buy Now" functionality, no shopping carts or anything like that. The site isn't super high volume, so I'd like to avoid any site with crazy monthly fees. I also need the ability to setup "discount codes" (or whatever you want to call them) for special promotions. The site must also have some sort of payment notification service (IPN). I am currently using PayPal, but their lack of discount codes is really starting to restrict what I can do.
What have you used, or what would you recommend I investigate further?
I have used Beanstream in Canada. They provide a hosted service, where you provide a link to a custom Beanstream page in your site; they do all the payment processing and deposit the funds in your bank account. You can edit the checkout page to make it match your site, and create shopping carts or provide charges on a case-by-case basis. I know you said you don't need a shopping cart, but it is only $10/month more.
They also provide a gateway API if you want to accept credit cards yourself, but I find the hosted service far more convenient.
I've had good luck with eMetrix. Also I've heard good things about Plimus too.
Has anyone had any experience with eSellerate?
Plimus looks good, although I've heard some horror stories from the customers point of view related to their phone verification.
On TeamMentor we use Payflow Pro and have had a good experience with it. The SDK is straightforward and easy to use especially if all you need is a quick "buy now" option. They support international processing, although no paypal processing outside of the US.
I saw the usage of Moneris at a client site.
I have used the Payflow Pro and the Paypal Payments Pro. I found them easy to use from an API standpoint, although Payflow's php API worked well, it required a recompile of php and that meant less ease for patching our servers. After the server setup each was equally okay. The biggest drawback to using the Paypal products was the customer support and set up. Setup was a nightmare and the "salesman"/account rep that we dealt with was less than helpful.
Maybe You should add some details about Your requirements:
If sufficient, try bank transfers. They are not known or free in all countries and I do not know about Canada, but it is the best payment system in Europe: You just tell Your bank to transfer the money to the destination account.
Advantages:
Cannot be undone.
The customer has a proof of the payment.
Free of charge (most banks in Europe)
Disadvantage:
Cannot be undone ;)
The customer has to order his/her bank to transfer the money.
It takes up to three days before the money appears in Your account.
Do You need "instant" payment?
International payments?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This question talks about different payment processors and what they cost, but I'm looking for the answer to what do I need to do if I want to accept credit card payments?
Assume I need to store credit card numbers for customers, so that the obvious solution of relying on the credit card processor to do the heavy lifting is not available.
PCI Data Security, which is apparently the standard for storing credit card info, has a bunch of general requirements, but how does one implement them?
And what about the vendors, like Visa, who have their own best practices?
Do I need to have keyfob access to the machine? What about physically protecting it from hackers in the building? Or even what if someone got their hands on the backup files with the sql server data files on it?
What about backups? Are there other physical copies of that data around?
Tip: If you get a merchant account, you should negotiate that they charge you "interchange-plus" instead of tiered pricing. With tiered pricing, they will charge you different rates based on what type of Visa/MC is used -- ie. they charge you more for cards with big rewards attached to them. Interchange plus billing means you only pay the processor what Visa/MC charges them, plus a flat fee. (Amex and Discover charge their own rates directly to merchants, so this doesn't apply to those cards. You'll find Amex rates to be in the 3% range and Discover could be as low as 1%. Visa/MC is in the 2% range). This service is supposed to do the negotiation for you (I haven't used it, this is not an ad, and I'm not affiliated with the website, but this service is greatly needed.)
This blog post gives a complete rundown of handling credit cards (specifically for the UK).
Perhaps I phrased the question wrong, but I'm looking for tips like these:
Use SecurID or eToken to add an additional password layer to the physical box.
Make sure the box is in a room with a physical lock or keycode combination.
I went through this process not to long ago with a company I worked for and I plan on going through it again soon with my own business. If you have some network technical knowledge, it really isn't that bad. Otherwise you will be better off using Paypal or another type of service.
The process starts by getting a merchant account setup and tied to your bank account. You may want to check with your bank, because a lot of major banks provide merchant services. You may be able to get deals, because you are already a customer of theirs, but if not, then you can shop around. If you plan on accepting Discover or American Express, those will be separate, because they provide the merchant services for their cards, no getting around this. There are other special cases also. This is an application process, be prepared.
Next you will want to purchase an SSL certificate that you can use for securing your communications for when the credit card info is transmitted over public networks. There are plenty of vendors, but my rule of thumb is to pick one that is a brand name in a way. The better they are known, the better your customer has probably heard of them.
Next you will want to find a payment gateway to use with your site. Although this can be optional depending on how big you are, but majority of the time it won't be. You will need one. The payment gateway vendors provide a way to talk to the Internet Gateway API that you will communicate with. Most vendors provide HTTP or TCP/IP communication with their API. They will process the credit card information on your behalf. Two vendors are Authorize.Net and PayFlow Pro. The link I provide below has some more information on other vendors.
Now what? For starters there are guidelines on what your application has to adhere to for transmitting the transactions. During the process of getting everything setup, someone will look at your site or application and make sure you are adhering to the guidelines, like using SSL and that you have terms of use and policy documentation on what the information the user is giving you is used for. Don't steal this from another site. Come up with your own, hire a lawyer if you need to. Most of these things fall under the PCI Data Security link Michael provided in his question.
If you plan on storing the credit card numbers, then you better be prepared to put some security measures in place internally to protect the info. Make sure the server the information is stored on is only accessible to members who need to have access. Like any good security, you do things in layers. The more layers you put in place the better. If you want you can use key fob type security, like SecureID or eToken to protect the room the server is in. If you can't afford the key fob route, then use the two key method. Allow a person who has access to the room to sign out a key, which goes along with a key they already carry. They will need both keys to access the room. Next you protect the communication to the server with policies. My policy is that the only thing communicating to it over the network is the application and that information is encrypted. The server should not be accessible in any other form. For backups, I use truecrypt to encrypt the volumes the backups will be saved to. Anytime the data is removed or stored somewhere else, then again you use truecrypt to encrypt the volume the data is on. Basically where ever the data is, it needs to be encrypted. Make sure all processes for getting at the data carries auditing trails. use logs for access to the server room, use cameras if you can, etc... Another measure is to encrypt the credit card information in the database. This makes sure that the data can only be viewed in your application where you can enforce who sees the information.
I use pfsense for my firewall. I run it off a compact flash card and have two servers setup. One is for fail over for redundancy.
I found this blog post by Rick Strahl which helped tremendously to understand doing e-commerce and what it takes to accept credit cards through a web application.
Well, this turned out to be a long answer. I hope these tips help.
Ask yourself the following question: why do you want to store credit card numbers in the first place? Chances are that you don't. In fact, if you do store them and manage to have one stolen, you could be looking at some serious liability.
I've written an app that does store credit card numbers (since the transactions were processed offline). Here's a good way to do it:
Get an SSL certificate!
Create a form to get CC# from the user.
Encrypt part (not all!) of the CC# and store it in your database. (I'd suggest the middle 8 digits.) Use a strong encryption method and a secret key.
Mail the remainder of the CC# to whoever processes your transactions (probably yourself) with the ID of the person to process.
When you log in later, you will type in the ID and the mailed-out portion of the CC#. Your system can decrypt the other portion and recombine to get the full number so you can process the transaction.
Finally, delete the online record. My paranoid solution was to overwrite the record with random data before deletion, to remove the possibility of an undelete.
This sounds like a lot of work, but by never recording a complete CC# anywhere, you make it extremely hard for a hacker to find anything of value on your webserver. Trust me, it's worth the peace of mind.
The PCI 1.2 document just came out. It gives a process for how to implement PCI compliance along with the requirements. You can find the full doc here:
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
Long story short, create a separate network segment for whichever servers will be dedicated to storing CC info (usually DB server(s)). Isolate the data as much as possible, and ensure only the minimum access necessary to access the data is present. Encrypt it when you store it. Never store PAN's. Purge old data and rotate your encryption keys.
Example Don'ts :
Don't let the same account that can lookup general info in the database look up CC info.
Don't keep your CC database on the same physical server as your web server.
Don't allow external (Internet) traffic into your CC database network segment.
Example Dos:
Use a separate Database account to query CC info.
Disallow all but required traffic to CC database server via firewall/access-lists
Restrict access to CC server to a limited set of authorized users.
I'd like to add a non-technical comment that you may wish to think about
Several of my clients run e-commerce sites, including a couple who have moderately large stores. Both of those, whilst they certainly could implement a payment gateway choose not too, they take the cc number, store it temporarily encrypted online and process it manually.
They do this because of the high incidence of fraud and manual processing allows them to take additional checks before filling an order. I'm told that they reject a little over 20% of all their transactions - processing manually certainly takes extra time and in one case they have an employee who does nothing but process transactions, but the cost of paying his salary is apparently less than their exposure if they just passed cc numbers though an online gateway.
Both of these clients are delivering physical goods with resale value, so are particularly exposed and for items like software where a fraudulent sale wouldn't result in any actual loss your mileage would vary, but it's worth considering above the technical aspects of an online gateway if implementing such is really what you want.
EDIT: And since creating this answer I'd like to add a cautionary tale and say that the time is past when this was a good idea.
Why? Because I know of another contact who was taking a similar approach. The card details were stored encrypted, the website was accessed by SSL, and the numbers were deleted immediately after processing. Secure you think?
No - one machine on their network got infected by a key logging Trojan. As a result they were identified as being the source for several score credit card forgeries - and were consequently hit by a large fine.
As a result of this I now never advise anyone to handle credit cards themselves. Payment gateways have since become much more competitive and cost effective, and fraud measures have improved. The risk is now no longer worth it.
I could delete this answer, but I think best to leave up edited as a cautionary tale.
Keep in mind that using SSL to send a card number from a browser to a server is like covering your credit card number with your thumb when you hand your card to a cashier in a restaurant: your thumb (SSL) prevents other customers in the restaurant (the Net) from seeing the card, but once the card is in the hands of the cashier (a web server) the card is no longer protected by the SSL exchange, and the cashier could be doing anything with that card. Access to a saved card number can only be stopped by the security on the web server. Ie, most card thefts on the net aren't done during transmission, they're done by breaking through poor server security and stealing databases.
Why bother with PCI compliance?? At best you'll shave a fraction of a percent off your processing fees. This is one of those cases where you gotta be sure this is what you want to be doing with your time both upfront in development and over time in keeping up with the latest requirements.
In our case, it made the most sense to use a subscription-savy gateway and pair that with a merchant account. The subscription-savy gateway allows you to skip all the PCI compliance and do nothing more than process the transaction proper.
We use TrustCommerce as our gateway and are happy with their service/pricing. They have code for a bunch of languages that makes integration pretty easy.
Be sure to get a handle on the extra work and budget required for PCI. PCI may require huge external audit fees and internal effort/support. Also be aware of the fines/penalties that can be unilaterally levied on you, often hugely disproportionate to the scale of the 'ofense'.
There's a lot to the whole process. The single easiest way to do it is to use services similar to paypal, so that you never actually handle any credit card data. Apart from that, there's a quite a bit of stuff to go through to get approved to offer credit card services on your website. You should probably talk with your bank, and the people who issue your merchant ID to help you in setting up the process.
As others have mentioned the easiest way into this area is with the use of Paypal, Google checkout or Nochex. However if you intend to to a significant amount of business you may wish to look up "upgrading" to higher level site integrations services such as WorldPay, NetBanx (UK) or Neteller (US). All of these services are reasonably easy to set up. And I know that Netbanx offers convenient integration into some of the off the shelf shopping cart solutions such as Intershop (because I wrote some of them). Beyond that you are looking at direct integration with the banking systems (and their APAX systems) but thats hard and at that point you also need to prove to the Credit card companies that you are handling the credit card numbers securely (probably not worth considering if you are not taking $100k's worth per month).
Working from 1st to last the cost/benefits are that the early options are much easier (quicker/cheaper) to set up put you pay quite high handling charges for each transaction. the later ones are much more costly to set up but you pay less in the long run.
The other advantage of the most of the non dedicated solutions is that you don't need to keep encrypted credit card numbers secure. Thats someone else's problem :-)