CREDIT CARD PAYMENT

[Former Member]

Hi!

can any one please tell me customization steps for credit card payment?

Thank u

Sushmitha

[Former Member · Accepted solution]

hi

Customizing:

http://help.sap.com/erp2005_ehp_02/helpdata/en/f0/ca4673260211d28a430000e829fbbd/frameset.htm

System Settings:

http://help.sap.com/erp2005_ehp_02/helpdata/en/b2/4dcd7cc8ecc046abe9baf7bfd4a9a4/frameset.htm

Credit Card Clearing

http://help.sap.com/erp2005_ehp_02/helpdata/en/54/8a4c6080df11d194bb00a0c92946ae/frameset.htm

Credit Card Settlement

http://help.sap.com/erp2005_ehp_02/helpdata/en/86/ab72584adc3f42a67dd88fdd5fc9e5/frameset.htm

Payment with Payment Card

http://help.sap.com/erp2005_ehp_02/helpdata/en/41/f7c8380ef2c707e10000000a11402f/frameset.htm

Given below is the set up for credit card payment processing:

Set Up Credit Control Areas:

Define Credit Control Area

Transaction: OB45

Tables: T014

Action: Define a credit control area and its associated currency. The Update Group should be ‘00012’. This entry is required so the sales order will calculate the value to authorize

Assign Company Code to Credit Control Area

Transaction: OB38

Tables: T001

Action: Assign a default credit control area for each company code

Define Permitted Credit Control Area for a Company

Code

Transaction:

Tables: T001CM

Action: For each company code enter every credit control area that can be used

Identify Credit Price

Transaction: V/08

Tables: T683S

Action: Towards the end of the pricing procedure, after all pricing and tax determination, create a subtotal line to store the value of the price plus any sales tax. Make the following entries:

Sub to: “A”

Reqt: “2”

AltCTy: “4”

Automatic Credit Checking

Transaction: OVA8

Tables: T691F

Action: Select each combination of credit control areas, risk categories and document types for which credit checking should be bypassed. You need to mark the field “no Credit Check” with the valid number for sales documents.

Set Up Payment Guarantees

Define Forms of Payment Guarantee

Transaction: OVFD

Tables: T691K

Action: R/3 is delivered with form “02” defined for payment cards. Other than the descriptor, the only other entry should be “3” in the column labeled “PymtGuaCat”

Define Payment Guarantee Procedure

Transaction:

Tables: T691M/T691O

Action: Define a procedure and a description.

Forms of Payment Guarantee and make the following entries Sequential Number “1”

Payment Guarantee Form “02”

Routine Number “0” Routine Number can be used to validate payment card presence.

Define Customer Payment Guarantee Flag

Transaction:

Tables: T691P

Action: Define a flag to be stored in table.

Create Customer Payment Guarantee = “Payment Card Payment Cards (All Customers can use Payment Cards)”.

Define Sales Document Payment Guarantee Flag

Transaction:

Tables: T691R

Action: Define the flag that will be associated with sales document types that are relevant for payment cards

Assign Sales Document Payment Guarantee Flag

Transaction:

Tables: TVAK

Action: Assign the document flag type the sales documents types that are relevant for payment cards.

Determine Payment Guarantee Procedure

Transaction: OVFJ

Tables: T691U

Action: Combine the Customer flag and the sales document flag to derive the payment guarantee procedure

Payment Card Configuration

Define Card Types

Transaction:

Tables: TVCIN

Action: Create the different card types plus the routine that validates the card for length and prefix (etc…)

Visa , Mastercard, American Express, and Discover

Create the following entries for each payment card

AMEX American Express ZCCARD_CHECK_AMEX Month

MC Mastercard ZCCARD_CHECK_MC Month

VISA Visa ZCCARD_CHECK_VISA Month

The Routines can be created based on the original routines delivered by SAP.

Define Card Categories

Transaction:

Tables: TVCTY

Action: Define the card category to determine if a

payment card is a credit card or a procurement card.

Create the following two entries

Cat Description One Card Additional Data

CC Credit Cards No-check No-check

PC Procurement Cards No-check Check

Determine Card Categories

Transaction:

Tables: TVCTD

