1. Implementing Payment Cards
A Project Plan
Session 1111
Jeff Hirsch
SAP America, Inc.

2. Overview of payment card functionality in R/3 and CRM Project plan
Agenda
Overview of payment card functionality in R/3 and CRM
Project plan
Questions and answers

3. Some Definitions
Authorization – Reservation of a customer’s credit in advance of a sale
Settlement – The process of requesting payment against an authorization after the sale
Issuing bank – Financial organization that issues payment cards
Clearing house – Organization that provides payment card authorization and settlement services to merchants. Intermediary between merchant and issuing bank.
Middleware – Third-party software to communicate between CRM or R/3 and clearing house
Level 2/Level 3 – Invoice detail information required by customers who use procurement cards

4. Authorization Process
Real-time Or
Background
Requests
goods/services
Receives CC data. Sends on for authorization.
Sends request to issuing bank M
Issuing Bank
Merchant
In the authorization process, the card-issuing bank is requested to authorize a purchase. If approved, the value of the authorization reserves some of the card-holder’s available credit. The reservation is good for a finite period of time – if not used it automatically expires and increased the card-holder’s available credit.
The card service provider acts primarily as a conduit between the merchant and the card-issuing bank.
Customer
Card
Services
Receives goods/services
Sends authorization to merchant
Authorizes transaction
Approves order

5. Settlement Process Batch M Merchant Issuing Bank Card Services
Settles batch. Sends payment instructions to both banks.
Transfers funds to merchant bank. Updates cardholder’s statement.
Transmits batch for settlement M
Merchant
The settlement process occurs after the sale has been completed, and the merchant requests payment.
Settlement references the authorization (or authorizations) associated with the sales order.
Settlement should occur before the authorization expires – if the authorization has expired the customer’s credit may have been committed to another merchant.
R/3 has no special functions for posting incoming payments from settlement – existing accounting procedures are used.
Issuing Bank
Card
Services
Merchant Bank
Receives notification of funds availability.
Deposits funds in merchant’s account.

6. R/3 Payment Card Overview
Can configure all types of payment cards
Can store card info in customer master
Authorization a real-time and background function
Invoice can reference multiple authorizations
Manual authorization supported
Can automate authorization retries in case of technical problems
You can define credit cards and procurement cards. Gift certificates can be defined as payment cards.
Multiple currencies are supported.
Level 3 reporting may require customer-specific coding to identify freight charges.

7. R/3 Payment Card Overview
Can be used with one-time customers and established customers
Integrated with Accounts Receivable and General Ledger
Supports Level 3 reporting for purchasing cards (may require customer-specific code)
Middleware certification program administered by SAP Labs
You can define credit cards and procurement cards. Gift certificates can be defined as payment cards.
Multiple currencies are supported.
Level 3 reporting may require customer-specific coding to identify freight charges.

8. R/3 Authorization Card Info Address Info MIDDLEWARE Authorization
Sales order
Pay with VISA
Ship-to party Cust Main St.
Sold-to/Payer A. Cardholder 456 George St.
Card Info
Card Services
Address
Info
Items
Printer 1 PC 400 USD
Paper 2 PC USD
408 USD
MIDDLEWARE
Authorization
Amount, Etc.
Authorization granted
Authorization is requested as the order is saved.
The value of the authorization requested is based on the value of the inventory confirmed by the Available to Promise check.
A customizable authorization horizon restricts the authorization value to deliveries made within a certain time frame.
A background process will automatically request authorization for future deliveries, when the delivery dates fall in the authorization horizon.
If the system determines that the sales order will result in multiple invoices, it will request multiple authorizations.
Payment cards are integrated within R/3 risk management – an order without sufficient authorization is blocked from subsequent activity.
Delivery
Printer 1 PC
Paper 2 PC

9. CRM Integration With R/3
CRM System
OLTP R/3
Credit Card
Information
Authorization
Response(s)
Credit Card
Information
Authorization and
Settlement
Response(s)
Card Services
CRM accepts a sales order but fulfillment is done in R/3
If the order will be shipped immediately and all in a single delivery, then the full authorization can be requested from CRM
If the order may not be shipped immediately or may be shipped in multiple deliveries, then CRM should request a pre-authorization to validate the payment card account and the full authorization should be requested from within R/3.
Initial authorization
Subsequent authorizations
Settlement

