If I understand correctly, companies like McDonalds and Apple have or will deploy large numbers of iBeacon BLE devices at their stores, each presumably having a unique UUID so that triangulation is possible within the store. Is there now, or will there be, a central place where UUIDs for various stores are going to be made available for bulk download for people who want to use them in apps?
Actually, the range of UUIDs for a given organisation will be quite small - 1 or maybe 2. It is the 16 bit minor and major values that are associated with a given UUID that identify a location.
An app can register its interest in a limited number of UUIDs (the total number of UUIDs that can be registered across all apps is also limited, so it is best for an organisation to use as few UUIDs as possible)
Once it has registered interest in a UUID, the app will be notified when the device comes into range of one. The app can then display an alert to the user prompting them to enter the app. If they do, then the app can retrieve the major and minor numbers from the beacon. The app can cross reference this information against a database, possibly via a web service, to determine its location. For example Major=12 might mean Sydney Apple store, minor=4 might mean the Genius bar.
If the device is in range of several iBeacons then it can use signal strength to estimate a range and therefore a location, but it isn't really triangulation in the true sense.
As to whether companies will release details of there UUIDs, major and minor values is unknown and will certainly vary from organisation to organisation - the data is being transmitted in the open so it is possible that 3rd parties may gather this information and make it available.
Locate for iBeacon (iOS) and iBeacon Locate (Android) can optionally collect iBeacon data and upload it to WikiBeacon.org, a public directory of iBeacon Locations. Data collection has been going on for a few months, but the directory has not yet been launched. I will update this answer when in is available.
If you know of the locations of iBeacons that you would like to be included in this directory, you can enable data collection in these apps, then use them to scan for them.
Data of this kind relies on reports from individual app users, so it is not comprehensive. Many organizations deploying iBeacons have no incentive to publish their locations because of the expense involved with deploying and maintaining them, so they probably will never reveal this info.
Full disclosure: I am Chief Engineer for Radius Networks.
The fact you don't know iBeacon identifiers (mainly UUID) for already deployed beacons can be indeed problematic. Basically, it does not allow you to leverage existing infrastructure for your applications and forces everyone to build their own infrastructure (= duplicate iBeacons), which is inefficient both financially and "morally".
We have started an effort called OpenUUID to help fix this issue:
OpenUUID
Basically, OpenUUID is a free to use registry of unique proximity UUIDs for your iBeacon applications.
Help us clean the iBeacon environment by using it to generate your proximity UUIDs and by spreading the word about this activity, so that McDonalds or Apple use the OpenUUID service for their iBeacon deployments... ;-)
Related
We are planing a new product with angular 5 and node.js . The product will run locally at the customer environment .
our problem is the following : how to protect our code from being stolen by any of the customers ? in dotnet i can seal all the source code into an encrypted dll or something like that . what can be done in angular 5 ?
Thank you .
our problem is the following : how to protect our code from being stolen by any of the customers ?
Stealing is illegal. The easiest solution would therefore be to not do business with criminals.
in dotnet i can seal all the source code into an encrypted dll or
something like that .
That doesn't work.
In order for your clients to run the code, your client's CPU needs to understand the code. CPUs are much, much dumber than humans, so if the CPU can understand the code, then a human can, too. If you encrypt the code, you need to decrypt it, otherwise the CPU won't understand it.
Since the launcher needs to be able to encrypt the code, the decryption key must be part of the launcher, IOW, the encryption key must be stored on the client's computer: ergo, the client has the encryption key. If you transmit the encryption key over the network, you still need to do that over the client's network: since the client owns the network, they can intercept any traffic and thus intercept the key. Even if you make all this safe: the decrypted code is still inside the RAM of the client's computer, a computer that the client has full administrative access to.
This is your main problem:
The product will run locally at the customer environment .
That just doesn't work. If you don't want your clients to have the code, then just don't give them the code. Host the code locally and only give the client remote access through a narrow, secure, well-defined interface. This is the "Google approach".
If there is really no other choice, you can give the client a computer that your code is installed on, and that the client has no access to. Note, however, that unless you fully control every single component of that system (CPU, RAM, motherboard, firmware, all busses and extension ports, the case, the network connections, etc.), it is generally still possible to get access somehow. This is the "game console approach".
what can be done in angular 5 ?
There are a couple of standard approaches to this problem. It depends on exactly why your clients are stealing your product.
If they feel that the quality doesn't justify the price, raise the quality or lower the price. Also, try to find out why they feel the quality doesn't justify the price. Maybe there is a problem with the documentation, and the clients don't even know how awesome your product really is?
If they just can't afford it, lower the price or enter a different market. (Also, take a big step back and ask your marketing department why the heck they are selling the product in a market at a price that the market cannot afford. A typical example are companies selling products to students at a price that is equivalent to several years living expenses.)
Offer services beyond just simply selling the application; your clients will then pay for those services.
Make the product so good that your clients want to reward you and don't even think about stealing. (And no, this is not wishful thinking; Audio Damage is a company that successfully does this: in a highly competitive market, where complex copy protection and licensing schemes, high prices and low quality, and rampant piracy are common, they successfully sell their products at a lower price and higher quality with zero copy protection, and a no-questions-asked 30-days cash back guarantee.)
The only thing you can do is to add an another uglify layer protection like strings encryption. Consider the risk where some browsers will not be able to read the uglified source code.
After the Sony PSN debacle, I am trying to find examples of secure hardware tethering to a network. There are two use cases in particular:
1- computer downloads a piece of software that then uniquely and securely labels it to a cloud service
2- a hardware manufacturer uniquely labels a hardware device that then negotiates membership on the network.
Given the fact that the hardware device might have to change (revoke or service enhancements) it feels like #2 becomes #1.
The broad outline is this:
- connect to the service via HTTPS to protect against man in the middle
- device generates a GUID and presents it via HTTPS to service
- service records GUID against account
- on success, service 'enables' device
But how do you protect the GUID so that it cannot be stolen?
I just wanted to comment here:
Sony's PSN issues started with horrible practices with regards to their QA environment.
First, they defaulted to trusting anything that was sent to those servers using their developers toolkit. The reason they did this was that the dev kit used to cost upwards of $10k US and therefore they thought anyone who paid that amount would be on the up and up. However, when they radically lowered the price things changed externally and they didn't account for it.
The second issue with PSN was that the security between QA and live was, well, weak at best and easily circumvented. My understanding is that you could send commands to live using QA credentials. Because QA credentials were used, all chargeable actions were approved without money changing hands and the actions were applied to live accounts. When several people told Sony about this they did nothing.
A third issue was a reliance on hardware based encryption keys. Even hardware encryption keys installed on the devices can be figured out.
Point is, Sony dug their own grave on it so I wouldn't use anything they did as a template for how to do things. Heck, a lot of their websites were open to SQL injection which in today's day and age should get you fired.
Another example here is the iPhone. Each iPhone has a unique identifier that installed apps can grab and send back across the network; similar to a serial number. Some apps use this ID to try and tie a particular device to a person. However, it's trivial to create ID's and broadcast them, so this hasn't worked out so well for the partners. Also Apple does not expose a way to ensure a given ID (UUID) is valid to app producers.
A third example is mobile phone carriers. They use a particular ID baked into your SIM card to identify your account in order to know who to bill when a call is made. This ID is verified whenever the phone checks in with the network. However, we're dealing with radio signals and any device that can broadcast a correct ID can gain access. Point is, honest people think that only AT&T approved devices can get on an AT&T network. Reality is, anything can but they are going to bill the owner of the particular ID...
That said, any software you have running on a remote device that is not under your direct control is likely to be hacked. The popularity of the device will increase the likelihood of it happening sooner rather than later.
Where do we go from here?
On a basic level you associate an ID with an account in your service. PSN, Apple and others have done this. When an ID is broadcast, you need to verify that it exists AND that it's tied to an active account. If both pass then you have two options: either perform the action requested OR request additional verification.
For any actions that require money to be spent, do the additional verification (usually some form of username/password), capture the funds, then perform the action. Go one step further and every time a bad login is entered, send an email to the user on file. Further, automatically send a receipt. These are typically done so that your honest users can tell when something is going on.
Anything else just let through.
Bearing in mind, of course, that QA credentials should NOT work in your Live environment. Those systems should not be tied to each other under any condition and, quite frankly, should even live on separate hardware. In other words, QA and Live should NOT share a login database.
The thing here is that you shouldn't care about the device itself; just the account. You can't control the device as it's out of your hands; heck you can't even be sure it hasn't been physically tampered with. (XBox has been fighting this one with people adding resistors or burning out certain components to get past physical security features).
So, IMHO, do a bit to keep honest people honest but overall don't worry about it. Now, you should transfer everything via SSL or someother encrypted connection between the device and your cloud so that you don't leak ID's to anyone that wants to grab them. This will help protect those honest people.
Further, you shouldn't have a direct way to query whether an ID is valid or not from the outside. This will make it a bit more difficult for a hacker to find existing valid IDs and take over accounts. If you want to get fancy you could honey pot those and track the hackers down in order to sue them into oblivion, but that takes time and resources companies don't normally have. Also you could log all of the requests that contained bad IDs and use that to track hackers down.
Note that even after the device has been "enabled" I still suggest you have two levels of authentication. The first is for simple actions like downloading free content; the second kicks in anytime there is a fee associated. Again, we're trying to protect your honest subscribers.
For the dishonest ones you will have to apply some statistical analysis on the transactions coming across. Things like the transaction rate can help identify bots that are running and allow you to kill their IDs. There are others but they'll be unique to your application.
This was long winded. But my point is:
You can't secure the ID or anything else you pass out.
You can't ensure the requests are coming from your devices or your own approved devices.
You better take actions to keep QA and production separate for those building software for these devices using your services.
You better take actions to protect your normal honest users.
Trust NOTHING.
Due to the above you should evaluate your business model so that you don't care what device was used and instead focus on the individual accounts themselves; which you do have control over.
I am not sure I entirely understand the question, but I think you want some sort of device to hold on to a GUID assigned to it by a web service, and you don't want someone finding out what that GUID is, correct?
If so, there isn't a lot you can do. You have already mentioned one option... using HTTPS during the assigning of the ID. That is a good start, but remember that anyone who has physical access to the device can do a lot of things to look up this ID.
In short, it is impossible to completely hide. Someone can always reverse engineer it. There are folks out there reading data right out of memory with hardware.
this is my first question so please be gentle...
I am working on a software which I would like to protect using some kind of licensing scheme.
A basic scheme would be to generate some "unique" key for a user. The user sends this key and a registration code when he wants to register the software and receives an activation code.
When the application runs it validates the activation code by comparing the "unique" key and a datablob received by decrypting the activation code.
This is fair and quite simple to implement, one can choose different crypto algorithms etc. however this scheme lacks two properties:
If the user manages to spoof hardware signature etc. to produce the same "unique" key on another computer he could use the same license data.
If the user decides to uninstall the application and wants to move it to another computer, there is nothing that prevents him from using the old license data again at the old computer and still obtaining new license data for the new installation.
Do you have any suggestions on how to resolve these issues?
One idea I had was to add some random data to the "unique" key, this random data would be stored in an obscure way, if the user deinstalls the application this random data would be removed, and some kind of hash with the previous random data and the license data would be generated which could be sent to me to verify that he really have uninstalled the application and made me sure that he wont be able to use the previous license data again since the random data had changed.
Over and out, for now...
EDIT:
I currently have a scheme that works, I should mention that the most common product is installed in an embedded enviroment where hardware-changes are very rare and if there is a hardware failure then most certain the machine is broken. But I could modify the hardware-key scheme to take into account and allow for some changes.
Also because of this the software will most likely not be run inside a VM, good point though and I haven't thought about that.
The application does not call out regularly, if a network connection is available the user gets the option to make a more automatic registration, otherwise he/she gets a registration key, enters it in the software and gets an installation ID which is provided to me, registration code + installation ID generates an activation key that the user gets from me which then unlocks the software.
What I am looking for is good/feasible solutions to the 2 points. Hardware spoofing, Revoking license keys i.e. to be sure the user can not use the same regcode+activationcode.
Thank you for all your feedback
It is not necessary to
First, you should make it clear what you're trying to protect. Apparently, you want to ensure that for each purchase of your application, there will only ever be one computer on which the application is installed and runnable.
You propose to use a hardware signature as part of each user's unique key. What happens if my hardware fails (e.g. my hard disk breaks)? I'm certainly not going to purchase your application if I can't go on using it after a hardware problem, so at a minimum you must be prepared to handle key change requests. You'd better respond fast, because if your application is important I want to minimize downtime. And I'm not inviting you to check that my hardware has failed, so you'll have to take my word for it. That means any user can get a free licenses from time to time by pretexting a hardware failure.
What about virtual machines? It's probably feasible to detect all currently existing virtual machine configuration, at the risk of a few false positives now and then. If you forbid virtual machines, how do you justify this to users? If you allow virtual machines, how do you prevent the user from making multiple copies of the whole VM? (This can happen even with physical machines, with hibernation).
Is the application going to call back to you every time it starts? I guess so, from your deinstallation scheme. That's a bandwidth and availabilty cost, and will also put off some users — not everyone is online, especially in sensitive environments. But then you don't need such a complex scheme: your server can keep track of how many copies of the application are running, though you do have to handle the case when the application doesn't terminate cleanly for any reason (application crash, OS crash, power failure, loss of connectivity...).
You don't discuss this in your question, but you have to protect the application executable, so that someone can't bypass the license check with a debugger.
Place your software into appliance hardware and put a padlock on the hardware. Ship the appliance to the customer.
If you believe the customer will hacksaw the appliance open to get your code, consider encrypting the storage medium.... Then they have to hacksaw the box AND find the keys. A TPM chip or secure USB token may aid with the latter.
Being a shareware author and longtime member of ASP myself i think you are going into the wrong direction with your solution. The only way to make this workable is with a hardware device as already suggested. This or constant online activations is the only way if you want to be sure and your product is so good and without competitors that your customers will still use it.
But what we (organized small ISV's) learned from practice is that you should not do what you are trying to do. Do not bind it to hardware. Sell one license per person not one license per computer. In the end you will make more sales because of the relaxed license.
Just do enough to make the honest people stay honest. So limit the trail version (i decided to terminate the application after one hour for me) and leave the final version free from all stuff. Give a separate download for payed customers and thats it. Be a nice company and not a greedy profit maximizing by legal restrictions company.
I used some of the better windows protection programs first but they all had serious problems with my code. And they call get cracked sooner or later. So i gave up all of them.
P.S.: I use a hardware fingerprint schema on windows where i don't restrict the program but just to keep people away from getting new trial keys every 30 days. Together with a nag screen it seems to work. The fingerprint is an xor of user name, windows installation time, modify time stamp of a system files and harddisk serial id.
Let the registration code also be the activation code.
You generate the unique registration code at point of sale, or packaged with the product. Customer registers/activates/deactivates with you (or your server) in one step using that single code. The customer's hardware doesn't have to generate any keys.
Reregistering/reactivating still requires contact with you, so you're aware of reinstall attempts.
I think that the only solution to your problem is a cryptographic hardware dongle. Usually it would be a USB-based tamper-resistant challenge-response dongle, that can be easily transferred between computers.
These devices cost less than $1 for large quantities, and not more than $10 for very small quantities. The good ones are very hard to forge, very easy to embed in your application, and usually supplied with a free EXE encryptor which also contains anti-debugging and anti-reverse-engineering functionality.
Is there a way to determine what kind of data plan a device has so an app provides a less rich experience if a data plan is not available? I imagine the connector factory would still be able to return me an HTTPConnection but it would cost the user serious money for lots of data, and I'd like to be nice and prevent that.
I thought there would be a way to query device capabilities in the MIDP API, but maybe it's in CLDC?
Since you mention it in your comments, you can probably make a Symbian OS C++ application that only connects via a specific set Wi-Fi access points (and just stay offline if none of these are available) but I can't think of a way to figure out the current user data plan or whether a given Wi-fi network is free.None of that is available in J2ME, at least not until something like JSR 307 is implemented.
You might want to look into how the Nokia IAPInfo API behaves on actual phones (including Sony-Ericsson and Samsung Series60 phones, potentially) since it is the closest thing to what you want.
No there is no way to do this.
As far as I know there is no way to do this. To address this precise issue, on first download we provide a big bold letter warning saying our apps require data plan. You can do something similar.
Or you can provide an option on first download for the user to say whether he has a data plan or not, and provide a degraded user experience if he doesnt. Dont forget to keep this as an option in application settings and allow the user to enable data services later, as he/she may get a data plan and want to use your app.
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 :-)