Action: For each card category map the account number range to a card category. Multiple ranges are possible for each card category or a masking technique can be used. Get the card number ranges from user community. Below is just a sample of what I am aware are the different types of cards.

Visa Credit Expires in 7 days.

400000 405500

405505 405549

405555 415927

415929 424603

424606 427532

427534 428799

428900 471699

471700 499999

Visa Procurement Expires in 7 days.

405501 405504

405550 405554

415928 415928

424604 424605

427533 427533

428800 428899

Mastercard Credit Expires in 30 days

500000 540499

540600 554999

557000 599999

Mastercard Procurement Expires in 30 days

540500 540599

555000 556999

American Express Credit Expires in 30 days

340000 349999

370000 379999

Discover Card Credit Expires in 30 days

601100 601199

Set Sales Documents to accept Payment Card Information Transaction:

Tables: TVAK

Action: Review the listing of Sales Document types and enter “03” in the column labeled “PT” for each type which can accept a payment card

Configuration for Authorization Request

Maintain Authorization Requirements

Transaction: OV9A

Tables: TFRM

Action: Define and activate the abap requirement that determines when an authorization is sent. Note that the following tables are available to be used in the abap requirement (VBAK, VBAP, VBKD, VBUK, and VBUP).

Define Checking Group

Transaction:

Tables: CCPGA

Action: Define a checking group and enter the

description. Then follow the below guidelines for the remaining fields to be filled.

AuthReq Routine 901 is set here.

PreAu If checked R/3 will request an authorization for a .01 and the authorization will be flagged as such. (Insight does not use pre-authorization check).

A horizon This is the days in the future SAP will use to determine the value to authorize

(Insight does not use auth horizon period).

Valid You will get warning message if the payment card is expiring within 30 days of order entry date.

Assign Checking Group to Sales Document

Transaction:

Tables: TVAK

Action: Assign the checking group to the sales order types relevant for payment cards

Define Authorization Validity Periods

Transaction:

Tables: TVCIN

Action: For each card type enter the authorization validity period in days.

AMEX American Express 30

DC Discover card 30

MC Master card 30

VISA Visa 7

Configuration for clearing houses

Create new General Ledger Accounts

Transaction: FS01

Tables:

Action: Two General Ledger accounts need to be created for each payment card type. One for A/R reconciliation purposes and one for credit card clearing.

Maintain Condition Types

Transaction: OV85

Tables: T685

Action: Define a condition type for account determination and assign it to access sequence “A001”

Define account determination procedure

Transaction: OV86

Tables: T683 / T683S

Action: Define procedure name and select the procedure for control. Enter the condition type defined in the previous step.

Assign account determination procedure

Transaction:

Tables:

Action: Determine which billing type we are using for payment card process.

Authorization and Settlement Control

Transaction:

Tables: TCCAA

Action: Define the general ledger accounts for reconciliation and clearing and assign the function modules for authorization and settlement along with the proper RFC destinations for each.

Enter Merchant ID’s

Transaction:

Tables: TCCM

Action: Create the merchant id’s that the company uses to process payment cards

Assign merchant id’s

Transaction:

Tables: TCCAA

Action: Enter the merchant id’s with each clearinghouse account

Reward if USeful

Thanx & regard.

Naren..

[arvind_pereira · Accepted solution]

Former Member

This is really a detailed document, very good.

thanks

Arvind Leo Pereira

[Former Member]

hi

CREDIT CARDS

Go thr below links:

PAYMENT CARDS:

http://help.sap.com/saphelp_erp2005vp/helpdata/en/93/745309546011d1a7020000e829fd11/frameset.htm

Overview

This document attempts to explain in the brief the credit card processing in SAP.

SAP provides a flexible and secure payment card interface that works with the

software of selected partners that provide merchant processes and clearing house

services. In SAP the credit card processing is integrated with the sales and

distribution module.

Payment card configuration

Much of what is required for credit card processing to work with VISA, Master

Card, and American Express is already set up in SAP.

For all credit card configurations refer to

Define Card Types

Transaction SPRO IMG ‡ Sales and Distribution ‡ Billing ‡ Payment Cards

Here we define the type of cards that can be used in the system. A four-letter

code is given for each card type. E.g. MAST for Master Card, VSAJ for Visa

