The Big Problems

The biggest problem with processing payment cards (processing credit cards, debit cards & corporate buying cards) with SAP, is the integration with the payment card gateway or the bank. If you plan to develop your own, it takes many months of development. Then the interface needs to be certified by the financial institution to meet certain standards (different for different banks). At the end of the day, you now have this custom interface that needs to be maintained each time there is a change in the requirements. The question you need to ask yourself is: What is my core business? Do I really want to be in software development?

The Solution

Find a third party company that specializes in payment card processing and integration into SAP. There are several of them, but the market leader (they have approximately 80% of the market) is Paymetric. The company has been in that space for over 10 years and has a few very sharp individuals at the helm. They offer 2 main products:

1. XiPay – Payment Card Processing
2. XiSecure – New Product that handles Payment Card Tokens (discussed in another article)

History of the XiPay Solution

XiPay has come a long way. I first saw it in 2002 and then it was just a collection of SAP programs designed to address the gaps within SAP. So they were attempting to address the second problem with the SAP functionality, namely, the functionality gaps. You still had to develop your own interface with the bank.

I next saw it in 2007 and it now offered a fairly comprehensive solution. It now also comprised of a separate server that took care of the interfaces with a slew of different payment processors and banks. To activate an interface with your bank or payment card processor,  you needed to add that banks software “cartridge” and make a few configuration settings.   A pretty elegant design.  That solved the biggest problem described in the first paragraph.

In the latter part of 2007, the payment card industry introduces a set of new data security standards (discussed in a previous article) that had to be complied with if you wanted to process payment with credit cards. This PCI Compliance changed the face of the payment card industry much the same as SOX changed the face of businesses several years ago.

What does it give you?

One big plus of the on demand solution, I think, is that it gets rid of the XiPay server that you need to maintain at your site  (in practice, this was at least 2 servers, 1 for your development and QA environment and 1 for your production environment). It was fairly specialized and I found that despite spending time with the Paymetric technical resource, our Basis person (who was good), still had to schedule time with Paymetric anytime an installation or patch had to be applied.  This created several delays in our implementation.

With the introduction of the on demand solution, instead of having to support about 1000 customers server installations, paymetric now only has to support one. And all the clients hook into this server.

With the XiPay On Demand solution, that technical maintenance aspect goes away, allowing you to focus on your core business again.

If you also implement a payment card token system, such as XiSecure (discussed in an upcoming article), the PCI Compliance become even less of an issue.

Conclusion

The paymetric XiPay solution simplifies your payment card processing in your SAP implementation and the on demand aspect provide some real advantages on an on-going basis.

Feel free to add Comments and Questions.

What is the biggest problem with Credit Card Data?

A tongue in cheek reply would be: “The Credit Card Data dummy!” While it is a tongue in check reply, there is some truth to it.

Having been involved with many implementations, I have seen this over and over. It is always an issue securing and protecting this data and only displaying it to those that need to know. Here are some classic issues I have seen.

Most SAP infrastructures include a Quality Assurance client for testing changes before moving these to the Production environment. And it is very often a copy of Production at some point in time. And what comes over with that copy? All the customers Payment Card data. So you need to do 1 of 2 things:

1. Purge the Credit Card Data (have to write a custom program)
2. Encrypt that data – very often not activated in the QA environment. And quite a process to turn on.

The Result of Encryption

When a credit card is encrypted in the database, it is displayed as ************4141 for example.

The problem is that it needs to be displayed everywhere like that. I have seen instances where someone will run a report and the unencrypted credit card will show up. Or someone enters a transaction from a different direction, or accesses a rarely used screen, and suddenly the unblemished, unencrypted credit card data show up.

And in reality, the Payment Card is still saved in our database. And we are responsible for securing and protecting that data.

What is a Token

What if we could move the Credit Card data from our database and give it to another server (called a Token Server)? The Token server then gives us back a Token that is representative of the Credit Card data. So the actual Credit Card data in our databases, is now replaced by a Token data.

For example: It gives us back ************4141 to store in out database. The only link from the token to the Credit Card data is now held on the Token Server.

Advantages of Tokenization

1. Now we do not have the credit card data in our database. If someone hacked into our database or a user accessed the customer Payment Card data, they could not do anything with the ************4141.
2. Obviously the Token Server needs to be secured and PCI compliant. But this means that we only have one system to secure, instead of potentially many systems.
3. And if we contract with a 3rd party to supply this Token Server, we have now moved the responsibility off site to another company whose core business is to secure such data and remain PCI compliant.
4. This reducing our costs.
5. If the Credit Card data is ever needed, a query goes out to the Token Server which returns the Credit Card Data. This makes PCI compliance much easier as we do not store Credit Card data on site anymore.

