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 [email protected], 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.