Japan. A function module for checking the card number is also specified here.

1. Define Card Types

Credit Card Configuration And Processing In SAP

Maintain Card Categories

(a) Define card Categories: Here we specify the card category of the

payment card. With this the system automatically determines the card

category when you enter a card number in master data or sales

documents.

(b) Determine card categories: Here we specify the acceptable number

ranges for different card types. Also card categories are assigned to the

card types. Even though SAP comes with card checking algorithms

(Function Modules) for standard card types this configuration setting

is particularly useful to those cards that do not contain any standard

checking algorithm already set up in SAP.

2. Determine Card Categories

Maintain Payment Card Plan Type

In this step, you assign the payment plan type for payment cards, the payment

card plan type, to all sales document types in which you will be using payment

cards. You cannot process payment cards if you have not made this assignment

The standard system contains payment plan type 03 for processing payment

cards. 3. Show the screen where this assignment is done.

Credit Card Configuration And Processing In SAP

3. Maintain Payment Plan Type

Maintain Blocking Reasons

In this step, you define blocking reasons for payment cards. You enter these in

the payer master record to block cards. The standard system contains blocking

reason 01 for lost cards.

Risk Management for Payment Cards

Transaction SPRO IMG ‡ Sales and Distribution ‡ Billing ‡ Payment Cards

‡ Authorization and settlement ‡ Risk Management for payment cards.

Risk Management plays a central role within Sales, providing you with checks

and functions to minimize your credit risk. In addition to letters of credit and

export credit insurance, payment cards are among the payment guarantee forms

that you can use to insure payment for sales order items. SAP comes with predefined

payment forms of guarantee as shown below. Customer can also

maintain other forms of payment suited for their line of business.

Credit Card Configuration And Processing In SAP

Define forms of payment guarantee

3. Define forms of payment guarantee

Maintain payment guarantee procedures

In this step, you define Payment guarantee procedure. These procedure controls,

which form of payment guarantee, are valid for a particular customer, and for a

particular sales document type.

The various settings done under this configuration are

Define payment guarantee procedures

Maintain customer determination procedure

Maintain document determination procedure

Assign sales document types

Determine payment guarantee procedures

Maintain authorization requirements*

Here requirements* are set to tell the system how and when to carry out

authorization when a sales order is saved. SAP comes with two requirements

Form routine 1. Carry out authorization only when the sales document is

complete. The system carries authorization when the order is saved.

Form routine 2. Carry out authorization only when the sales document is

complete, but the authorization for all the complete documents is carried out in

batch.

Additional requirements* can be assigned here as per the business requirements.

*Requirements are ABAP/4 code. Requirements for various functions can be accessed using transaction VOFM

Credit Card Configuration And Processing In SAP

4. Maintain Card Authorization Requirements

Maintain Checking Groups

How and when authorizations are carried out depends on the setting you make in

the customizing for maintain checking group routines.

The three main settings that influence authorization are:

a) Authorization requirements

b) Authorization horizon

c) Preauthorization

There are two settings under this setting.

Define checking group: Here a checking group is defined and the

authorization requirement (described in the previous section), Authorization

horizon (described below) and preauthorization settings are done for this

checking group.

5. Define Checking Group

Credit Card Configuration And Processing In SAP

Here you can see a checking group C1 is defined with the authorization

requirement 902. Checking the pre-authorization tells the system to carryout preauthorization

if the order fulfillment date falls outside the horizon. The

authorization horizon specifies the number of days before the material

availability date, or billing date, that the system is to initiate authorization. If a

sales order is saved within the authorization horizon, the system carries out

authorization immediately. If a sales order is saved before the authorization

horizon comes into effect, the system does not authorize at all, or carries out

preauthorization.

6. Preauthorization Concept

In this example, the system has been set to authorize one day before delivery

creation. The system does not carry out authorization when the order is saved on

Day 0, rather on Day 2. Note that the authorization validity period has been set to

14 days in Customizing IMG‡ Authorization and settlement‡ Specify

authorization validity periods. The transaction will have to be reauthorized if

delivery activities take longer than 14 days.

Assign checking groups: Here the checking groups defined earlier are

assigned to different sales document types as shown 8.