Who offers these Tokenization Services for SAP

Probably the best known of the Service Providers is Paymetric, with their XiSecure Service (they use a 25 Character Token).

1. XiSecure – Onsite local Installation
2. XiSecure – SAAS Hosted Offsite Service.

Whilst I have not implemented a Token system yet, it makes sense and would be a useful compliment to a Credit Card Payment System.

Paymetric Implementation masks a Looming Change to the Payment Card Industry

What led to the Payment Card Industry Change?

New Payment Card Industry Data Security Standard (PCI DSS)

What are the PCI Standards?

1. Build and Maintain a Secure Network
   • Requirement 1: Install and Maintain a Firewall to protect cardholder data
   • Requirement 2: Make sure you create and use your own strong passwords (don’t use vendor supplied passwords)
2. Protect Cardholder Data
   • Requirement 3: Protect stored Cardholder data
   • Requirement 4: Encrypt data transmission of cardholder data across public networks
3. Implement a Vulnerability Management Program
   • Requirement 5: Use and regularly update Anti-Virus programs and measures
   • Requirement 6: Develop and maintain secure systems and applications
4. Implement Strong Access Control
   • Requirement 7: Restrict access to cardholder information to strict business need-to know personnel
   • Requirement 8: Each person needs to be assigned a unique ID for computer access
   • Requirement 9: Restrict the physical access for cardholder data
5. Regularly Monitor and Test Networks
   • Requirement 10: Track and monitor all access to network resources and cardholder data
   • Requirement 11: Regularly test security systems and processes
6. Maintain an Information Security Policy
   • Requirement 12: Maintain a security policy that includes both employees and contractors

PCI Compliance & PCI Audit Requirements

1. A PCI data security assessment (on site or self assessment)
2. A Third party network scan (quarterly or annually)

Consequences of Non PCI DSS Compliance

1. Card Companies may impose fines up to $500,000 on the Banks if their merchants are not complying.
2. Merchants could risk losing their ability to process credit cards
3. Business’s whose cardholder data has been compromised, are obliged to notify legal authorities and provide free credit-protection services to those who are affected.
4. Cardholder’s may sue you. This may lead to bad publicity and potential loss of business.

Conclusion

I hope this brief overview of PCI DSS has been informative.

I have spent the past 5 months working with Paymetric’s solution for SAP credit cards and I must say I have been impressed.

I first came across Paymetric in 2002 when supporting Credit Cards from the CRM side and they have come a long way since then. I was impressed with their expertise at that stage but their solution was not as comprehensive as it is today.

They have had a long and comprehensive look at SAP’s standard solution for credit cards and developed their offering to fill the gaps and improve the functionality.

Here are a few examples:

• In standard SAP, the customer needs to decide up front in the sales order to pay by credit card. It is not possible to pay for your open A/R balance later. Paymetric’s Open A/R module allows you to select Open balances after the fact to settle with a credit card.
• In standard SAP, if you have a billing plan of say 3 bills of $5,000 each, SAP will attempt to authorize the whole $15,000 instead of only the amount with in the configured horizon. There is a way of using the Auto A/R module to cover this.

The solution comprises of a group of SAP programs (imported as a series of transports) and a separate server called XiPay (actually server is a misnomer, it is actually a piece of middleware that communicates with the payment processor). There is also an encryption/decryption server which resides on the same box.

The XiPay server is where you get a lot of value, as Paymetric has certified their interfaces with the processors (and they support quite a few). This save a bunch of development and testing time.
Even though the solution is vastly improved, it does not necessarily mean that you do not have to add code to user exits.

For example: It does not support Invoice Cancellations out of the box. You need to add some coding to cover the 2 scenarios: before settlement and after settlement. Actually, most of the coding is related to the XiPay side in this case. Another example is Billing Plans. A bit of code needs to be added to handle these.

Whatever you do, do not underestimate the effort still involved in implementing credit cards as we have discovered. Paymetric definitely does shorten the implementation time dramatically, but do not get the illusion that it is a plug and go.

I have also been very impressed with the caliber of the Paymetric consultants when we have had questions or issues.

In summary, I think it is an excellent solution and well worth the investment. It will shorten your credit card implementation time and really improve your final solution.