PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP:

A T E C H N I C A L G U I D E T O P L A N N I N G A N D I M P L E M E N TAT I O N

Executive Summary 1 EXECUTIVE SUMMARY

............................................................................

Why Process Payment Card Transactions in SAP? 2 Increasingly, organizations that utilize SAP are
............................................................................ exploring payment card acceptance as a vital
What You Need to Know Before You Start 2 component of their financial supply chain. Electronic
............................................................................ payment via payment card offers clear advantages
Develop a Solution In-House or Implement over manual, paper-intensive processing methods.
Third-Party Software? 3
............................................................................ Beyond substantial labor savings, accepting
Verify Your SAP Functionality 4
payment cards can free up valuable working capital
............................................................................ by reducing Days of Sales Outstanding (DSO) and
Understand the Transaction Process 5 decreasing exposure to accounts receivable risk.
............................................................................
Before implementing payment card processing in
Configuring Functionality Built into SAP 6
............................................................................ SAP, technical professionals can reduce the risk of
Processing Business Logic in SAP 7
mid-project surprises by developing a solid
............................................................................ understanding of the overall payment card
Processing Limitations in SAP 7 processing environment and the specific
............................................................................ requirements involving SAP. While SAP provides
Configuration Tips & Tricks in SAP 8 basic payment card processing capabilities, ensuring
............................................................................
functional continuity and transaction efficiency
Enhanced Reporting Techniques 10 between multiple SAP components and financial
............................................................................
institutions is a far more complex challenge than
Technical Advantages of Third-Party Software 10
many may realize.
............................................................................

Enhanced Functionality Integrated Directly into FI 12
............................................................................
Enhanced & Automated Reporting Capabilities 12
............................................................................
Appendix A - Payback Example Using XiPay 13
............................................................................
Appendix B - Terminology 16
............................................................................
Learn More 17
Purchasing third-party software 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 for CA-
PCI integration, SAP has confirmed the viability of
this option.
This white paper explains in detail how to best plan
and implement payment card processing in SAP. It
highlights the benefits of utilizing a third-party
software provider such as Paymetric to maximize the
operational and financial payback from payment card
transaction processing.

Paymetric, Inc.
13430 Northwest Freeway, Suite 900
Houston, TX 77040
Phone: 713.895.2000 Fax: 713.895.2001
www.paymetric.com
 WHY PROCESS PAYMENT CARD TRANSACTIONS IN SAP?
Increasingly, organizations that utilize SAP are exploring payment card acceptance as a vital component
of their financial supply chain. Electronic payment via payment card offers 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 supplier. 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.

Accepting payment cards improves cash flow by dramatically

speeding the settlement deposit process— from 30 to 90 days
or more for paper-bb ased transactions to a matter of 24 to 72
hours for payment card transactions.

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).

WHAT YOU NEED TO KNOW BEFORE YOU START

Before implementing payment card processing in SAP, 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. While SAP 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.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 2

With B2B commerce customers now demanding fast, FIGURE 1
flexible and secure payment options as part of a complete Financial Supply Chain:
Payment Card Overview
business relationship, analysts now project that more than
half of all business-to-business transactions will be SAP provides basic payment
electronic by 2009. card processing functionality,
but does not provide an
Given the potential labor savings and accelerated cash flow
interface or direct connection
obtained by integrating payment cards into the financial between various SAP products
supply chain, it is not surprising that many IT departments and the payment card
running SAP systems today have received their "marching processing networks.
orders" to plan and implement payment card processing.

O Issuing Bank:
O Accepts payment
O Provides sends payment to
from Buyer via the supplier’s
transaction
payment card merchant bank
authorization &
settlement services O Merchant Bank:
O Uses: receives payment from
the buyer’s issuing bank

DEVELOP A SOLUTION IN-H

HOUSE OR IMPLEMENT THIRD-P
PARTY SOFTWARE?
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 does not offer direct processing network connections, the necessary
"middleware" interface between your organization and the payment card processing network or
clearinghouse must either be developed in-house or acquired through a third-party vendor.

Developing and maintaining a custom, in-house interface between SAP 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 deploying a third-party solution become more evident as one gains a clearer
understanding of the native functionality and limitations of connecting to processing networks with SAP.
Details of the advantages provided by the XiPay solution are described toward the end of this paper.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 3

VERIFY YOUR SAP FUNCTIONALITY
Payment card functionality is found in SAP R/3 from release 4.0A and above, including the latest mySAP
ERP release. In addition, all releases of SAP products such as CRM, Internet Sales, and Biller Direct
incorporate payment card functionality.