Specify authorization validity periods

Here number of days that an authorization can remain valid for different card

types are maintained. Refer to 9.

Credit Card Configuration And Processing In SAP

8. Assign checking groups

9. Assign validity period for authorization for different card types

Credit Card Configuration And Processing In SAP

Account Determination

Transaction SPRO IMG ‡ Sales and Distribution ‡ Billing ‡ Payment Cards‡

Authorization and settlement ‡ Maintain Clearing House

In the following steps, you set the condition technique for determining

clearinghouse reconciliation accounts for authorization and settlement. The

system uses the entries here to determine the clearing account for the payment

card charges. When settlement is run, the postings in the receivable account for

the payment card will be credited and a consolidated debit will be created and

posted to the clearinghouse account. These accounts are a special type of general

ledger account that is posted from Sales and Distribution.

Here, you maintain:

• Maintain field catalog.

• Condition tables and the fields that they contain

• Access sequences and condition types

• Account determination procedures

• You then assign these accounts to condition types.

Add to field catalog

Here you maintain the fields that can be used in the condition table. 10.

Shows the transaction to maintain the field catalog.

10. Maintain Field Catalog.

Maintain condition tables

Here condition tables are maintained with fields that are added to the field

catalog. SAP comes pre-configured with two condition tables 4 and 6. Refer

11.

Credit Card Configuration And Processing In SAP

11. Maintain Condition Table

Maintain access sequences

In this step we define an access sequence and link the access sequence with the

condition tables.

Here an access sequence is defined. SAP comes with the access sequence A001.

12. Define Access Sequence

Once the new access sequence is defined, it is linked to the condition tables as

shown in the next screen.

Credit Card Configuration And Processing In SAP

13. Maintain Access For Access Sequence

Selecting an access and clicking fields will display the fields for the selected

access as shown below for access 10 as shown above.

14. Display Access Fields

Maintain condition types

Here condition types are defined and the access sequence to linked to it.

Condition types are contained in account determination procedures and control

which access sequences the system uses to find condition records.

These are The condition tables.

Credit Card Configuration And Processing In SAP

15. Define condition type

Maintain account determination procedure

In this step an account determination procedure is defined and linked to the

condition type (which in turn is linked to the access sequence).

Define account determination procedure

16. Assign account determination procedure.

Here an account determination procedure CC01 is defined and the condition type

CC01 is assigned to it.

Access sequence linked to the condition type

Credit Card Configuration And Processing In SAP

Assign account determination procedures

In this customizing the previously set up account determination procedure is

assigned to different billing documents.

Assign Accounts (G/L)

G/L accounts are assigned here for the combination of Sales organization, Card

type, chart of accounts and condition types as shown in the 17.

17. Assign G/L accounts

Set authorization / settlement control per account

Each G/L account is assigned an authorization and a settlement function module.

The system will read the configuration a call the authorization and settlement

function module during authorization and settlement respectively.

Credit Card Configuration And Processing In SAP

18. Set Authorization and settlement function module

Maintain merchant IDs per account

A merchant may have one or more IDs for each clearinghouse with which it does

business. Here, you assign these different merchant IDs to their related

receivables accounts.

19. Assign Merchant ID’s

Credit Card Configuration And Processing In SAP

Authorization and Settlement in SAP

20. Sales Order Cycle With Credit Card Authorization

When an order is placed through the front-end system, the order information,

credit card information, billing information, shipping information is passed to

SAP. SAP processes the order calculates the taxes, the shipping costs and reads

the configuration information settings and executes the function module setup as

described in Fig. 18. The function module formats the data and makes a RFC *

call to the payment application**.

The payment application screens the order for fraud, encrypts the data and

communicates with the third party processor who in turns communicates with

the card association and card issuer.

*RFC (Remote Function Call)

*Payment Application: Middle ware between SAP and third party processor/bank.

Credit Card Configuration And Processing In SAP

The third party processor responds back with the response whether the

transaction is approved or declined or referred.

Note: When any item in the order does not have a confirmed quantity, then

authorization is not carried out for the full amount. A small dollar amount

usually ($1) is used as the authorization amount. During the rescheduling run

the system will check for the material availability. If the material can be

delivered within the horizon date, a full authorization for the order is carried

