SAP ECC / Sales and Distribution. For more information, visit the Enterprise Resource Planning homepage.
Summary
This whitepaper explains why successful businesses running on SAP need to embrace Data Security Standards inorder to offer their customers highly secure operating IT environment for processing credit card payments. It aims to explain the overall architecture and the challenges in implementing the same for bulk sales and settlements. Such challenges are more so common when it comes to Oil and Gas industry where bulk movements are usually subject to volume and temperature corrections. These challenges are generally not found applicable in smaller scale retail sales and online sales on websites like Amazon or eBay.
Author: Kiran Srirama
Company: SAP Netherlands B.V.
Created on: 01 October 2010
Author Bio
Kiran Srirama works as Senior Business Solution Architect in the BTS (Business Transformation Services Group) at SAP Netherlands. His focus is in providing expert consulting services to SAP customers successfully implementing SAP ERP Sales and Distribution and Industry solutions Oil & Gas. He has worked closely with several SAP partners and enabling partner solutions for the success of SAP’s customers.
Related Content ................................................................................................................................................ 11
More and more organizations are today feeling the need to secure upfront the cash flow for sales being made. Obviously this phenomenon is nothing new when it comes to retail sales and point sales where the value of sale is not large. There are outstanding IT enabled frameworks for achieving such a result.
On the other hand, the businesses who primarily sell to customers in bulk volumes spread across years are often based on mutual trust and expectation that payments would be made in due period of time after products/services are dispatched/fulfilled. In general such arrangement is guided by terms of payment.
However with the recent downturn in the global economy and failures/bankruptcies of multiple companies across the supply chain there has been a growing fear of not receiving payments from customers on time. This trend has also been common in the usually cash rich companies in the Oil and Gas downstream segments including super majors. Subsequently a huge amount of operational issues and costs rose in the process of securing the receivables. Businesses now have to send across multiple reminders to customers who have outstanding payments due. The credit needs to be managed very closely now and credit approval workflow within an organization is ever more hierarchical. Subsequently at times financial losses are also triggered due to write-off cases. This eventually brings to a company the worst of situations i.e. greater focus shift from leadership/vision towards operations and execution. This is not good for any business. Credit card payments are an excellent way to handle (or hedge the risk in) this situation. It is becoming a growing trend to encourage bulk customers pay upfront using credit cards. Several companies like VISA, MasterCard, Discover Card, and American express are making available higher credits. Although this is just one side of the story, the reality is that the selling organization is now way comfortable with dealing with its bulk customers with these card companies assuring the incoming payment from the sale Another aspect is to enable order taking to the maximum time of a day, where possible making it 24x7. Although most bulk transactions are handled on a physical call to a customer contact centre, taking orders online in a “touch-less” way is becoming more often a norm even for bulk sales and bulk volumes. Credit card based payments again offers an excellent possibility here. Looking from the perspective of the Chief Operating Officer (COO), it’s a very simple operation i.e. to establish a new form of customer payment and giving the customer the necessary tools and security for carrying on the business as usual. However it is a completely different world when looked from the perspective of a Chief Information Officer (CIO). Aspects such as adapting to industry data security standards, ensuring the customer sale points are linked in the IT landscape with the necessary credit card clearing houses in a secure manner, and ultimately designing card transactions to match the same capabilities of other established forms of payment including forward sales, invoicing, returns handling, cancellation handing etc are Top Priorities on the table. On an SAP based IT framework achieving such an end result generally would mean integrating the solid ERP backend transactions with SAP’s partner solutions and orchestrating the whole Order to Cash flow seamlessly. The aim of this white paper is to depict some industry details and benchmarks, consider legality behind compelling decisions to move to the latest industry data security standards, and achieving such an implementation on a SAP ERP based backbone. More importantly, the communication to existing customers to switch over to new forms of payment could be a challenge as this means extensive changes on their side as well in enabling credit card based payment and settlement.
Enabling Secure Credit Card Payments on SAP Environment
SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com
SAP offers the basic tools that you require to handle credit cards in various business environments.
Within Sales and Distribution (SD module) the following are possible
Integrate payment card activities into the sales, delivery, and billing processes
Exchange information with clearing houses for authorization
In Risk Management, payment cards can be setup to secure payment guarantee for receivables.
Within Finance (FI module) the following are possible
Carry out settlement and payment functions to complete activities from SD.
Set up an open item-managed, general ledger account for each clearing house
Record processing fees charged by the clearing house for its services
Manage information sent back by clearing houses to accept or reject card transactions
Carry out bill-back processing when a customer disputes a transaction
Although banks and purchasers are included in the payment card concept, SAP payment card processing has been designed specifically for merchants.
While SAP provides the tools required to compute the value to be authorized, but interacting with the clearing house needs a specially designed interface. SAP recommends using third party software to carry out such authorization. That’s where the Payment card interface (PCI) comes into picture and SAP’s partners provide pre-built interfaces to reduce the complexity and errors and to reduce drastically the build time on an own implementation. These partner solutions essentially use the PCI as a base layer to interact from and back to the SAP backend.
A simple integration of credit cards payment into an organization’s sales and distribution depicted below.
Standard SAP encryption with On-Premise authorization Versus Hosted Encryption and authorization:
Most of the current and past implementations are still relying on standard SAP encryption using SAP cryptographic library. The SAP Cryptographic Library is the default security product delivered by SAP for performing encryption functions in SAP Systems. For example, you can use it for providing Secure Network Communications (SNC) between various SAP server components or for using the Secure Sockets Layer (SSL) protocol with the SAP Web Application Server. Secure Network Communications (SNC) integrates an external security product with SAP systems. With SNC, you strengthen security by using additional security functions provided by an external product that is not directly available with SAP systems.
Credit Card encryption in SAP R/3 encrypts Credit Card numbers before they are stored in the database and decrypts the cards numbers while the document is processed if required (e.g. for authorization purposes). In transactions, the system displays only a marked number. The encryption prevents direct database to the tables that contain the Credit Card information or direct select from R/3 environment.
However the key point is that the “encryption key” and “encrypted data” are both stored in the same SAP environment. This brings a couple of challenges as required by the latest PCI DSS council specification that can be viewed at the following web link: https://www.pcisecuritystandards.org/index.shtml
1) Key rotation
The standards specify that the encryption key to be changed atleast once per calendar year. This
however means a production downtime because the system needs to be taken down to decrypt the
data with older key and generate a new key and encrypt back the data with the new key. This takes
some time.
2) Key and Data in the same IT environment
However secure the SAP environment might be, the standards specify that the encrypted key and
data being in the same IT environment pose a threat. If one of them is hacked, chances of hacking
the other are possible. Therefore the suggestion is to move to a different architecture where the data
and key remain in separate environments.
To handle these issues some organizations are moving towards other architectures involving a Hosted Encryption and Authorization. The above two challenges are solved in the following way.
1) Solution to Key rotation problem
On a hosted environment, the Key and Data are different environments. So the key generation is
transparent and data encryption can be seamless and efficient with no production downtime.
2) Solution to Key and Data in the same IT environment problem
In a hosted environment, a new concept of tokens is generally used. Each time a data is identified to
be encrypted, the hosted environment issues a token and the token is stored in SAP instead of the
actual card number. The token is issued on a remote hosted server. Hosting is provided securely by
some certified hosting service companies.
For this reason a hosted encryption and authorization is better. The time required implementing a hosted encryption and authorization variant directly from scratch is much quicker when compared to an upgrade from the existing SAP encrypted variant. This is due to the extensive changes required and local circumstances about how an organization likes to remain consistent with its SAP footprint.
With this challenging situation we now look forward into the finer details of how things actually need to be laid out on SAP framework to work seamlessly.
Handling challenges on the Oil & Gas implementations
SAP is a market leader in providing industry solution software for Oil & Gas industry with its IS-OIL product. In a typical Oil & Gas downstream market the majority products sold are Fuels, Lubricants, Bitumen, and Base oils. In the service stations car care and wash services are provided additionally. In case of some products above packed variant are more common for instance packaged versions in drums and containers for instance. These variants are not as subject to volume and temperature conversion as the bulk versions; the latter being measured for temperature and density while loading and at discharge. IS-Oil offers special screens during delivery processing to store the temperature and density measured at the time of loading a truck for instance and also the ambient temperature along with the loading unit of measure. These are then sent off to a remote server containing software that computes volumes in all additional units of measure belonging to that unit of measure (UoM) group plus any other UoMs necessary. The conversion mechanism follows the ASTM standards (http://www.astm.org/) to convert between the parallel UOMs.
Such parallel UoMs most often result in the value of the delivery being slightly higher of lower than the value authorized at the time of the sales order. For instance you order 100 L15 (liters at 15Celcius) and the price of each L15 is 1 Euro, so this converts to 100 Euros. However, during delivery 100 Liters could be anywhere between 98 L15 of 102 L15 depending on the loading temperature and volume expansion. This volume correction results in either the delivery value being between 98 Euros to 102 Euros. Since the order authorized value is 100 Euros, the cases where the delivery value is higher than 100 Euros will all be blocked and SAP standard does not allow delivering them since the value authorized is lesser than the delivery value. This is a for instance a unique problem for Oil bulk products being sold on payment with card. In general, such problems are solved by an internal agreement within an organization and an external customer communication that their card might be over authorized by a small delta (although order value is lesser) – This helps the deliver to go through and during invoicing and settlement the actual invoiced value is settled. You have user-exists in standard to perform such modification to authorized value during order processing.
Another problem on hosted environments is the tokens that are issued in exchange to credit cards are usually 25 characters in length (including numbers and characters). However SAP cards are maximum 18 in length. In many cases such tokens are simply non-storable on the sales order screens for instance. SAP therefore truncates the token and sends it back for authorization – this obviously fails and gives back a failure of authorization due to bad card. This just means SAP implementations cannot go forward with Tokens anymore. Luckily SAP has released a general available note (OSS note 1427524) so the screen field that holds the credit card is increased to 25 digits. This allows token to be stored and sent out to the partner hosting server with no truncation.
Standard SAP checks validity of authorization during actual goods issue and not during delivery creation. But in most situations of Oil bulk products the delivery creation is already the time when goods are handed over to the customer. So there may be a need that you build own enhancement for an additional check.
For authorizations, SAP standard works quite well products are sold and sent out in full. However with all the complications that comes into picture due the very common partial deliveries in the Oil industry need to be handled additionally. You may have to schedule additional background reports which pick up an order and authorize them over night and make ready for the delivery the next morning.
Data sent out to the clearing house while settlement can be classified into Level 1, Level 2 and Level 3 data. Higher the level, more specific the information is about the sale. Such information helps the organization how more precise information data on the card statement along with ease of reconciliation in the card company. Sending out the Level 2 and Level 3 data depending on the card type is an important decision which Oil companies need to decide and consider the benefit the card supplier can bring due to passing this information (usually discounts of the fee)
There are other issues which might come along depending on the scope of your implementation.
In the below content, please consider “card” incase of SAP Encryption is used in your implementation, else consider “token” incase of Hosted Encryption.
Transaction flow
Order taking: When you create a sales order, you can enter credit card data manually, or copy it from the payer master record. You can enter one card in the sales order overview screen. You are able to enter multiple cards or multiple authorizations on one card, in the payment card plan in the sales order header. The system automatically authorizes the sales order when you save it. Such authorization usually requires a call to the partner software (for instance XiPay from Paymetric) which carries over the data across the PCI interface and receives back response from the authorizing bank or card provider.
Delivery processing: At a later time, you create the delivery. The authorization may have expired in the meantime, so the system checks to ensure that it is still valid. If the authorization is no longer valid, the system tells you to reinitiate authorization in the sales order. This can be done via special transactions provided either by SAP or SAP partner solution. Such re-authorization in general is scheduled as background job (standard program RV21A010) for tomorrow’s deliveries. This saves immense time on your organizations operations because the shipper is usually a different role when compared to the order administrator role. Such automation therefore helps your shipper do his join on time. You complete and save the delivery.
Invoicing: When all the items are picked packed, and goods issue is posted, you create a billing document. Here, payment card data is copied from the sales order, or uploaded directly into the billing document from an external system, as in the case of point of sale. The system uses the authorizations in the payment card plan to calculate billing amounts. You process the billing document and release it to Financial Accounting.
Settlement: When you release the billing document, the system copies the payment card information, billing amount, and authorization information into the accounting document. In accounting, receivables are posted to a special cash clearing account for the clearing house. The appropriate settlement process is then carried out according to the category of the card used. For instance, if a procurement card is used, additional data about the purchase is submitted for settlement.
Card Configuration
Most important pieces of configuration for payment card processing in SAP are located in SPRO
Enabling Secure Credit Card Payments on SAP Environment
SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com
Although banks and purchasers are included in the payment card concept, SAP payment card processing has been designed specifically for merchants. Merchant ID is an important start point that you need to define and agree with the partner so that the transactions are routed correctly to the right processor at the backend.
Merchant ID: Inside SAP Merchant ID, points to a combination of Chart of Accounts and a GL account. Merchant ID is recorded as a part of each successful or unsuccessful authorization line in the SAP sales order header screen. This is simply a way to link the transaction source and destination and also the accounts the authorized value is going to stay on until settled.
The clearing account is maintained in the SPRO node “Set Authorization/Settlement Control per Account”
Credit card type: and the routines used to validate the entered card number are configurable. Most cases where partner solution is involved a new routine is presented in this case.
For Implementations with SAP Encryption, There are several types of checks which are carried out when a card is input onto a screen inorder to ensure we don’t sent bad values to the processor. For instance BIN range check and LUHN check are most common. LUHN is a validation algorithm (http://en.wikipedia.org/wiki/Luhn_algorithm) which is inbuilt into standard SAP function module CCARD_CHECK_LUHN_MOD_TEN. BIN range check is Bank Identification Number check and a means to know the card type a card number belongs to. For instance for VISA card the length is usually 13 or 16 digits and first digit is 4 this is enough to say this is a VISA card. Such standard logic is coded down into standard function module CCARD_CHECK_VISA. BIN is also called as Issuer Identification Number (IIN) with details can be found at (http://en.wikipedia.org/wiki/Bank_card_number#Issuer_Identification_Number_.28IIN.29)
For Implementations with Hosted Encryption, tokens need to be validated in a different way. The BIN and LUHN needs to be conducted after decrypting the token into standard card. However the Token itself can be validated against any wrong entries.
Authorization Validity: On order save, SAP triggers an authorization request. If the authorization is successful, normally each card issuer makes the authorization available for a certain number of days. This is allowed to be customizable although the idea is to ask your card provider and enter the number of days. Usually the number of days for VISA is 7 days, MC is 7 days, and AMEX is 30 days as of today. This means from the day the order authorization is obtained you need to finish the delivery and billing ideally before those days, else another re-authorization on the card would be released. The motivation behind this is that the seller needs to stick to his timelines too and cannot block money on customer’s card for a longer time. In this way the customer has a choice to order more from the released amount. At the same time if a re-authorization is triggered for an order which already has an active authorization there is no duplicate block on additional funds on the card.
Checking group: is another important piece of configuration in the credit card arena. At times you don’t like to burden your customer with blocking his card much ahead of time. For instance you would like to not authorize a card if the material availability date of the product is 1 month ahead from now. But the customer is still interested and would like to place the order. So you would like to setup an “Authorization Horizon” that guides when the system should authorize and when not.
In such cases you would like to perhaps establish a 1$ pre-authorization or soft-authorization stating the order is confirmed.
In general, the authorization horizon specifies the number of days before the material availability date, or billing date, that the system is to initiate authorization. If a sales order is saved within the authorization horizon, the system carries out authorization immediately. If a sales order is saved before the authorization horizon comes into effect, the system does not authorize at all, or carries out preauthorization
In this example, the system has been set to authorize one day before delivery creation. The system does not carry out authorization when the order is saved on Day 0, rather on Day 2. Note that the authorization validity
period has been set to 14 days in Customizing (Authorization and settlement Specify authorization validity periods). The transaction will have to be reauthorized if delivery activities take longer than 14 days.
Returns handling: In general SAP does not provide default copy of sensitive data from document to document using the regular copy controls. For instance when a customer returns a product, you may want to copy the same card information from the original sales order. In such situations card data copy needs an enhancement.
Hosted Encryption and Authorization
On a hosted implementation, the partner usually provides tools to configure the Remote Function Calls (RFC) and decide which ones should be used for obtaining tokens and which one for the actual authorization and settlement purposes. The way the tokens should be displayed is also configurable i.e. since a token is a 25 character field; the last four digits of a card should be somehow made visible on the token, so the choice to show them can be made. Converting existing to SAP encrypted data into tokens is time consuming process that needs to be taken up before going live with such an implementation. This involves decryption using standard SAP tools and tokenization using the partner’s tools.
Enabling Secure Credit Card Payments on SAP Environment
SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com
Probably the biggest change involved is to have your customer’s signup the new form of payment. Most often customers prefer to remain in the same old system because of two main reasons: it’s established and it’s tested and trusted. Bringing a change is very crucial, so getting your customers to sign up. Retail sales are very different since customers with low value sales are easily adapting to new modes of payment. But with bulk sales and customers buying bulk volumes, it’s not easy to convert the strategy and bring this change. Therefore most often customer incentive programs are rolled out within an organization. Perhaps giving a small discount or waiving off a little surcharge if purchased by credit card. This is in the interest of the company due to the guaranteed income of products (and lower risk in the sale). Another way is to insist this is the default payment method for new customers. Especially, considering one-time customers it’s perhaps the easiest and risk free payment method.
Certain amount of change management is involved when going live with card based payments. Clearly the attempt and aim is to automate and give customers allot more flexibility that they used have. All the usual problems that customers used to have with the order facing, namely, considering opening hours and closing hours of an office, making a call or sending out a fax is all changed now. Systems are open 24/7 and order processing is more seamless. Since the stock availability is a key topic, you could link customer’s card based on the horizon you define for the material availability therefore not blocking customer’s funds on card unnecessarily. Re-authorization background scheduling also reduces time loss during delivery processing since the system now is intelligent to lookup the orders which will be delivered tomorrow and re-authorize them automatically.
Such a design now means the customer contact center colleagues are more educated about how orders are taken and how the processing of card based orders is different to the regular order taking. Workflow approval is different if your organization is big and needs a complex implementation. New organizational roles are needed and perhaps at times it’s also possible to re-organize the existing roles.
Trusted engagement is required when Hosted Encryption is in place as there are special user accounts provided to the Hosted environment where the customer cards are available in raw format. Only special organizational roles need these roles and accordingly training.
After this rollout, the support in your organization needs knowledge interacting with the SAP partner and approaching for guidance where required.
Summary
Organizations attempting a large scale implementation of credit cards based payment processing can fully rely on SAP and its framework along with the brilliant eco-system with SAP partners and solutions.
Change Management is essential factor which makes such a rollout sucessful. Change is required both externally (customers, distributors) and internally (customer contact management staff, workflow representatives, invoice administrators and settlement administrators)
Understanding where SAP Partner solutions come into picture and what they offer is very important. Its important to rely on PCI DSS standards organization and understand which rules are considered to be must and which ones are just recommended. Since there are many partners involved in having a card authorized and settled, its nice to have knowledge about Card Issuers, Clearing houses and their software platform. At times this becomes transparent with the SAP Partner solution coming into picture.
Key Performance Indicators need to be established to measure what gains we could have with such an implementation. Its required because your organization might have to spend those worthy dollars in licensing software additional to the hardware requirements that come along with the connecting adaptors (or bridges) between SAP and SAP Partner Hosted solution. KPI’s like improved order taking during out of office hours aswell and during office hours is a key indicator. Time spent in settlement of any sale should be drastically reduced.
Most important KPI could be the risk you reduced from late payments from customers. The amount of time spent in sending out reminders and chasing customers to pay back their dues is now gone. Credit Management Teams are now releived from finding new techniques to improve the risk mitigation mechanisms.
In general the objectives of implementing credit card payments can be fulfilled by an SAP implementation and card handling above it.
Enabling Secure Credit Card Payments on SAP Environment
SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.
All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