In SAP R/3, payment card functionality is integrated with both the Sales and Distribution (SD) and
Financial (FI) modules. While payment card functionality is shared equally between the SD and FI
modules, the required configuration work takes place mostly in the SD module (80%) versus the FI
module (20%). Configuration in the SD and FI 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.

O Accepts payment O Issuing Bank:

O Provides sends payment to
from Buyer via
transaction the supplier’s
payment card
authorization & merchant bank
settlement services O Merchant Bank:
O Uses: receives payment from
the buyer’s issuing bank

In addition, the connection from SAP to a network FIGURE 2

processor or clearinghouse requires either an Internet XiPay Provides Interface

gateway or frame relay connection. Between SAP and
Processors /
To meet current security and privacy regulations and Clearinghouses
policies, SAP has recently introduced encryption for
payment card numbers in R/3 (see OSS note 7666703) that Purchasing third-party
is available in releases 4.6C Support Package 46 and higher middleware such as XiPay
and 4.70 Support Package 22 and higher. from Paymetric offers an
attractive alternative for
The CRM module for SAP also includes encryption those who want to avoid an
functionality. Third-party vendors such as Paymetric, for additional burden on in-house
example, also include payment card number encryption for resources, accelerate time-to-
SAP customers on releases not containing the new SAP value, and ensure continuous
functionality that relies on secure external functionality. compliance with industry best
Encryption capability is essential for securing payment card practices. By certifying XiPay
transactions and protecting payment card numbers from for CA-PCI integration, SAP
theft or misuse by unauthorized personnel. has confirmed the viability
of this option.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 4

As shown in Figure 3, a customer requests goods or FIGURE 3
services from your organization, the supplier. Upon Understand the
collecting the customer's payment card data for payment, Transaction Process
the supplier sends an authorization request to the credit
In SAP, payment card transaction
card issuing bank.
processing is basically a two-step
The issuing bank responds to the authorization request process. The first step, payment
with acceptance or denial through its designated "authorization", occurs in real-time
processing network or clearinghouse. The clearinghouse during sales order save. The second
then provides authorization information to the supplier, step, payment "settlement", occurs
which can then approve the order and ship the goods to as a batch job after invoicing, or it
the customer. can be executed manually at any
time, if desired.

O Requests goods O Receives card O Sends

& services data authorization
O Requests request to
O Provides card
authorization issuing bank
data during order save

O Receives goods O Approves order O Sends O Responds with

& services if or places on authorization authorization
approved credit hold response to approved or
supplier denied

UNDERSTAND THE TRANSACTION PROCESS

In SAP, 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.

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.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 5

CONFIGURING FUNCTIONALITY BUILT INTO SAP FIGURE 4
Credit Card Authorization
It's important to note several distinctions in configuring SAP
Process in SAP
functionality for both the Authorization and Settlement
processes. The settlement process, as illustrated
in Figure 4, typically occurs in batch
First, the customer's Accounts Receivable account is
only after billing or invoicing of the
cleared of any liability once the invoice is posted to
payment card payment. Transactions
accounting. Liability is then posted to a "Credit Card"
are sent by the supplier to the
clearing account, essentially transferring the liability to the
network processor or clearinghouse,
financial institution that issued the payment card. As these
which then communicates with the
transactions accumulate in the Credit Card clearing
issuing bank. The issuing bank then
account, they become eligible for subsequent batch
transfers funds to the supplier's bank.
processing.
The supplier's bank receives the
Second, settlement deposits for payment card payments funds and then notifies the supplier of
must be manually reconciled in SAP. Settlement clears all funds deposited. The supplier then
open items in the Credit Card clearing account into a single reconciles the deposits in SAP.
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.

O Processes batch O Transfers funds

O Transmits batch to merchant bank
for settlement O Sends payment O Updates
instructions to cardholder
both banks statement

O Receives funds
deposit O Deposits fund in
notification supplier’s
O Manually account
reconciles in SAP

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 6

PROCESSING BUSINESS LOGIC IN SAP
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. It's 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 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 will also
warn if expiration dates entered have lapsed. In addition,
SAP can capture Card Verification Value (CVV) or Card
Identification Number (CID) values, assuming you have
applied the appropriate OSS notes. Also note that
transaction authorization occurs only at "order save," and is
embedded in SAP'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.

PROCESSING LIMITATIONS IN SAP

While SAP offers substantial payment card functionality, some functions are not configurable. At "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 in a new 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) 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 authorization
is obtained on the sales order.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 7