out.

Approved: When the credit card transaction is approved the systems checks for

the material availability, confirms the material for the ordered quantity and saves

the order.

Declined: The material availability check for the material is not made, and the

order is rejected.

Referred: The order is saved and is blocked for delivery. In this situation is

merchant calls the bank checks for the available credit on the card and a manual

authorization is carried out.

21. Sales Order Entry Screen in SAP

Payment Card

Information

Credit Card Configuration And Processing In SAP

The first line in payment card screen is the card check performed by SAP system,

using the card check algorithm function module as described in 1. And the

remaining lines represent the actual authorizations that are carried out.

22. Payment Card Screen

Path Header ‡ Payment Cards.

Settlement

Legally the merchant can charge the credit card after the order has been

completely processed. In SAP this happens after a delivery is created and the

goods has been shipped. In case there is not enough authorization for the order

to be delivered, the system goes out the get the authorization for the remaining

amount.

In SAP settlement is initiated using the transaction FCC1. All the valid

authorization is submitted in a batch to the payment application at scheduled

intervals as specified by the third party processor.

The payment application encrypts this data and communicates with the third

party processor. The third party processor checks if the settlement request has a

valid authorization against it. The third party processor then transfers the fund

from the cardholder’s bank to the merchant bank.

Authorization

Response

Credit Card Configuration And Processing In SAP

<a href="http://help.sap.com/printdocu/core/Print46c/en/data/pdf/SDBILIVPC/SDBILIVPC.pdf">http://help.sap.com/printdocu/core/Print46c/en/data/pdf/SDBILIVPC/SDBILIVPC.pdf</a>

[Former Member]

<b>HI REFER BELOW REWRAD IF HELPS</b>

Credit Card Payment Processing

Given below is the set up for credit card payment processing:

Set Up Credit Control Areas:

Define Credit Control Area

Transaction: OB45

Tables: T014

Action: Define a credit control area and its associated currency. The Update Group should be ‘00012’. This entry is required so the sales order will calculate the value to authorize

Assign Company Code to Credit Control Area

Transaction: OB38

Tables: T001

Action: Assign a default credit control area for each company code

Define Permitted Credit Control Area for a Company

Code

Transaction:

Tables: T001CM

Action: For each company code enter every credit control area that can be used

Identify Credit Price

Transaction: V/08

Tables: T683S

Action: Towards the end of the pricing procedure, after all pricing and tax determination, create a subtotal line to store the value of the price plus any sales tax. Make the following entries:

Sub to: “A”

Reqt: “2”

AltCTy: “4”

Automatic Credit Checking

Transaction: OVA8

Tables: T691F

Action: Select each combination of credit control areas, risk categories and document types for which credit checking should be bypassed. You need to mark the field “no Credit Check” with the valid number for sales documents.

Set Up Payment Guarantees

Define Forms of Payment Guarantee

Transaction: OVFD

Tables: T691K

Action: R/3 is delivered with form “02” defined for payment cards. Other than the descriptor, the only other entry should be “3” in the column labeled “PymtGuaCat”

Define Payment Guarantee Procedure

Transaction:

Tables: T691M/T691O

Action: Define a procedure and a description.

Forms of Payment Guarantee and make the following entries Sequential Number “1”

Payment Guarantee Form “02”

Routine Number “0” Routine Number can be used to validate payment card presence.

Define Customer Payment Guarantee Flag

Transaction:

Tables: T691P

Action: Define a flag to be stored in table.

Create Customer Payment Guarantee = “Payment Card Payment Cards (All Customers can use Payment Cards)”.

Define Sales Document Payment Guarantee Flag

Transaction:

Tables: T691R

Action: Define the flag that will be associated with sales document types that are relevant for payment cards

Assign Sales Document Payment Guarantee Flag

Transaction:

Tables: TVAK

Action: Assign the document flag type the sales documents types that are relevant for payment cards.

Determine Payment Guarantee Procedure

Transaction: OVFJ

Tables: T691U

Action: Combine the Customer flag and the sales document flag to derive the payment guarantee procedure

Payment Card Configuration

Define Card Types

Transaction:

Tables: TVCIN

Action: Create the different card types plus the routine that validates the card for length and prefix (etc…)