10. CRM Payment Card Overview
Can configure all types of payment cards
Can use multiple payment cards in a single sales order
Authorization a real-time function
Invoice can reference multiple authorizations
Can be used with one-time customers and established customers
Middleware interface NOT certified by SAP Labs – different structures than R/3
Not an issue – certified providers have demonstrated ability to work with RFC
Authorization response is transferred to R/3 when order is passed to R/3
You can define credit cards and procurement cards. Gift certificates can be defined as payment cards.
Multiple currencies are supported.
Must modify the outgoing authorization RFC structure to match R/3 in order to interface with SAP certified middleware solutions

11. R/3 Billing Release to FI Amount 408 Sales Order VISA 1234...
Payer A.Cardh.
Items 408
Amount 408
Sales Order
VISA
Payer A.Cardh.
Items 408
Amount 408
Sales Order
VISA
Payer A.Cardh.
Items
Amount 408
Delivery
Delivery
Delivery
FI Doc
Amount 408
FI Doc
Amount 408
FI Doc
Amount 408
The settlement process is initiated from within R/3 Accounts Receivable.
Settlement is a batch process – many payment requests are transmitted together.
Payment card invoices are posted to special A/R accounts.
At the time of settlement, the A/R items are cleared and the value is then posted to a special cash clearing account.
Each settlement run is assigned a unique reference number.
Procurement cards require information describing the goods and services that were purchased – R/3 obtains this information from the SD billing document.
Billing Doc
VISA
Payer A.Cardh.
Items 408
Amount 408
Billing Doc
VISA
Payer A.Cardh.
Items 408
Amount 408
Billing Doc
VISA
Payer A.Cardh.
Items
Amount 408
Release to FI

12. Transmission of additional data
R/3 Settlement
Card Services
Sales Order
VISA
Payer A.Cardh.
Items 408
Amount 408
Sales Order
VISA
Payer A.Cardh.
Items 408
Amount 408
Sales Order
VISA
Payer A.Cardh.
Items
Amount 408
MIDDLEWARE
Settlement
Delivery
Delivery
Delivery
Transmission of additional data
for procurement cards
FI Doc
Amount 408
FI Doc
Amount 408
FI Doc
Amount 408
The settlement process is initiated from within R/3 Accounts Receivable.
Settlement is a batch process – many payment requests are transmitted together.
Payment card invoices are posted to special A/R accounts.
At the time of settlement, the A/R items are cleared and the value is then posted to a special cash clearing account.
Each settlement run is assigned a unique reference number.
Procurement cards require information describing the goods and services that were purchased – R/3 obtains this information from the SD billing document.
Billing Doc
VISA
Payer A.Cardh.
Items 408
Amount 408
Billing Doc
VISA
Payer A.Cardh.
Items 408
Amount 408
Billing Doc
VISA
Payer A.Cardh.
Items
Amount 408

13. Financial Document Created From SD
FI document
Account A. Cardholder
Trans 0001 Auth 1234
VISA
Amount 80 USD
A. Cardholder 80 80
Revenue 80
A. Cardholder
FI document
Account A. Cardholder
Trans 0002 Auth 5678
VISA
Amount 100 USD
MC/VISA
100
100 80
100
500
Revenue
100
B. Cardholder
FI document
Account B. Cardholder
Trans 0003 Auth 8765
VISA
Amount 500 USD
500
500
Revenue
500

14. Settlement Accounting
MC/VISA
CC Clearing 80
100
500 80
100
500
680
Request for
payment
680 USD
VISA

15. Posting the Cash CC Clearing MC/VISA Bank Charges 80 100 500 680 68015
Cash
The difference between incoming cash (665 USD)
and expected sum (680 USD) can be posted as
charges or deductions.
The CC clearing account is cleared.
Charges are not posted automatically.
665

16. Project Plan