Authorizations are considered "consumed" once any Common Misconceptions About
portion is used to post an invoice to accounting. In Payment Card Processing in SAP
business-to-business transactions, there can be a lag of
In planning the implementation of
several days between order entry and delivery. Obtaining
payment card processing in SAP,
additional authorizations to fulfill an order when an
consider these common
authorization "expires" can require substantial manual effort,
misconceptions so you can avoid
negatively impacting the operating efficiency of customer
being surprised.
service and order management.
z SAP Can Do It All
Accounting postings in SAP also vary from standard
SAP does not possess native
invoicing methods when accepting payment card
functionality to process payment
payments. As noted earlier, posting an order to accounting
cards. You will need to build or
clears the customer's liability and posts it to the Credit Card
purchase middleware to interface
clearing account. This effectively transfers the liability to the
with a payment card
card's issuing bank rather than the customer's account.
clearinghouse.
Only when the Credit Card clearing account entries are
posted on an accounting document is settlement possible. z It's Easy to Build Our Own
Clearinghouse Interface
Building your own interface can
CONFIGURATION TIPS AND TRICKS IN SAP require weeks or months of effort
To help reduce your Days of Sales Outstanding when at considerable cost. See
accepting payment card payments, there are SAP example of costs in Appendix A.
configuration "tips and tricks" that can smooth processing. z Authorization is Automatic
These tips and tricks can help you manage the "quirks" of You can't perform payment card
the payment card processing functionality more efficiently. authorization until the product is
SAP includes an "Authorization Horizon" configuration confirmed as shippable within X
setting that specifies a shipment confirmation window. number of days.
Items ordered must be confirmed for shipment within 'X' z Settlement is Automatic
number of days or those items cannot be authorized until You can't request a settlement
they are confirmed for shipment within this Authorization deposit until an order has been
Horizon. To prevent the customer's credit from being tied invoiced and posted to financial
up unnecessarily for long periods of time, it is best to limit ledger.
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
unnecessarily if authorization were obtained at initial order
entry time.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 8

Once an authorization is obtained, a configurable
"Authorization Validity Period" determines how many days
the authorization is considered valid in SAP 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.

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.

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).

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.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 9

It's important to recognize that while you can utilize userexits in native SAP,
third-pp arty providers such as Paymetric have already done this coding work,
giving you the desired functionality while saving time and effort.

ENHANCED REPORTING TECHNIQUES

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 your own
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 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, many
organizations today elect to purchase bolt-on solutions 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 THIRD-P

PARTY SOFTWARE
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 organizations–Paymetric solutions
address configuration and processing limitations in SAP to deliver enhanced payment card functionality,
configuration, and reporting.

With XiPay, your organization can compress implementation of an SAP-to-clearinghouse payment card
interface from multiple months down to two weeks or less. XiPay 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.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 10

XiPay Cartridges provide plug-in integration for 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.

XiPay offers you the capability to extend the payment card functionality in SAP with automated batch
settlement, more efficient payment processing, encrypted payment card data, and real-time payment
card authorization. XiPay's interface is so well integrated that it appears as an indistiguishable part of SAP
screens, enabling you to avoid extensive training or business process modification.

Custom & Legacy

SAP
Extensions

Internet
Frame Relay

Web Servers

Extend SAP Modular Enterprise Intelligent Transaction Modular Banking

Capabilities Integration Processing Engine Connections

FIGURE 5 XiPay Provides a Fully Integrated Payment Card Solution

Based on a modular, open architecture engineered for efficient enterprise integration,

XiPay from Paymetric provides the flexibility to rapidly accommodate the most
current payment card methods.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 11

ENHANCED FUNCTIONALITY INTEGRATED SAP Reports Provided by
DIRECTLY INTO FI XiPay Include:
While SAP's Biller Direct product includes customer self- z Settlement batch items reported
service functionality for Electronic Bill Presentment and by batch number with debit and
Payment (EBPP) and Electronic Invoicing Presentment and credit subtotals to assist with
Payment (EIPP) over a web-based connection, this the reconciliation of deposits.
functionality is not available in standard FI for direct clearing
of an open item with a payment card payment. z Settlement batch items reported
across batches by date range
XiPay fully supports the clearing of open accounts receivable with debit and credit subtotals.
items directly in FI. This capability enables your customer
service representatives (CSRs) to interact with your z Identification of expiring
customers and easily clear open A/R items on orders authorizations to assist in
already placed or shipped. For example, XiPay will display all prioritizing shipments and
open items for a customer A/R account in an interface that billings.
is similar to that shown in SAP transaction FBL5N. It allows
z Location of SAP documents
the CSR to charge one item at a time, or a sum of all items
according to a specific payment
selected.
card number.
Once payment card information is entered, XiPay will
perform authorization and post a clearing document with
transaction FB05. XiPay enables you to automate—and
even customize—this same basic functionality to "sweep"
accounts or pay items generated by billing plans or
contracts.