Visa , Mastercard, American Express, and Discover

Create the following entries for each payment card

AMEX American Express ZCCARD_CHECK_AMEX Month

DC Discover Card ZCCARD_CHECK_DC Month*****

MC Mastercard ZCCARD_CHECK_MC Month

VISA Visa ZCCARD_CHECK_VISA Month

The Routines can be created based on the original routines delivered by SAP.

*****SAP does not deliver a card check for Discover Card. We created our own routine.

Define Card Categories

Transaction:

Tables: TVCTY

Action: Define the card category to determine if a

payment card is a credit card or a procurement card.

Create the following two entries

Cat Description One Card Additional Data

CC Credit Cards No-check No-check

PC Procurement Cards No-check Check

Determine Card Categories

Transaction:

Tables: TVCTD

Action: For each card category map the account number range to a card category. Multiple ranges are possible for each card category or a masking technique can be used. Get the card number ranges from user community. Below is just a sample of what I am aware are the different types of cards.

Visa Credit Expires in 7 days.

400000 405500

405505 405549

405555 415927

415929 424603

424606 427532

427534 428799

428900 471699

471700 499999

Visa Procurement Expires in 7 days.

405501 405504

405550 405554

415928 415928

424604 424605

427533 427533

428800 428899

Mastercard Credit Expires in 30 days

500000 540499

540600 554999

557000 599999

Mastercard Procurement Expires in 30 days

540500 540599

555000 556999

American Express Credit Expires in 30 days

340000 349999

370000 379999

Discover Card Credit Expires in 30 days

601100 601199

Set Sales Documents to accept Payment Card Information Transaction:

Tables: TVAK

Action: Review the listing of Sales Document types and enter “03” in the column labeled “PT” for each type which can accept a payment card

Configuration for Authorization Request

Maintain Authorization Requirements

Transaction: OV9A

Tables: TFRM

Action: Define and activate the abap requirement that determines when an authorization is sent. Note that the following tables are available to be used in the abap requirement (VBAK, VBAP, VBKD, VBUK, and VBUP).

Define Checking Group

Transaction:

Tables: CCPGA

Action: Define a checking group and enter the

description. Then follow the below guidelines for the remaining fields to be filled.

AuthReq Routine 901 is set here.

PreAu If checked R/3 will request an authorization for a .01 and the authorization will be flagged as such. (Insight does not use pre-authorization check).

A horizon This is the days in the future SAP will use to determine the value to authorize

(Insight does not use auth horizon period).

Valid You will get warning message if the payment card is expiring within 30 days of order entry date.

Assign Checking Group to Sales Document

Transaction:

Tables: TVAK

Action: Assign the checking group to the sales order types relevant for payment cards

Define Authorization Validity Periods

Transaction:

Tables: TVCIN

Action: For each card type enter the authorization validity period in days.

AMEX American Express 30

DC Discover card 30

MC Master card 30

VISA Visa 7

Configuration for clearing houses

Create new General Ledger Accounts

Transaction: FS01

Tables:

Action: Two General Ledger accounts need to be created for each payment card type. One for A/R reconciliation purposes and one for credit card clearing.

Maintain Condition Types

Transaction: OV85

Tables: T685

Action: Define a condition type for account determination and assign it to access sequence “A001”

Define account determination procedure

Transaction: OV86

Tables: T683 / T683S

Action: Define procedure name and select the procedure for control. Enter the condition type defined in the previous step.

Assign account determination procedure

Transaction:

Tables:

Action: Determine which billing type we are using for payment card process.

Authorization and Settlement Control

Transaction:

Tables: TCCAA

Action: Define the general ledger accounts for reconciliation and clearing and assign the function modules for authorization and settlement along with the proper RFC destinations for each.

Enter Merchant ID’s

Transaction:

Tables: TCCM

Action: Create the merchant id’s that the company uses to process payment cards

Assign merchant id’s

Transaction:

Tables: TCCAA

Action: Enter the merchant id’s with each clearinghouse account

http://images.google.com/imgres?imgurl=http://web.mit.edu/sapr3/docs/webdocs/purchpay/screens/ppCCwk...

Message was edited by:

SHESAGIRI.G