17. Project Plan – No Experience With Credit Cards
~ 6 months

18. Project Plan – Already Using Credit Cards
~ 2 months

19. Project Plan Task List Nr Description Days Resource 1
Define scope and environment
2 – 10
Business
[2]
Select bank & card processor
45 – 90
Finance
[3]
Arrange for communications
5 – 60 IT 4
Select middleware
20 – 30 5
Configure/unit test
SD/FI 6
User exits & enhancements
4 – 5
SD/Basis 7
Unit test with simulation 2 SD 8
Integration test with simulation
7 – 10 9
Install middleware
2 – 3
IT/Vendor 10
Unit test with middleware 11
Integration test with middleware
2 – 5 12
Site certification with processor 13
Document R/3 procedures 14
Document middleware procedures 15
End user training
SD/FI + CUST SVC & A/R 16
Go Live!!

20. (1) Determine Project Scope and Environment
Which card types will you offer?
In which countries will you accept payment cards?
How will orders be entered: CRM, web site, R/3?
Do you require that stored card information be encrypted?
Will you accept a credit card to pay an open balance in Accounts Receivable?
Will credit cards replace COD or pre-payments by check?
Will credit cards be used for periodic billing (billing plans)?
Will credit cards be used for installment payments?
What is the typical value of a payment card order?
How many credit card orders per day will you process?
Consumer credit cards typically have much lower available credit than procurement cards. When coupled with high order values you can anticipate higher rates of declines. Consider the impact on your customer service department.
Some authorizations will expire in as few as 7 days – therefore settlement should be initiated within 7 days of authorization request to minimize problems.
Typical processes with third party orders wait until receipt of the supplier’s invoice before invoicing the customer. If your suppliers don’t invoice immediately, consider having the supplier send an Advance Ship Notice and use that to initiate invoicing.

21. (1) Determine Project Scope and Environment
Will your customers be consumers or businesses?
Do any of your customers have specific requirements for reporting on credit card purchases?
What are the organizational responsibilities?
Are orders filled from your inventory or from 3rd party suppliers?
What will be typical time between order entry and invoicing?
Are you providing goods, services or both?
Can a single order result in multiple deliveries and/or invoices?
How good is your ATP (Available to Promise) process?
Do you want to confirm stock to an order that has not yet received an authorization?
Because R/3 requests authorizations BEFORE deliveries are created, it must be able to predict the number and the value of the invoices that will result. This requires an accurate ATP process.

22. (2) Select Bank and Card Processor
Choice of merchant bank generally dictates the card processor (clearinghouse)
Does clearinghouse support the card types you would like to accept?
Does clearinghouse operate in the countries and/or currencies in which you accept payment cards?
What discount rates can you negotiate?
Will you need to use multiple clearinghouses to support the card types and/or currencies you wish to process?
What communication methods do they support?
In the US a single clearing house generally covers all card types. In other countries that is not necessarily true.

23. (3) Arrange for Communications
Method
Pros
Cons
Recommendation
Time
Direct line (frame- relay)
Fastest, most reliable, best for high data volumes
Expensive, lengthy lead time.
Best, especially for high data volumes ( trans/day)
45 – 60 days
Internet
Inexpensive, leverage existing connection, quick to install
Response-time varies by network traffic, not supported by all clearinghouses, ISP quality is an issue
Good for low-mid data volumes (5 – trans/day)
2 – 5 days
Dialup (modem)
Inexpensive, quick to install
Line quality an issue, not supported by all clearinghouses, slow response, potential problems during settlement transmission
Not recommended

24. Middleware – Why Not Write Your Own?
Long (60-day) certification process with clearing house
Lack of support – clearing house does not want to talk with you
Difficult to change banks and clearing house

25. (4) Select Middleware
Is middleware product certified by your clearinghouse(s)?
Is middleware product certified by SAP?
Will it handle anticipated data volumes?
Does vendor offer a turn-key installation?
Does middleware support Level 3 reporting?
Does middleware offer additional needed features?
Encryption
A/R integration
Fraud prevention
You can write your own middleware – it must be certified by each clearing house. Certification takes 2 months or more. You also have to maintain it as clearing house requirements change.
SAP-certification verifies that the software communicates successfully with R/3.
If you accept purchasing cards, you will pay a higher discount rate if you cannot provide Level 3 reporting.

