Intro to-payment-processing-in-sap
- 1. Introduction to Payment Card Processing in SAP How to optimize payment card acceptance by leveraging an SAP® certified solution
- 2. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 2 Table of Contents Introduction to Payment Card Processing in SAP 3 Why Process Electronic Payments in SAP? 3 What You Need to Know Before You Start 3 The Pitfalls of Doing It Yourself 4 Verify Your SAP Functionality 5 Understanding the Transaction Process 6 Configuring Functionality Built into SAP 7 Processing Business Logic in SAP ERP 8 Processing Limitations in SAP ERP 8 Configuration Tips and Tricks 9 Standard SAP Reporting 10 Technical Advantages of Third-Party Card Processing Solutions 10 Enhanced Functionality for XiReceivables 11 XiReceivables Solution Options 11 Features of XiPay On-demand 12 Benefits of XiPay On-demand 12 About Paymetric 13
- 3. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 3 Executive Summary While SAP’s products provide basic payment card processing capabilities, ensuring functional continuity and transaction efficiency between multiple SAP components and payment processors is a far more complex challenge than many realize. It is important to understand the payment card processing landscape and the associated requirements involving SAP products. Using an external payment processing service offers an attractive alternative for those who want to avoid the additional burden on in- house resources, accelerate time-to-value and ensure continuous compliance with industry best practices. By certifying XiPay® On-demand, Paymetric’s integrated payment card processing service for Cross Application Payment Card Interface (CA-PCI) integration, SAP has confirmed the viability of this award- winning solution. This white paper explains in detail how to best plan and implement payment card processing in SAP’s products. It highlights the benefits of utilizing Paymetric’s Software-as-a-Service (SaaS) based payment card processing capabilities to maximize the operational and financial payback from payment card transaction processing. Why Process Electronic Payments in SAP? Increasingly, organizations that utilize SAP are exploring electronic payment acceptance as a vital component of their financial supply chain. Electronic payments are accepted via credit, debit, purchase, corporate, loyalty and gift cards, as well as eCheck, offering clear advantages over manual, paper-intensive processing methods. Besides substantial labor savings, accepting payment cards can free up valuable working capital by reducing Days of Sales Outstanding (DSO) and decreasing exposure to accounts receivable risk. Accepting electronic payments improves cash flow by dramatically speeding the settlement process from 30 to 90 days or more for paper-based transactions to a matter of 24 to 72 hours for electronic payments. Payment card acceptance provides real-time transaction authorization with an immediate guarantee from the card’s issuing bank, effectively transferring transactional and credit risk to the issuing bank and away from the merchant. Automatic payment authorization via electronic payment also provides an effective control to ensure that shipment of goods is based on legitimate, secure and timely payment. Given the potential labor savings and accelerated cash flow obtained by integrating payment cards into the financial supply chain, it is not surprising that many IT departments are running SAP systems have received their “marching orders” to plan and implement electronic payment processing.
- 4. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 4 What You Need to Know Before You Start Before implementing electronic payment processing in SAP’s products, technical professionals can reduce the risk of mid-project surprises by developing a solid understanding of the overall payment card processing environment and the specific requirements involving SAP’s products. While SAP products provide basic payment card processing capabilities, ensuring functional continuity and transaction efficiency between multiple SAP components, other payment acceptance systems, payment processors and other financial institutions are far more complex challenges than many may realize. Particularly in North America, payment card transaction processing requires managed access to the gateway positioned between the merchant and the payment processor (see figure 1). Most major financial institutions have a proprietary processing network associated with their payment card operations. Examples of payment processors include Elavon, First Data, Bank of America Merchant Services, Chase Paymentech, Heartland and RBS WorldPay. The Pitfalls of Doing It Yourself Because SAP’s products do not offer direct connections to the payment processors, the necessary interface between your organization and the payment card processing network must either be developed in-house or an SAP- certified third party solution must be leveraged. Developing and maintaining a custom, in-house interface between SAP’s products (defined by SAP as the Cross Application Payment Card Interface or CA-PCI) and payment processors typically requires a substantial commitment of staff resources and time. In many cases, the process will require months of effort and a development team of IT professionals. Additionally, a separate interface must be built to connect each proprietary processing network. In the event of an interface change to your application, the payment application or the processor, it would be your company’s responsibility to support that on an ongoing basis. The advantages of leveraging a third party, integrated on- demand payment card processing service become more evident as one gains a better understanding of the native functionality and limitations of connecting to processing networks with SAP’s applications. Figure 1: Financial Supply Chain: Payment Card Processing Gap SAP’s products provide basic payment card processing functionality, but do not provide a direct connection between various SAP products and the payment card processing networks. SAP Order Entry Order Management Customer Management Clearing Open Receivables Accounting and Reconciliation Business Processes Payment Card Processing Gap Connects to financial institutions to provide transaction authorization and settlement services Issues payment cards, ensures the availibility of customer funds CSR Takes Order Web Store Order Merchant Environment Gateway Processor Issuing Bank Credit Card Process
- 5. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 5 Verify Your SAP Functionality Payment card functionality is found in SAP Business Suite from release 4.0B and above, including ECC 6.0, the latest SAP ERP release. In addition, many of the other SAP products such as SAP CRM, SAP Business ByDesign, SAP BusinessOne and SAP Biller Direct incorporate payment card processing functionality. In SAP Business Suite, payment card functionality is integrated with both the Sales and Distribution (SD) and Financial (FI) modules. Configuration of SAP products allows you to choose the card types to be accepted, specify the order and invoice types that allow payment card processing and identify customers that may be restricted from payment card use. In addition, the connection from SAP’s products to a payment processor requires either an Internet or dedicated frame relay connection. To address some, but not all, security and privacy regulations and policies, SAP introduced encryption for payment card number in R/3 (see OSS note 766703) that is available in releases 4.6C and higher. Please check SAP’s online support for the latest updates. All SAP products with payment card processing business logic also include encryption functionality. But most industry experts recommend going beyond the level of encryption provided by SAP’s encryption solution for maximum data security. Third-party service providers, including Paymetric, include solutions for protecting payment card numbers for all SAP releases including the ones that do not contain the new SAP encryption functionality. Paymetric’s solution is called tokenization, a solution that goes one step further than encryption by actually removing sensitive data with a surrogate number known as a token. You will no longer store sensitive cardholder data in your enterprise systems and applications, protecting your business from theft or misuse by unauthorized personnel. The sensitive data is stored in Paymetric’s highly secure off-site data vault, and you can continue to conduct business as usual with tokens. In July 2010, VISA issued the Tokenization Best Practices Guideline and endorsed the use of the technology to reduce PCI DSS scope. Figure 2: Paymetric Provides Interface Between SAP Products and Payment Processors On-demand payment card processing services from Paymetric offer an attractive alternative for those who want to avoid the additional burden on in-house resources, accelerate time-to-value and ensure continuous compliance with industry best practices. By certifying Paymetric solutions for SAP’s CA-PCI, SAP has confirmed viability for this option. CSR Takes Order Merchant Order SAP Order Entry Order Management Customer Management Clearing Open Receivables Accounting and Reconciliation Business Processes Bridges the Processing Gap Merchant Environment Connects to financial institutions to provide transaction authorization and settlement services Issues payment cards, ensures the availibility of customer funds Gateway Processor Issuing Bank Credit Card Process
- 6. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 6 Understanding the Transaction Process In SAP’s products, payment card processing is basically a two-step process. The first step, payment authorization, occurs in real-time during the sales order save process. The second step, payment settlement, occurs after invoicing as a scheduled batch job or is executed manually at any time, if desired. Figure 3 shows a customer requesting goods or services from a merchant. Upon collecting the customer’s card data for payment, the merchant sends an authorization request to Paymetric who then sends it to the processor that in turn sends it the credit card issuing bank. The issuing bank responds to the authorization request with approval or denial. If approved, the processor then provides the authorization information to Paymetric who then provides the response along with a token to the merchant, who can then approve the order and ship the goods to the customer. Figure 3: Understanding the Authorization Process Authorization occurs in real-time during sales order save. Authorization Process Customer Customer • Requests goods and services • Provides card data • Receives goods and services if approved Merchant Merchant • Receives card data • Sends authorization request securely using token to Paymetric • Sends authorization request to processor • Sends authorization response and token back to the merchant • Approves order or places on credit hold • Sends authorization request to issuing bank • Sends authorization respones to Paymetric Processor Processor Issuing Bank
- 7. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 7 Configuring Functionality Built into SAP It’s important to note several distinctions in configuring SAP products’ functionality for both the authorization and settlement processes. First the customer’s accounts receivable account is cleared of any liability once the invoice is posted to accounting. Liability is then posted to a credit card receivable account, essentially transferring the liability to the financial institution that issued the payment card and approved the transaction. As these transactions accumulate in the credit card receivable account, they become eligible for subsequent settlement batch processing. Second, settlement deposits for payment card payments must be manually reconciled within SAP’s Financial module. Settlement clears all open items in a credit card clearing account into a bank settlement cash clearing account. Items in the bank settlement cash clearing account must then be manually cleared as an offset to a cash account and an optional posting to a credit card processing fees account. Figure 4: Understanding the Settlement Process The settlement process occurs in batch only after billing or invoicing the card payment in SAP. The merchant sends transactions to Paymetric, who formats the request for the payment processor. The payment processor then communicates with the various issuing banks, which transfer funds to the acquiring bank. The merchant bank finally receives the funds from the acquiring bank, minus any transaction fees, and then notifies the merchant of funds deposited. The merchant then manually reconciles the deposits in SAP’s financial module. Merchant Settlement Process • Transmits batch settlement request securely utilizing tokens Merchant • Receives funds deposit notification • Manually reconciles in SAP • Breaks each individual transaction out of the settlement batch and sends to the appropriate issuing bank • Formats batch settlement request for the payment processor Processor • Debits customer account and updates cardholder statement • Funds the acquiring bank minus interchange fees Issuing Bank • Funds the merchant bank minus transaction processing fees Processor
- 8. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 8 Processing Business Logic in SAP ERP SAP contains pre-defined business rules and functionality that dictate how processes such as payment card approvals and declines are handled, as well as specific card-related accounting procedures. It’s important to understand the functionality, business logic and limitations of these processes when planning and implementing payment card transaction processing and management. SAP contains standard payment card processing business logic that features controls such as verification functionality such as standard Luhn checks to validate the card number at the time of card entry. SAP will also warn if expiration dates have lapsed. In addition, SAP can capture Card Verification Value (CVV) or Card Identification Number (CID) values. Also note that authorization request occurs only at the time of sales order save in standard SAP business logic. Once the order is saved, SAP receives an authorization response from Paymetric on behalf of the payment processor, which may be one of the following types: Approval, Communication Error or Decline. Additional information in the response includes an Address Verification System (AVS) response code and a Card Verification Value (CVV) response code. Processing Limitations in SAP ERP While SAP offers substantial payment card functionality, some functions are not configurable. At sales order save, for example, SAP automatically checks for sufficient authorization. If insufficient authorization exists, orders are placed on credit hold and are shown in standard credit management transactions: VKM1, VKM3 or a payment card specific credit management transaction, VCCI. The credit hold will automatically be released if authorization is obtained at a later time or if payment card details are deleted from the order, returning it to a “payments terms” relevant order. Insufficient or expired authorization on a sales order will also place deliveries that originated with this order on credit hold. A valid authorization must exist on the sales order to pick, pack and Post Goods Issue (PGI) for any subsequent deliveries. Insufficient or expired authorization at invoice creation will block the invoice from posting to accounting (blocked invoices are listed by transaction VFX3). The Invoice can be posted to accounting only once sufficient authorization is obtained on the sales order. Accounting postings in SAP FI also vary from standard invoicing methods when accepting payment card payments. As noted earlier, posting an order to accounting clears the customer’s liability and posts it to the credit card receivable account. This effectively transfers the liability to the card’s issuing bank rather than the customer’s account. Only when the credit card receivables account entries are posted on an accounting document is settlement submission possible. When an invoice is created, with a valid credit card authorization of an amount equal to or greater than the invoice amount, an accounting document is automatically posted. When a payment card is used, the Customer AR account is immediately cleared of any liability for payment. The liability then shifts to the credit card receivables account. The credit card receivables account will include other postings representing other invoices with payment card payments and is reflective of the day’s activity. During settlement, the postings in the credit card receivables account will be cleared in one lump sum that is posted to a settlement bank cash clearing account. Upon receipt of the deposit for the settlement submission in the merchant’s bank account, typically 1-3 days later, the lump sum posting to the settlement bank cash clearing account is then manually reconciled to the merchant’s cash account. There may also be additional postings to reflect the card processing fees that have been withheld. This posting will credit the merchant’s cash account and debit the credit card fees account.
- 9. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 9 Configuration Tips and Tricks SAP includes an “Authorization Horizon” configuration setting that specifies a shipment confirmation window. If a sales order line item is not available to ship within “X” number of days, the price of that item will not be included in the authorization request. To prevent the customer’s credit limit from being tied up unnecessarily, it is best to limit the “Authorization Horizon” to as few days as possible. Three days or less is a common setting. An item ordered that takes weeks or even months to fabricate and deliver, for example, would tie up the purchaser’s credit limit unnecessarily if authorization was obtained at initial order entry time. Once an authorization is obtained, a configurable “Authorization Validity Period” determines how many days the authorization is considered valid and when a new authorization is needed to complete the order-to-cash process and allow for delivery and billing. Authorization validity periods can be defined for each type of credit card accepted. Processors commonly recommend that the authorization validity periods be set to 7 days for all card types. A merchant should consult their processor for advice on how many days the authorization validity period should be set to. In addition, many orders can include freight and other variable charges that cannot be precisely determined at the time of sales order entry. In these scenarios, it is helpful to buffer the authorization amounts to account for price changes or additions that occur from the time of order entry to invoicing. This will avoid interruptions to delivery and billing processes because of insufficient authorization and will reduce confusion and disputes that may occur when multiple charges are applied to single invoice. (e.g., one charge for the goods order and one charge for freight to ship the order). Buffering of authorizations is usually performed in the AUTHORIZATION_VALUE_SPLIT “userexit” in program MV45AFZH. The AUTHORIZATION_VALUE_SPLIT “userexit” performs several functions that allow you to predict delivery splits in an order and obtain an authorization for each subsequent delivery, or insert an authorization buffer amount to compensate for order value fluctuations such as the addition of freight charges or tax calculations. Other “userexit” enhancements in SAP include preventing accidental credit release of credit card holds from transactions VKM1 or VKM3 and copying payment card details by reference from document to document. It’s important to recognize that while you can utilize “userexits” in native SAP, SAP payment processing experts such as Paymetric have already completed this coding work, giving merchants the desired functionality while saving much time and effort. Figure 5: The Transfer of Liability to the Issuing Bank Once the issuing bank has authorized payment card payments, and an Invoice has been posted to Accounting in SAP, liability is effectively transferred from the customer AR account to a credit card receivable account representing the issuing bank. The issuing bank then guarantees funds delivery to your merchant bank account. The tables below depict this transfer of liability from the customer AR account to the credit card receivables account. Customer Settlement Cash Credit Card Receivables Credit Card Fees 100 100 100 50 225 75 225 225 225 6.75 6.75
- 10. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 10 By defining your authorization horizon to within three days, or less, of scheduled shipment, you can optimize the amount of time you have to ship products to the customer and settle the card payment before the authorization becomes “stale” or expired. Standard SAP Reporting Native SAP offers several standard reporting tools that summarize and detail transactions such as Settlement (FCC1). Resubmit Settlement (FCC2), Settlement Batch Logs (FCC4), Settlement Batch Reports (FCCR), Credit Card Orders and Deliveries on Credit Hold (VCC1) and Invoices Blocked from Accounting for Insufficient Authorization (VFX3). You can also create customized reports using data stored in standard SAP tables to show Payment Card Transaction Data in SD (FPLTC), Payment Card Transaction Data in FI (BSEGC) and Customer Master Credit Card Information (VCNUM & VCKUN). Paymetric provides SAP users a variety of custom reports in a desirable format so that you can have a more usable view of information stored in the SAP database. Better reporting can assist merchants in analyzing trends, lowering transaction costs, maximizing performance, enhancing efficiencies and understanding customer-buying behavior. Sample SAP Reports Provided by Paymetric Include: §§ Settlement batch items reported by batch number with debit and credit subtotals to assist with the reconciliation of deposits §§ Settlement batch items reported across batches by date range with debit and credit subtotals §§ Identification of expiring authorizations to proactively obtain new authorizations to expedite shipping and billing §§ Identification of SAP documents on which specific payment card numbers were used Technical Advantages of Third-Party Card Processing Solutions Since 1998, Paymetric has applied industry best practices to combine intelligent transaction processing with SAP-certified integration for streamlined payment card implementation and other ongoing operations. Serving more than 500 SAP customers, including many Fortune 100, 500, 1,000 and Global 2000 organizations. Paymetric solutions address the processing limitations in SAP’s products to deliver enhanced payment card functionality, configuration and reporting. By implementing a proven, award-winning integrated payment processing solution from Paymetric, your organization can save hundreds of hours in research, development and installation, enabling you to rapidly meet the demands of your business stakeholders. As with any deployment, it is essential to allow adequate time to process management and implementation testing. XiPay® On-demand, Paymetric’s on-demand payment card processing service, offers plug-in integration to the most commonly used payment processors so you won’t have to re-code your interface if you would like to switch processors or if the payment processor’s interface changes. Paymetric also provides the capability to extend the payment card processing functionality in SAP with real-time authorization, more efficient payment processing business logic, tokenized payment card numbers and automated batch settlement processing. Paymetric’s on-demand service interface is so tightly integrated that it is invisible to users of SAP screens, enabling you to avoid extensive training or business process modification.
- 11. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 11 Enhanced Functionality for XiReceivables To apply payment against open receivables, native SAP workflows require that invoices be canceled and reissued through the sales system rather than allowing credit card payments directly against open receivables. With Paymetric’s SAP Pinnacle award-winning XiReceivables solution for XiPay On-demand, companies can accept electronic payments directly against accounting documents and automatically clear open items. Benefits also include reduced risk, improved customer satisfaction and reduced DSO. Paymetric’s XiReceivables solution enables acceptance of credit card payments against open accounting documents for one-off transactions, recurring transactions or even down payments, prepayments and deposits. XiReceivables Solution Options Automatically process payments in the SAP Financial module utilizing any of the following options: Open AR: Accept electronic payments against open accounting documents and automatically clear open items with an efficient process, even clearing multiple items in a single payment. Auto AR: Optimizes recurring payment relationships by managing payment acceptance of services and products provided by subscription, recurring or rescheduled delivery. Direct AR: Accommodates deposit and down payment processing with an efficient workflow that allows organizations to accept electronic payments and post debits and credits directly to customer accounts. Figure 6: Paymetric’s Fully Integated, On-Demand Payment Card Processing Service Based on a modular open architecture engineered for efficient enterprise integration, Paymetric provides the flexibility to rapidly accommodate the most current payment methods. XiPay On-demand allows electronic payments to flow securely to payment processors from any system where payment originates within an enterprise. Tokenization Settlement No payment data subject to PCI DSS remains in enterprise applications Merchant ERPCRM WEB CALL CENTER POS KIOSK MOBILE LEGACY Gateway Processor Issuing Bank Authorization
- 12. Paymetric | White Paper | Introduction to Payment Card Processing in SAP 12 Features of XiPay On-demand Paymetric’s XiPay On-demand solution is a SaaS (Software- as-a-Service) solution that enables companies to manage, accept and integrate virtually every type of electronic payment in any enterprise system where payment is accepted. Below are the standard features of XiPay On- demand: §§ Level 1 and 2 Processing – Enables required data to flow to processors and banks to ensure that transactions remain qualified for the lowest possible processing fees §§ Accept Multiple Payment Types – Support for credit, debit, stored value, gift, payment and corporate cards as well as eChecks §§ Accept Alternative Payments – Immediate access to multiple payment types, including Bill Me Later, Google Checkout and PayPal §§ Accept Multiple Currencies – Support for multiple currency types facilitates payment acceptance worldwide §§ Processor Connectivity – Integrated modules enable seamless connectivity to your processor of choice §§ Web-based User Interface – Provides powerful reporting and transaction management facilities in a familiar environment §§ Multi-Tenant Architecture – Support for Merchant IDs, company codes and business units §§ Multiple Cardholder Authentication Types – Support for 3D Secure/UCAF, CVV2, CVC2, CID, AVS and custom scripts §§ High Availability – 24X7 operations are supported via high availability mechanisms such as parallel processing, load balancing and database clustering §§ Basic Reporting – A comprehensive set of reports that include daily, weekly, and monthly activity, all transactions, or only authorized transactions, credits, staged transactions, in-progress, settled transactions, error transactions and batch details Benefits of XiPay On-demand Reduced Total Cost of Ownership of Electronic Payment Acceptance Where traditional, on-premise payment applications require major licensing fees, significant hardware procurement costs and regular maintenance contracts, XiPay On- demand lowers the total cost of ownership (TCO) with an inclusive monthly service fee and reduced installation costs. Support for Complex Payment Management Paymetric supports the complex and dynamic nature of enterprise payment environments by shouldering the burden of on-going maintenance, including: semi-annual association releases, processor certifications and new payment types or currencies. Accelerate Time to Cash XiPay On-demand allows companies to accept payment for products delivered or services rendered today. With XiPay On-demand, it’s no longer necessary for companies to take on the risk of extending payment terms to customers. Accepting electronic payments accelerates time to working capital, giving businesses a competitive advantage over rival companies with less significant cash positions. Reduced Scope and Financial Burden of Achieving PCI DSS Compliance XiSecure®, Paymetric’s proprietary credit card tokenization solution, radically improves data security while reducing the scope and financial burden of achieving PCI DSS compliance. Merchants no longer store credit card numbers interally, yet can continue to conduct business as usual with tokens that span the entirety of the customer relationship. With no credit card data to be compromised, merchants mitigate the risk of a credit card security breach.
- 13. About Paymetric Paymetric, Inc. is the standard in secure, integrated payments. Our innovative payment acceptance solutions expedite and secure the order-to-cash process, improve ePayment acceptance rates, and reduce the scope and financial burden of PCI compliance. Leading global brands rely on Paymetric for the only fully integrated, processor- agnostic tokenization solution, supported by dedicated customer service. Paymetric is a nationally award-winning industry leader recognized for continual innovation, SAP partnership and world-class support since 1998. For more information, visit paymetric.com. 1225 Northmeadow Pkwy | Suite 110 Roswell, GA 30076 T: 678.242.5281 | F: 866.224.5867 paymetric.com ©2014 Paymetric, Inc. All rights reserved. The names of third parties and their products referred to herein may be trademarks or registered trademarks of such third parties. All information provided herein is provided “AS-IS” without any warranty.