Show me the money! Money is, in many ways, why most of us are working. And companies need income to pay us. So how does your company get paid? Or how does your client get paid by their customers? Accepting checks is easy enough, but many of your customers are going to want to be able to pay by credit card. Salesforce has a few AppExchange apps that handle credit card billing, but most can’t be customized for your already pre-existing conditions. If you are working with the wrong bank or the wrong processor, you are out of luck. There are a few ways to handle credit card processing and hook it up to Salesforce without these apps.
The most straightforward is integrating with a site that already does credit card processing and setting up a callback to Salesforce with either a SOAP or REST API call. That way your company isn’t actually involved in the nitty-gritty of the process. You send the customer a link, they go to the link and enter their payment information, and then the updated information gets sent back to Salesforce. This limits some of the problems that can come from handling credit cards yourself.
And those problems can be severe, depending on how you handle credit cards. If you gather credit card data, then you are required to adhere to the Payment Card Industry Data Security Standard (PCI DSS). Even if you are using an application that is validated to Payment Application Data Security Standards, you will probably have to verify that the whole process is PCI compliant. Audits, meetings, and paperwork are sure to follow. My recommendation? The short version is to never see or handle the cardholder data that is part of the PCI DSS requirements.
The external integration that handles everything, which I mentioned above, is probably the overall easiest way, but also the least customizable. I’ve worked on 2 integrations and a key point in both of those processes was that we handed the web form data directly to the credit card processor so that we never saw the data and therefore weren’t bound by the PCI DSS requirements.
The first of the 2 integrations I’ve been involved in was with a large scale payment handler. It presented a EULA (End User License Agreement) to the customer that was appropriate for the items they were paying for. It marked when and by whom the EULA was approved. It accepted the payment by directing the card data to the payment processor and then parsed the results. And if the payment was successful, it did some behind-the-scenes work to get the product moving out the door. We were trying to make it as close to the Amazon user experience as possible. We even included the saving of a payment token so that we could bill subscription services to a customer’s card as needed. All of this was without seeing a bit of cardholder data. It was also customized specifically for the payment processor and bank that the company was using. The company didn’t have to swap banks or get new bank accounts. The site was built in PHP with connections to Salesforce and the payment processor.
My second experience with this level of integration was built much closer on top of Salesforce. For this client, we set up a couple of Visualforce pages that sent the cardholder data to the payment processor. A different Visualforce page parsed the return information from the processor and handled the updating of the object data. Pretty simple and not too difficult. The worst problem was, of course, managing the encryption and data security with the processor itself. That can get pretty intense. But it’s still something that can be done. Of course, it’s much simpler if you’ve done it before.
Payment processing can work with Salesforce. But you should try to avoid holding credit card data as much as possible. Doing that incorrectly can lead to rather large fines from the payment Card Industry. Don’t get fined. Handle your customers’ data correctly. For further reading on payment processing and the data standards, please check www.pcisecuritystandards.org. And share your own experiences–good and bad–with integrating payment processing into past Salesforce projects in the comments section below.