26. How Do I Find Middleware Providers?
In SAPNet, go to
Search by Software Category
From drop-down list, select Payment Card Interface

27. (5) Configure and Unit Test
Identify order types to be used
Identify credit memo and return order types to be used
Create G/L accounts for credit cards and for clearing
Configure standard system
Test the process – order entry through settlement

28. Review OSS Corrections
Many corrections have been posted in OSS. Not all are delivered in Service Packs.
Most corrections are delivered in R/3 release 4.6C.
Look under these components:
SD-BIL-IV-PC for SD-related corrections
FI-BL for settlement-related corrections
CRM-BF-PC for CRM-related corrections

29. (6) Frequent User Exits and Enhancements
Create card validation routines for Discover card (and others)
Enhance data transfer routines to copy card information from a billing document to return order and credit memo request
Bypass selected credit checks in order if credit card is used
Suppress blocked credit card orders from credit management blocked document reports (like VKM1)
Activate user exit routine for split authorizations

30. (6) Frequent User Exits and Enhancements
Inflate authorization to cover increases in invoice value
Freight added to delivery or billing document
Re-pricing
Over-picking
Review printing of credit card invoices
Add support for Card Verification Value

31. Gaps and Enhancements Potential Gap Enhancement
Authorization logic does not consider billing plans.
Can read billing plan information in a user exit. Also requires a MODIFICATION. Applicable to periodic billing, not installment billing.
Billable items added to delivery (packaging, freight, etc.) not charged to payment card.
Delivery to billing document data transport routine.
Installment purchases, down payments not supported.
Can be done, but requires development effort. May require a MODIFICATION.
Accept credit card in A/R to pay open balance
If infrequent, can develop a credit memo/debit memo work-around.
Some middleware vendors offer an integrated solution .
Payment card information not encrypted in data base.
Use authorizations to control access to payment card information.
Data encryption/decryption offered by some middleware vendors.

32. (7 – 8) Unit and Integration Testing
SAP-delivered authorization and settlement simulation routines can be used for all but the final testing.
Test all enhancements thoroughly.
Integration testing should use actual processes.
VL10x to create deliveries, not VL01N
VF04 to create billing documents, not VF01
Process should extend over several days
Integrate with order fulfillment processes
Rescheduling
MRP
3rd-party purchase orders
Interfaces with non-R/3 warehouses

33. (9 – 11) Install and Test Middleware
Normally supported by vendor’s consultants
Look out for network settings that may disconnect the middleware server from R/3 after a period of inactivity.
Attempt to request authorizations and run settlement when server is not connected. See how system responds and develop appropriate procedures.
Test value-added services.
Obtain a list of authorization failure reasons from the clearinghouse.
Verify that authorization failures map to the correct response in R/3 and that descriptive texts are provided.
Process a real transaction for a low dollar amount and then verify that the money is deposited in your merchant account.

34. (12) Certify Site With Clearinghouse
Clearinghouses frequently require a certification that you can provide the necessary information to qualify for best discount rates.
Address verification
eCommerce indicator
POS indicators
Level 2 or level 3 data at settlement
Card verification code at authorization
Certification typically required for each card type accepted
Must test all transaction types
Authorization
Credit
Settlement

35. (13 – 14) Define and Document Procedures
R/3 functions –
Customer master maintenance
Order entry
Detecting and processing authorization failures (VCC1)
Detecting and processing problems at invoicing (VFX3)
Settlement
Problems with settlement run batches
Processing receipt of payments from credit card companies
Accounting procedures for credit card charges and chargebacks
Middleware functions –
Technical administration
Reports
Value-added functions

36. (15) Train End Users Customer Service Accounts Receivable Finance
Master Data Maintenance

37. (16) Go Live
Oh Happy Day...

38. Additional Information
WNACCP 2-day workshop – contact SAP Training for schedule

39. Q and A