ENHANCED AND AUTOMATED

REPORTING CAPABILITIES
XiPay includes enhanced reporting through pre-coded SAP
extensions, saving your IT staff days or weeks of work in
custom coding effort.

XiPay 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."

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 12

Appendix A: Payback Example Using XiPay

PAYMETRIC PAYBACK SCENARIO

The example shown here displays the cost savings of
implementing payment card processing with third-party
software such as XiPay from Paymetric. 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

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 13

Appendix A: Payback Example Using XiPay, 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 Additional Revenue $ 263,040

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 14

Appendix A: Payback Example Using XiPay, 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

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 15

Appendix B - Terminology
A c q u i r e r : A bank or company that acquires data relating to transactions from a merchant (supplier) for
processing.
A c q u i r i n g B a n k : 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.
A u t h o r i z a t i o n : 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.
A u t h o r i z a t i o n C o d e : A code that an issuer or its authorizing processor provides to indicate approval or denial for
an authorization request.
A u t h o r i z a t i o n O n l y : 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.
B a n k I d e n t i f i c a t i o n N u m b e r ( B I N ) : The first six digits of a Visa or MasterCard account number. This number is
used to identify the card issuing institution.
C a r d I s s u e r : Any association member financial institution, bank, credit union, or company that issues, or causes
to be issued, plastic cards to cardholders.
C o m m e r c i a l C a r d : A general name for cards typically issued for business use and may include Corporate Cards,
Purchase Cards, Business Cards, Travel and Entertainment Cards.
C r e d i t C a r d P r o c e s s o r : 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).
F B R C : The SAP FI transaction code to Reset Cleared Items for Payment Cards.
I n t e r c h a n g e : 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.
I n t e r c h a n g e F e e : A fee paid by the acquiring bank/merchant bank to the issuing bank. The fee compensates the
issuer for the time after settlement with the acquiring bank/merchant bank and before it recoups the settlement
value from the cardholder
I s s u i n g B a n k ( I s s u e r ) : Any association member financial institution, bank, credit union, or company that issues,
or causes to be issued, plastic cards to cardholders.
L e v e l 3 : Also known as Level III, Level 3, or Level-IIIlLine-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.
L u h n C h e c k : 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.
M e r c h a n t ( o r s u p p l i e r ) : An entity that contracts with merchant banks or Independent Sales Organizations to
originate transactions.
M e r c h a n t B a n k : Bank that has a merchant agreement with a merchant (supplier) to accept (acquire) deposits
generated by bankcard transactions.
S e t t l e m e n t : The reporting of settlement amounts owed by one member to another, or to a card issuing concern,
as a result of clearing.
S e t t l e m e n t B a n k : 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.

PROCESSING PAYMENT CARD SALES TRANSACTIONS IN SAP 16

LEARN MORE ABOUT PAYMETRIC

This paper has described some of the advantages of using Paymetric empowers
a third-party software solution for processing payment card
organizations to benefit from
transactions in SAP. As an SAP Development Partner with a
licensed SAP system on site for development and support, payment cards by integrating
Paymetric delivers a payment card solution based on first- payment card buying and selling
hand experience, proven methodology, and superior functions directly into the financial
technical expertise.
supply chain. Paymetric solutions
leverage and extend SAP
To learn more about how XiPay from Paymetric can help you reduce
your days of sales outstanding, str eamline processing operations, capabilities to streamline
mitigate risk, and improve cash flow, visit our website at
procurement, sales, and
www.paymetric.com, email us at info@paymetric.com, or call
713.895.2000. accounting operations. Paymetric
customers benefit by reducing
Paymetric, Inc. Provides this document "as is" without warranty of any kind, either their cost structure, mitigating
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. risk, improving cash flow, and
This document and may not be lent, sold, or given away without the prior written expanding revenue opportunities.
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 Paymetric is an award-winning
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 SAP partner and certified SAP
illustration purposes and may not represent real companies, individuals, or data.
developer. Paymetric, established
This document could include technical inaccuracies or typographical errors. Changes are
periodically made to the information herein. These changes may be incorporated in new in 1998, is headquartered in
editions of this document. Paymetric, Inc. May make improvements in or changes to the
software described in this document at any time.
Houston, Texas and is an Austin
© 2005 Paymetric, Inc., all rights reserved.
Ventures portfolio company.

Paymetric, Inc.
13430 Northwest Freeway, Suite 900
Houston, TX 77040
Phone: 713.895.2000 Fax: 713.895.2001
www.paymetric.com