How to Optimize Payment Card Acceptance in SAP :
Innovative Payment Card Solutions How to Optimize Payment Card Acceptance in SAP®: A planning and implementation guide for on-demand ePayment integration © 2008 Paymetric, Inc. All rights reserved. How to Optimize Payment Card Acceptance in SAP®: A planning and implementation guide for on-demand ePayment integration Increasingly, organizations that utilize Contents Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 SAP are exploring electronic payment Why Process Payment Card Transactions in SAP? .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 acceptance as a vital component of What You Need to Know Before You Start .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Develop a Solution In-house or Utilize On-demand Software .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . methods offer clear advantages over 9 10 10 savings, accepting payment cards can .. . . . . . . . . . . Configuring Functionality Built into SAP .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processing Business Logic in SAP ERP.. . . . . . Processing Limitations in SAP ERP. . . . . . . . . . . . . . . . Configuration Tips and Tricks in SAP ERP.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enhanced Reporting Techniques. . . . . . . . . . . . . . . . . . . . . Technical Advantages of On-demand Services.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Enhanced Functionality Integrated Directly into FI.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Learn More .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . © 2008 Paymetric, Inc. All rights reserved. manual, paper-intensive processing methods. Beyond substantial labor free up valuable working capital by reducing Days of Sales Outstanding 11 13 Enhanced and Automated Reporting Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . payment via payment cards and other 6 6 8 Verify Your SAP Functionality .. . . . . . . . . . . . . . . . . . . . . . . . . . . . Understand the Transaction Process 5 their financial supply chain. Electronic (DSO) and decreasing exposure to accounts receivable risk. 14 19 3. How to Optimize Payment Card Acceptance in SAP® Executive Summary Before implementing payment card processing in an SAP product, 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’s products provide basic payment card processing capabilities, ensuring functional continuity and transaction efficiency between multiple SAP components and financial institutions is a far more complex challenge than many may realize. 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 XiPayNet(TM), Paymetric’s ePayment Integration Service, for Cross Application Payment Card Interface (CA¬PCI) integration as well as Enterprise Service Integration, SAP has confirmed the viability of these options. 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 a Paymetric’s software-as-a-service (SaaS) based payment service to maximize the operational and financial payback from payment card transaction processing. Why Process Payment Card Transactions in SAP? Increasingly, organizations that utilize SAP are exploring electronic payment acceptance as a vital component of their financial supply chain. Electronic payment via payment cards and other methods offer 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. Payment cards provide real-time transaction authorization with an immediate payment guarantee from the card’s issuing bank, effectively transferring transactional and credit risk to the issuing bank and away from you, the merchant. Automatic payment authorization via payment card also provides an effective control to ensure that shipment of goods is based on a legitimate, secure, and timely payment. Cost reductions from receiving “pre-payment” via payment card versus paper invoicing, for example, can easily add to savings of more than $12.00 per invoice. For a large SAP organization with $500 million in sales, these and other savings can quickly add up to more than $1 million per year. (See example in Appendix A). © 2008 Paymetric, Inc. All rights reserved. Accepting payment cards improves cash flow by dramatically speeding the settlement deposit process- from 30 to 90 days or more for paper-based transactions to a matter of 24 to 72 hours for payment card transactions. 4. What You Need to Know Before You Start Before implementing payment card 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’s products provides basic payment card processing capabilities, ensuring functional continuity and transaction efficiency between multiple SAP components and financial institutions is a far more complex challenge than many may realize. Particularly in North America, payment card transaction processing requires managed access to the financial networks positioned between the supplier and the buyer. (See Figure 1) Most major financial institutions have a proprietary processing network associated with their payment card operations. Processing network examples include First Data Merchant Services (FDMS) servicing Chase, Wells Fargo, Fleet and Commerce Bank; Paymentech servicing BankOne; and Vital Processing Services servicing Bank of America. With B2B commerce customers now demanding fast, flexible and secure payment options as part of a complete business relationship, analysts now project that more than half of all business-tobusiness transactions will be electronic by 2009. 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 running SAP systems today have received their “marching orders” to plan and implement payment card processing. Financial Supply Chain: Payment Card Overview Figure 1 SAP’s products provide basic payment card processing functionality, but does not provide an interface or direct connection between various SAP products and the payment card processing networks. Supplier 5WWYdhgdUmaYbhZfca 6imYfj]UdUmaYbhWUfX IgYg. © 2008 Paymetric, Inc. All rights reserved. Payment Chain Gap Processor or Clearinghouse Dfcj]XYghfUbgUWh]cbg Uih\cf]nUh]cbUbX gYȜ`YaYbhgYfj]WYg Banks and Financial Institutions Issuing Bank:gYbXg dUmaYbhhch\Ygidd`]YfÈg aYfW\UbhVUb_ Merchant Bank:fYWY]jYg dUmaYbhZfcah\YVimYfÈg ]ggi]b[VUb_ 5. How to Optimize Payment Card Acceptance in SAP® Develop a Solution In-house or Utilize On-demand Service The challenge, therefore, is to extend the functionality of SAP systems to integrate payment card transaction processing with SAP-enabled data and workflows. Your organization has made a substantial investment in its SAP system and expects to extend that investment to enable an efficient payment card process. Because SAP’S products do not offer direct processing network connections, the necessary interface between your organization and the payment card processing network or clearinghouse must either be developed in-house or an on-demand service must be leveraged. Developing and maintaining a custom, in-house interface between SAP’s products and the processing networks (defined by SAP as the Cross Application Payment Card Interface or CA-PCI) typically requires a substantial commitment in 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 with each proprietary processing network. The advantages of leveraging an on-demand service become more evident as one gains a clearer understanding of the native functionality and limitations of connecting to processing networks with SAP’s products. Details of the advantages provided by the Paymetric SaaS solution are described toward the end of this paper. Verify Your SAP Functionality Payment card functionality is found in SAP R/3 from release 4.0A and above, including the latest SAP ERP release. In addition, all releases of SAP products such as SAP BusinessSuite, SAP CRM, SAP Business ByDesign, and SAP BusinessOne incorporate payment card processing functionality. In SAP R/3, payment card functionality is integrated with both the Sales and Distribution (SD) and Financial (Fl) modules. While payment card functionality is shared equally between the SD and Fl modules, the required configuration work takes place mostly in the SD module (80%) versus the Fl module (20%). Configuration in the SD and Fl modules allows you to choose the card types to be accepted, specify the order and invoice types that allow payment cards, and identify customers that may be restricted from payment card use. © 2008 Paymetric, Inc. All rights reserved. 6. Paymetric Provides Interface Between SAP and Processors / Clearinghouses Figure 2 On-demand payment processing services from Paymetric offer an attractive alternative for those who want to avoid an additional burden on in-house resources, accelerate time-to-value, and ensure continuous compliance with industry best practices. By certifying Paymetric solutions for CA-PCI and Enterprise Services integration, SAP has confirmed the viability of this option. Supplier 5WWYdhgdUmaYbhZfca 6imYfj]UdUmaYbhWUfX IgYg. Processor or Clearinghouse Dfcj]XYghfUbgUWh]cbg Uih\cf]nUh]cbUbX gYȜ`YaYbhgYfj]WYg Banks and Financial Institutions Issuing Bank:gYbXg dUmaYbhhch\Ygidd`]YfÈg aYfW\UbhVUb_ Merchant Bank:fYWY]jYg dUmaYbhZfcah\YVimYfÈg ]ggi]b[VUb_ In addition, the connection from SAP’s products to a network processor or clearinghouse requires either an Internet gateway or frame relay connection. To address some, but not all, security and privacy regulations and policies, SAP introduced encryption for payment card numbers in R/3 (see OSS note 7666703) that is available in releases 4.6C and higher. Please check SAP’s online support for the latest updates. The SAP CRM product also includes encryption functionality. Third-party service providers, including Paymetric, also include payment card number encryption for SAP customers on releases not containing the new SAP encryption functionality. Paymetric’s service provides a solution which tokenizes the card number and stores the encrypted data in a secure, centralized data vault. Encryption capability is essential for securing payment card transactions and protecting payment card numbers from theft or misuse by unauthorized personnel. © 2008 Paymetric, Inc. All rights reserved. 7. How to Optimize Payment Card Acceptance in SAP® Understand the Transaction Process In SAP’s products, payment card transaction processing is basically a two-step process. The first step, payment “authorization”, occurs in real-time during sales order save. The second step, payment “settlement”, occurs as a batch job after invoicing, or can it be executed manually at any time, if desired. Figure 3 Understand the Transaction Process In SAP’s products, payment card transaction processing is basically a two-step process. The first step, payment “authorization”, occurs in real-time during sales order save. The second step, payment “settlement”, occurs as a batch job after invoicing, or it can be executed manually at any time, if desired. FYeiYgh[ccXgUbX gYfj]WYg Dfcj]XYgWUfXXUhU FYWY]jYgWUfXXUhU FYeiYghgUih\cf]nUh]cb Xif]b[cfXYfgUjY 6imYf Gidd`]Yf 7 6 FYWY]jYg[ccXUbX gYfj]WYg]ZUddfcjYX 5ddfcjYgcfXYfcf d`UWYgcbWfYX]h\c`X GYbXgUih\cf]nUh]cb fYeiYghhc]ggi]b[VUb_ DfcWYggcf GYbXgUih\cf]nUh]cb fYgdcbgYhcgidd`]Yf =ggi]b[6Ub_ FYgdcbXgk]h\ Uih\cf]nUh]cbUddfcjYX cfXYb]YX As shown in Figure 3, a customer requests goods or services from your organization, the supplier. Upon collecting the customer’s payment card data for payment, the supplier sends an authorization request to the credit card issuing bank. The issuing bank responds to the authorization request with acceptance or denial through its designated processing network or clearinghouse. The clearinghouse then provides authorization information to the supplier, which can then approve the order and ship the goods to the customer. © 2008 Paymetric, Inc. All rights reserved. 8. 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. 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 in SAP’s products. Settlement clears all open items in the Credit Card receivable account into a single open item in 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 Credit Card Authorization Process in SAP’s Products The settlement process, as illustrated in Figure 4, typically occurs in batch only after billing or invoicing of the payment card payment. Transactions are sent by the supplier to the network processor or clearinghouse, which then communicates with the issuing bank. The issuing bank then transfers funds to the supplier’s bank. The supplier’s bank receives the funds and then notifies the supplier of funds deposited. The supplier then reconciles the deposits in SAP’s products. HfUbga]hgVUhW\Zcf gYȜ`YaYbh 6imYf FYWY]jYgZibXgXYdcg]h bch]ÑWUh]cb AUbiU``mfYWcbW]`Yg ]bG5D © 2008 Paymetric, Inc. All rights reserved. DfcWYggYgVUhW\ GYbXgdUmaYbh]bghfiWh]cbg hcVch\VUb_g Gidd`]Yf HfUbgZYfgZibXhc aYfW\UbhVUb_ IdXUhYgWUfX\c`XYf ghUhYaYbh DfcWYggcf =ggi]b[6Ub_ 8Ydcg]hgZibX]b gidd`]YfÈgUWWcibh 9. How to Optimize Payment Card Acceptance in SAP® Processing Business Logic in SAP ERP SAP R/3 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. Its important to understand the functionality, business logic and limitations of these processes when planning payment card transaction processing and management. During the authorization phase, standard SAP ERP payment card business logic, for example, features card verification functionality you would expect for processing payment cards. This includes standard Luhn checks to validate card numbers at the time of card number entry. SAP ERP will also warn if expiration dates entered have lapsed. In addition, SAP ERP can capture Card Verification Value (CVV) or Card Identification Number (CID) values, assuming you have applied the appropriate OSS notes or upgraded to an appropriate support package. Also note that transaction authorization occurs only at “sales order save,” and is embedded in SAP’s SD’s credit checking functionality. Once the order is saved, SAP processes an authorization response from the clearinghouse which may be one of the following types: Approval, Communication Error, a “Soft Decline” (whereby future automatic authorization attempts are not blocked), and a “Hard Decline” (where future, automatic authorization attempts are blocked). Additional information in the response includes an Address Verification System (AVS) response code and a Card Verification Value (CVV) response code, however there is no standard SAP business logic for the AVS and CVV response codes. This approach offers significant benefits over traditional database encryption. First, unencrypted payment data is removed from the SAP application and database at all times, which boosts security. Second, cryptographic processing is completely removed from the SAP servers, which enhances application and database performance. Processing Limitations in SAP ERP While SAP ERP offers substantial payment card functionality, some functions are not configurable. At “sales order save,” for example, SAP ERP 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, VCC1. The credit hold will be released if authorization occurs at a later time or if payment card details are deleted from the order. Insufficient authorization on a sales order will also put deliveries that originated with this order on credit hold. An authorization must be obtained on the sales order to execute Post Goods Issue (PGI) for a subsequent delivery. Insufficient authorization at invoice creation will block the invoice from posting to accounting. (Blocked invoices are listed by transaction VFX3). Invoice posting to accounting will only happen once sufficient authorization is obtained on the sales order. © 2008 Paymetric, Inc. All rights reserved. 10. Common Misconceptions About Payment Card Processing in SAP ERP In planning the implementation of payment card processing in SAP, consider these common misconceptions so you can avoid being surprised. • SAP Can Do It All SAP does not provide interfaces directly to clearinghouses. You will need purchase middleware or connect to an on-demand service to interface with a payment card clearinghouse. • IVs Easy to Build Our Own Clearinghouse Interface Building your own interface can require weeks or months of effort at considerable cost. See example of costs in Appendix A. • Authorization is Automatic You can’t perform payment card authorization until the product is confirmed as shippable within X number of days. • Settlement is Automatic You can’t request a settlement deposit until an order has been invoiced and posted to accounting. Authorizations are considered “consumed” once any portion is used to post an invoice to accounting. In business-to-business transactions, there can be a lag of several days between order entry and delivery. Obtaining additional authorizations to fulfill an order when an authorization “expires” can require substantial manual effort, negatively impacting the operating efficiency of customer service and order management. 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 receivable account entries are posted on an accounting document is settlement submission possible. Configuration Tips and Tricks in SAP ERP To help reduce your Days of Sales Outstanding when accepting payment card payments, there are configuration “tips and tricks” that can smooth processing. These tips and tricks can help you manage the “quirks” of the payment card processing functionality more efficiently. © 2008 Paymetric, Inc. All rights reserved. 11. How to Optimize Payment Card Acceptance in SAP® SAP ERP includes an “Authorization Horizon” configuration setting that specifies a shipment confirmation window. Items ordered must be confirmed for shipment within ‘X’ number of days or those items cannot be authorized until they are confirmed for shipment within this Authorization Horizon. To prevent the customer’s credit limit from being tied up unnecessarily for long periods of time, it is best to limit the Authorization Horizon to as few days as possible. 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 were 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 a sales order. You can define authorization validity periods for each type of credit card accepted. Authorization validity periods for MasterCard, American Express and Discover cards, for example, are typically 28 or 30 days. For VISA cards, the authorization validity period is set by the various banks issuing VISA cards and can be as few as seven days. In addition, many sales 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 invoices being blocked from accounting because of insufficient authorization and will reduce confusion and disputes that may occur when multiple charges are applied to a single invoice, (e.g. One charge for the goods order and one charge for freight to ship the order). “Buffering” is usually performed in the AUTHORIZATION_VALUE_SPLIT userxit in program MV45AFZH. By defining your authorization horizon to within three days 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. SAP “userexits” perform several functions that allow you to predict delivery splits in an order and obtain an authorization for each order, or insert an authorization “buffer” amount to compensate for order value fluctuations such as the addition of freight charges. Other “userexit” enhancements include preventing accidental credit release of credit card holds from VKMx transactions, copying payment card details by reference, and enabling cancellation of invoices with payment card data to allow for proper rebilling. It’s important to recognize that while you can utilize userexits in native SAP, SAP payment processing experts such as Paymetric have already done this coding work, giving you the desired functionality while saving time and effort. © 2008 Paymetric, Inc. All rights reserved. 12. Enhanced Reporting Techniques Native SAP ERP 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 your own reports using data stored in standard SAP ERP tables to show Payment Card Transaction Data in SD (FPLTC), Payment Card Transaction Data in Fl (BSEGC), and Credit Card Customer Master information (VCNUM & VCKUN). While all of these “tips and tricks” can help you improve management of payment card transactions in SAP ERP, many organizations today elect to leverage on-demand services in order to reduce complexity, accelerate payment card implementation, lower IT development and administrative costs, and ensure continuous compliance with industry requirements. Technical Advantages of On-demand Services Since 1998, Paymetric has applied industry best practices to combine intelligent transaction processing with SAP-Certified Integration for streamlined payment card implementation and ongoing operations. Serving more than 100 SAP customers-including many Global 2000 organizationsPaymetric solutions address configuration and processing limitations in SAP’s products to deliver enhanced payment card functionality, configuration, and reporting. With Paymetric’s on-demand service, your organization can compress implementation of an SAP-to-clearinghouse payment card interface from multiple months down to two weeks or less. Paymetric can save your organization 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 for process management and implementation testing. Paymetric’s on-demand service offers plug-in integration to more than a dozen of the most commonly used clearinghouse interfaces, so you won’t have to “re-code” your interface if a clearinghouse vendor changes or if a merger or acquisition requires the addition of a new processor connection. Paymetric also provides the capability to extend the payment card functionality in SAP ERP with automated batch settlement, more efficient payment processing, encrypted payment card data, and real-time payment card authorization. Paymetric’s on-demand service interface is so well integrated that it is an indistinguishable part of SAP ERP screens, enabling you to avoid extensive training or business process modification. © 2008 Paymetric, Inc. All rights reserved. 13. How to Optimize Payment Card Acceptance in SAP® Paymetric’s On-Demand Service Provides a Fully Integrated Payment Card Solution Figure 5 LEGACY ERP ADAPTERS ePayment Integration Service CARTRIDGES Card Processor/Bank Payment Origination Systems Based on a modular, open architecture engineered for efficient enterprise integration, Paymetric provides the flexibility to rapidly accommodate the most current payment card methods. WEB STORE Enhanced Functionality Integrated Directly into FI While SAP’s Biller Direct product includes customer self-service functionality for Electronic Bill Presentment and Payment (EBPP) and Electronic Invoicing Presentment and Payment (EIPP) over a web-based connection, this functionality is not available in standard Fl for direct clearing of an open item with a payment card payment.Paymetric also provides the capability to extend the payment card functionality in SAP ERP with automated batch settlement, more efficient payment processing, encrypted payment card data, and real-time payment card authorization. Paymetric’s on-demand service interface is so well integrated that it is an indistinguishable part of SAP ERP screens, enabling you to avoid extensive training or business process modification. SAP Reports Provided by XiPay Include: • S ettlement 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 assist in prioritizing shipments and billings. • Location of SAP documents according to a specific payment card number. © 2008 Paymetric, Inc. All rights reserved. 14 . Enhanced and Automated Reporting Capabilities Paymetric’s reporting and analytics features include enhanced reporting through pre-coded SAP extensions, saving your IT staff days or weeks of work in custom coding effort. Paymetric also features enhanced reporting for the Settlement Submission and Resubmission program, as well as enhanced reporting for FBRC programs to quickly locate transactions that must be reversed due to a customer “chargeback.” Appendix A: Payback Example Using Paymetric’s On-Demand Service Paymetric Payback Scenario The example shown here displays the cost savings of implementing payment card processing with Paymetric’s on-demand service. This example is based on a hypothetical company with $500 million in sales, accepting approximately 20 percent of its revenue from payment cards. The summary box at the end shows nearly $1 million in hard-dollar savings plus a $250,000 increase in revenue. Basic Customer Information Customer Annual Revenue $ 500,000,000 Customer Avg Daily Revenue $ 1,369,863 Customer Cost of Capital 8% Annual Sales Transaction Volume 900,000 Annual Payment Card Transaction Volume 450,000 Annual Transaction Value $ 100,000,000 Percent of Revenue via Payment Cards 20.0% DSO - Reduce A/R Capital Costs Before Paymetric: Percent of Revenue via A/R 50% Amount of Revenue via A/R $ 250,000,000 Days of Sales Outstanding (DSO) 58 Avg DSO Amount $ 40,000,000 Annual Cost of DSO $ 3,200,000 After Paymetric: Percent of Revenue via A/R 45% Amount of Revenue via A/R $ 225,000,000 Avg DSO Amount $ 36,000,000 Annual Cost of DSO $ 2,880,000 Annual Savings $ 320,000 © 2008 Paymetric, Inc. All rights reserved. 15. How to Optimize Payment Card Acceptance in SAP® Appendix A: Payback Example Using Paymetric’s On-Demand Service (cont’d) Reduce Transaction Costs Before Paymetric: Average Transaction Percent Fee 2.7% Transaction Processing Expense $ 2,739,000 After Paymetric: Average Transaction Percent Fee 2.1% Transaction Processing Expense $ 2,645,625 Annual Savings $ 93,375 Reduce Bad Debts Before Paymetric: Annual Receivables Amount $ 250,000,000 Avg. Receivables Writeoff Percent 1.0% Annual Receivables Writeoff Amount $ 2,500,000 After Paymetric: Annual Receivables Amount $ 225,000,000 Avg. Receivables Writeoff Percent 1.0% Annual Receivables Writeoff Amount $ 2,250,000 Annual Savings $ 250,000 Improve Productivity Before Paymetric: Total number of labor hours 52,000 Avg cost per hour $ 21.92 Total labor cost $ 1,139, 840 After Paymetric: Total number of labor hours 40,000 Avg cost per hour $ 21.92 Total labor cost $ 876,800 Annual Savings $ 263,040 © 2008 Paymetric, Inc. All rights reserved. 16. Appendix A: Payback Example Using Paymetric’s On-Demand Service (cont’d) Increase Revenue Before Paymetric: Total Number of Sales Transactions 900,000 Avg Value per Transaction $ 556 % Transact Cancelled Due to Payment Method 0.10% # of Transact Cancelled Due to Payment Method 900 Value of Transact Cancelled Due to Payment Method $ 500,000 After Paymetric: % Transact Cancelled Due to Payment Method 0.05% # of Sales Transactions Saved 450 Value of Transactions saved by Paymetric Solution $ 250,000 Annual Additional Revenue $ 250,000 Paymetric Payback Summary Reduce A/R Capital Costs $ 320,000 Reduce Transaction Costs $ 93,375 Reduce Bad Debts $ 250,000 Improve Productivity $ 263,040 Increase Revenue $ 250,000 Total Annual Benefit $1,176,415 Appendix B - Terminology Acquirer: A bank or company that acquires data relating to transactions from a merchant (supplier) for processing. Acquiring Bank: Also known as a merchant bank. A bank that receives the credit card transactions and then settles with the issuing banks. Bank that signs up / enables the merchant to process transactions. Authorization: The act of insuring that the cardholder has adequate funds available against their line of credit. A positive authorization results in an authorization code being generated, and those funds being set aside. The cardholder’s available credit limit is reduced by the authorized amount. Authorization Code: A code that an issuer or its authorizing processor provides to indicate approval or denial for an authorization request. © 2008 Paymetric, Inc. All rights reserved. 17. How to Optimize Payment Card Acceptance in SAP® Appendix B - Terminology (cont’d) Authorization Only: A transaction created to reserve an amount against a credit card’s available limit for intended purchases; the settlement may occur within three to five days, depending on the card type. Bank Identification Number (BIN): The first six digits of a Visa or MasterCard account number. This number is used to identify the card issuing institution. Card Issuer: Any association member financial institution, bank, credit union, or company that issues, or causes to be issued, plastic cards to cardholders. Commercial Card: A general name for cards typically issued for business use and may include Corporate Cards, Purchase Cards, Business Cards, Travel and Entertainment Cards. Credit Card Processor: A company that performs authorization and settlement of credit card payments, usually handling several types of credit and payment cards (such as Visa, MasterCard, and American Express). FBRC: The SAP Fl transaction code to Reset Cleared Items for Payment Cards. Interchange: The exchange of information, transaction data and money among banks. Interchange systems are managed by card associations such as Visa and MasterCard according to their requirements. Interchange Fee: A fee paid by the acquiring banWmerchant bank to the issuing bank. The fee compensates the issuer for the time after settlement with the acquiring banWmerchant bank and before it recoups the settlement value from the cardholder Issuing Bank (Issuer): Any association member financial institution, bank, credit union, or company that issues, or causes to be issued, plastic cards to cardholders. Level 3: Also known as Level III, Level 3, or Level-IIIILine-item detail is a data specification designed to support business-to-business and business-to-government credit card use. Level-3 line item detail provides specific purchase information such as Item Description, Quantity, Unit of Measure, Price, and more. This information is very useful to cardholding organizations to help streamline accounting and business practices and to merge payment data with electronic procurement systems. Luhn Check: Credit Card numbers are usually 13 to 16 digit numbers that are protected by a special numerical check, called Luhn check. Each digit is multiplied by the alternating factors 2 and 1 (last digit is always multiplied by 1). The digits of each calculation result are summed together. Finally, to be a valid Credit Card number, the total must be divisible by 10. Merchant (or supplier): An entity that contracts with merchant banks or Independent Sales Organizations to originate transactions. © 2008 Paymetric, Inc. All rights reserved. 18. Appendix B - Terminology (cont’d) Merchant Bank: Bank that has a merchant agreement with a merchant (supplier) to accept (acquire) deposits generated by bankcard transactions. Settlement: The reporting of settlement amounts owed by one member to another, or to a card issuing concern, as a result of clearing. Settlement Bank: A bank, including a correspondent or intermediary bank, that is both located in the country where a member’s settlement currency is the local currency, and authorized to execute settlement of interchange on behalf of the member or the member’s bank. Learn More To learn more about how Paymetric can help you reduce your days of sales outstanding, streamline processing operations, mitigate risk, and improve cash flow, visit our website at www.paymetric. com, email us at info@paymetric.com, or call 713.895.2000. Paymetric, Inc. Provides this document as is” without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. Some states do not allow disclaimers of express or implied warranties in certain transactions; therefore, this statement may not apply to you. This document and may not be lent, sold, or given away without the prior written permission of Paymetric, Inc., except as otherwise permitted by law. Except as expressly set forth in such license agreement or non-disclosure agreement, no part of this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of Paymetric, Inc. Some companies, names, and data in this document are used for illustration purposes and may not represent real companies, individuals, or data. This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of this document. Paymetric, Inc. May make improvements in or changes to the software described in this document at any time. © 2008 Paymetric, Inc. All rights reserved. 19. About Paymetric Paymetric, Inc. provides innovative software for managing, protecting, and integrating payment card transactions in enterprise systems, most notably SAP. The company combines proven expertise in ERP payment processes with powerful software and services to improve return on card acceptance, optimize purchasing card programs, and reduce barriers to compliance. To learn more about our innovative payment card solutions, visit: www.paymetric.com How to optimize payment card acceptance in SAP®/9-2008 Paymetric, Inc. / 13430 Northwest Freeway, Suite 900 / Houston, Texas 77040 / tel 713-895-2000 / fax 713-895-2001 / www.paymetric.com Copyright 2008 Paymetric, Inc. All rights reserved. Paymetric, XiPay, XiPay Extensions, XiPay Cartridges, XiBuy, XiSecure, and Paymetric Solutions are either registered trademarks, service marks, or trademarks of Paymetric, Inc. in the United States and/or other countries. SAP and mySAP are registered trademarks of SAP AG. All other trademarks appearing on this document are the property of their respective owners. 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.
© Copyright 2024