Working with Paymetric SAP Credit Card

Solution

They have had a long and comprehensive look at SAP‟s standard solution for credit cards and

developed their offering to fill the gaps and improve the functionality.

Here are a few examples:

In standard SAP, the customer needs to decide up front in the sales order to pay by credit

card. It is not possible to pay for your open A/R balance later. Paymetric‟s Open A/R

module allows you to select Open balances after the fact to settle with a credit card.

In standard SAP, if you have a billing plan of say 3 bills of $5,000 each, SAP will

attempt to authorize the whole $15,000 instead of only the amount with in the configured

horizon. There is a way of using the Auto A/R module to cover this.

The solution comprises of a group of SAP programs (imported as a series of transports) and a

separate server called XiPay (actually server is a misnomer, it is actually a piece of middleware

that communicates with the payment processor). There is also an encryption/decryption server

which resides on the same box.

The XiPay server is where you get a lot of value, as Paymetric has certified their interfaces with

the processors (and they support quite a few). This save a bunch of development and testing

time.

Even though the solution is vastly improved, it does not necessarily mean that you do not have to

add code to user exits.

For example: It does not support Invoice Cancellations out of the box. You need to add some

coding to cover the 2 scenarios: before settlement and after settlement. Actually, most of the

coding is related to the XiPay side in this case. Another example is Billing Plans. A bit of code

needs to be added to handle these.

Whatever you do, do not underestimate the effort still involved in implementing credit cards as

we have discovered. Paymetric definitely does shorten the implementation time dramatically, but

do not get the illusion that it is a plug and go.

I have also been very impressed with the caliber of the Paymetric consultants when we have had

questions or issues.

In summary, I think it is an excellent solution and well worth the investment. It will shorten your

credit card implementation time and really improve your final solution.

What a great site! I have a question out to our consultants, but it‟s been awhile so I was

trying to google the answer… we use the customer master functionality for credit card

information, but it‟s becoming a problem when a customer‟s expiration date changes. Our

people in the field need to process the card immediately, and not wait for the centralized

MDM team at corporate to make the change (which could take days). Does anyone have

any ideas or hints on how to change code for this? Thanks in advance!

Eric Bushman June 27, 2013 at 12:05 pm

Lesley,

Unfortunately, SAP has code in place that pulls the details in from the Customer Master

record whenever you enter a card/token number that is stored on a Customer‟s Master

record. In other words, if the card 4444333322221111 is stored on the Customer‟s Master

records with an Expiration Date of 12/15 and you try to use that card on a Sales Order

and enter an Expiration Date of 04/19 then SAP will overwrite it back to 12/15.

This happens in FUNCTION CCARD_ENHANCE_FROM_MASTERDATA. This

function is called in the business logic flow immediately after the Card Validation

Routine from configuration is called in FORM CC_NUMBER_CHECK in program

LV60FFCC. You would need to modify the code to skip that check or have a different

response.

I hope that helps!

Regards,

Eric Bushman

Paymetric.

Reply

Lesley June 27, 2013 at 12:16 pm

Thanks, Eric!

For the expiration date problem, we decided to automate the request to MDM. This way,

it will go through immediately when the user updates it.

Lesley

Reply

Eric Bushman June 27, 2013 at 12:41 pm

Lesley,

My pleasure!

Do you mind sharing how you automated the requests?

Regards,

Eric Bushman

Paymetric

Reply

Lesley June 27, 2013 at 12:46 pm

I believe we are using Service Now for it, but I‟m not 100% sure. There is a helpdesk

type of software in which the user can submit requests as a workflow. And I believe they

would have to enhance that to sync with SAP. Sorry, I‟m not very technical. I‟ll know

more probably next month when it actually rolls out (it is a different department).

Amit Mulay March 19, 2013 at 2:56 am

Hello Eric,

Our business requires sales order authorization should split per line item i.e. if there are

three line items in SO, then total sales order authorization should split in three

authorizations. Each authorization should have value equal to line item value. Is there any

way by which we can split authorization in CRM per line item?

Kind Regards,

Amit Mulay

Reply

Jshah January 5, 2013 at 10:21 am

Hello Eric/ Paul.

Thanks for your Prompt answer.

If i use the User exit option :

Userexit_Field_modification then could you please suggest me the code to suppress the

fields or keep the screen blank for the non payment card customer according to the

Account group.

As you have mentioned Payment card tab is appearing at both overview and Header level

so have to deal with Multiple screens

Eric, I have also come across your Old post where somebody had suggested the code for

the same USER exit. It was back in 2010.

Could it be possible to post that code to see whether it works in my case.

Our ABAPer had spent couple of hours so far but could not able to fix the Problem(could

not able to locate right screen no 4204 & 4001 to suppress the TAB or Greyed out the

Particular fields)

Awaiting for your updates.

Many Thanks

Jitesh

Reply

Eric Bushman January 6, 2013 at 1:17 pm

Jitesh,

I‟ve looked in my archives and am not able to find any sample code for you. I don‟t know

that I‟ve ever done this type of enhancement before.

I do know that you need to be working with program SAPLV60F. The

USEREXIT_FIELD_MODIFICATION you want is in RV60FUS4. I don‟t know that

you can use that userexit to gray out the credit card fields on the Header Payment Card

Screen or not though. It may be that you need to place an Enhancement Point somewhere

in the Screen Flow logic of screen 4204 instead.

Let me know if that helps at all.

Regards,

Eric Bushman

Paymetric

Reply

Alex June 6, 2013 at 4:26 pm

Hi Eric,

I have a question for you. Please take a look at the scenario

Paymetric has been implemented and the incoming files are being processed successfully.

However in some cases we need to reverse the payment back to the credit card of the

customer.

Can you tell me how to go about it?

Reply

Eric Bushman June 6, 2013 at 4:50 pm

Alex,

If you need to reverse a Settled credit card transaction in SAP (either because the

transaction was rejected, fraudulent or for some other reason was not funded), SAP

provides transaction FBRC to accomplish this. The result of running transaction FBRC is

that the payment is reversed from the Settlement Pre-Cash GL account and the original

Accounting Document is re-opened to reflect the liability on the customer account.

You can find a deeper discussion about this topic here:

http://www.sapfans.com/forums/viewtopic.php?f=10&t=146720.

Regards,

Eric Bushman

Paymetric

Reply

Jshah January 3, 2013 at 4:49 am

Hi Eric,

we have recently Implemented Sales Payment card Functionality in our Company.

We have came across following problem.

We are using a Document type ZYO( Sales order) for the all the customer , and same

document type for the Sales Payment card as well.

We have also created New Payer group(4050) and assigned Pyment procedure to the

customer. So theoritically when Sold to Party Place an order with this Payer , Payment

card tab should appear at Document level.

We tested it and it appears there but at the same time if sold to party place an order with

different payer (non- Payment card payer) with using the same order type , Payment card

tab is also appearing there.

I have checked the customer master account for the payer there is not payment gurantee

procedure assigned there still Tab appears at doc header level.

Business wanted this tab to be suppressed for NON payment card customer?

What could be the soultion for this?

Awaiting for your reply.

Reply

SAPGuy January 5, 2013 at 5:00 am

Hi Jitesh

My initial questions would be:

Why is your company afraid of displaying the blank Payment Card tab on the order?

What is the perceived risk?

Only authorized people should be able to create/change/display information on this tab

anyway.

The bad news is that there is no standard way of suppressing this tab.

Once you activate the payment guarantee procedure for the Document Type (ZYO in

your case), it automatically activates the display of the Payment Card tab for the

document type. It does not depend on whether the customer is also activated. The

reasoning is that it allows the user to manually add or change payment cards on the order,

irrespective of whether there was a payment card on the customer.

I can give you 3 options for achieving this:

Option 1: The simplest way is via Authorizations (speak to your SAP Authorization

person if you do not know anything about SAP authorizations)

The authorization object that controls user activities related to payment cards on the sales

order is V_VBAK_AAT. The authorization object that controls user activities related to

payment cards on the invoice is V_VBRK_PKA. The different kinds of activity that can

be controlled are:

Activity = C1 Controls ability to create/change credit card info.

Activity = C2 Controls ability to display credit card info

Activity = C3 Controls ability to enter manual authorizations

I do not believe this will suppress the payment card tab (I may be wrong – you may want

to test this), but the user will not have any authorization is create/change or display the

information. This does not give you exactly what you are looking for, but it may address

the concerns your company has.

Option 2: Suppress the Tab via ABAP user exit This code should not be too complex. It is simply a header level check against the

payment card configuration of the customer and then the code would suppress or display

that tab based on that check.

Option 3: Using GUIXT and Input Assistant I only recommend this if you are already using GUIXT and Input Assistant. This is a

bolt-on produced by Synactive used to simplify and changes SAP screens. The free

component GUIXT is already packaged with all SAP versions since 1999. This would

also require the paid module called Input Assistant. It would apply a similar logic to

Option 2. It is designed specifically to work with SAP screens and makes these changes

much more rapidly than using ABAP.

Hope that helps. Let me know what solution you come up with.

Regards

Paul

The SAPGuy

Reply

Eric Bushman January 5, 2013 at 9:48 am

Jitesh,

Paul has already responded with some excellent information and included what I would

have initially responded with:

“Once you activate the payment guarantee procedure for the Document Type (ZYO in

your case), it automatically activates the display of the Payment Card tab for the

document type. It does not depend on whether the customer is also activated. The

reasoning is that it allows the user to manually add or change payment cards on the order,

irrespective of whether there was a payment card on the customer.”

SAP decided to allow the Payment Card fields on the Sales Overview screen and the

Payment Card Header Tab to be visible based on the document type. So if you‟ve

configured a certain document type to allow payment by credit card then those fields and

tab will be visible on every document of that type regardless of the partners on the

document.

There is a little used configuration technique that you could apply here, but it isn‟t

something I usually recommend because it can be extremely cumbersome to maintain. It

has to do with the “Define Payment Guarantee Schema Determination” configuration.

You‟ve mentioned already that you have setup a Document Determination Schema that is

assigned to document type ZYO. And you also said you “assigned Pyment procedure to

the customer” so you have a Customer Determination Schema configured and assigned to

customers as well. You can now limit which customers can pay by credit card by setting

up the proper Payment Guarantee Schema Determination.

Normally in that configuration step you‟d see the following (assuming a Customer

Determination Schema of „ZCPG‟, a Document Determination Schema of „ZD‟ and a

Payment Guarantee Procedure of „ZPAYME‟):

Cust Doc Payment Guarantee Procedure

BLANK ZD ZPAYME

ZCPG ZD ZPAYME

The first entry, where the Customer Determination Schema is left BLANK, is added to

allow for ANY customer(partner) to pay by credit card so long as the document has the

„ZD‟ Document Determination Schema associated with it in configuration. If you were to

remove that entry then only customers(partners) with the „ZCPG‟ Customer

Determination Schema on their Customer Master Record would be able to pay by credit

card. And specifically it must be the Payer Partner on the order that has that „ZCPG‟

Customer Determination Schema on their Customer Master Record.

The reason I don‟t typically recommend that is because you must manually maintain the

„ZCPG‟ Customer Determination Schema on their Customer Master Record on every

customer that should be allowed to pay by credit card. All other customers can not pay by

credit card. However, if that is what you‟d like to enforce then this is the best way I know

how to do so.

Regards,

Eric Bushman

Paymetric

Reply

Sarang Gujrati December 6, 2012 at 2:10 am

Hi Eric,

Sorry I dont know whether this blog is still active or not.

I am facing one problem with credit card authorization.

At the time of Sales order creation, we would like to know if we can check whether

customer credit card has authorization for the sales order amount.

The reason behind to this is that we are calling 3rd part interface to determine plant and

inventory.

So if system fails to get authorization then we have to reverse whole order back to intial

point.

so if I can determine authorization before calling the 3rd party interface then we dont

have to go through the reversal process.

Thanks,

Sarang

Reply

Eric Bushman December 6, 2012 at 9:49 am

Sarang,

SAP‟s business logic determines the amount for an Authorization request based on the

Material Availability Dates on schedule lines. If a line item on a Sales Order is in stock

(ATP) and has a Material Availability Date within what SAP calls an “Authorization

Horizon” (this is configured in the IMG – I suggest it be set to 3 days) then the amount of

that line item will be added into the Authorization amount to be requested.

So if your ATP checks are accurate and your stock is up-to-date then SAP will

automatically request an Authorization for the amount of the items that can ship in 3

days.

If you would prefer to force SAP to request an Authorization for the full order value

instead of relying on the business logic described above you can also do that by adding

code to userexit AUTHORIZATION_VALUE_SPLIT in program MV45AFZH. You

basically force SAP to include the full amount of all line items whether they can ship in 3

days or not. However, I generally advise against this.

Hopefully that answers your question. If not please let me know!

Reply

Sarang Gujrati December 20, 2012 at 9:29 am

Sorry Eric for the delay in reply. I was struck with some other issues.

Thanks for the detailed explaination. It is really helpful. Your explanination gave us very

clear picture what is actuaaly happening in the system.

Thanks once again.

Right now we are facing issues with CRM. Orders replicating from CRM in ECC are not

calling MV45AFZH user exit.

Not able to understand why.

Reply

Eric Bushman December 20, 2012 at 10:07 am

Sarang,

It has been a while since I‟ve debugged the replication of Sales Orders from CRM to

ECC. However, I seem to recall that SAP doesn‟t use the same code flow in SAPMV45A

that is used when you create orders via t-code VA01 in ECC.

What are you hoping to do with userexit MV45AFZH when replicating from CRM to

ECC? If you‟re trying to affect the authorization amount I‟d suggest you do that in CRM

before the replication happens.

I suppose I should also ask, have you configured your CRM system to perform

authorizations? Or did you setup your system to send the orders from CRM to ECC and

have the authorizations take place in ECC?

Regards,

Eric Bushman

Paymetric.

Reply

Sarang Gujrati December 20, 2012 at 12:10 pm

Thanks for the reply..

We are trying to split authorization in MV45AFZH

(AUTHORIZATION_VALUE_SPLIT) by using ZUKRI field .

Plant and other spliting criteria are determined by ECC only. Order first takes single

authorization in CRM then comes to ECC.

We want then to run our code written in MV45AFZH .

When we create order in ECC spliting code works perfectly but not in the case of

replication from CRM.

Please advise..

Thanks,

Sarang

Eric Bushman January 2, 2013 at 2:06 pm

Sarang,

I‟m not able to respond to your most recent response for some reason, so I‟ll respond

here.

CRM has different logic that is similar to MV45AFZH, but I can‟t recall off-hand what it

is. As I recall it is one of the BADIs that is available in the IMG. You‟d need to create

similar logic in that BADI for orders created in CRM.

I hope that helps.

Regards,

Eric Bushman

Paymetric

Sarang Gujrati March 18, 2013 at 4:34 am

Hi Eric/Paul,

We need to check/validate credit card authorized amount before saving the sales oder. Is

there any way or any function module which we can use in user exit MV45AFZZ

(Save_Document_Prepare.

Thanks,

Sarang

Eric Bushman March 18, 2013 at 9:19 am

Sarang,

The best approach for checking the authorized amount before the order is saved is to

create a userexit in the configuration for the Authorization Function call. In

configuration, where you specify the Function and RFC Destination for Authorization

you can call a „Z‟ function module that you create.

In that „Z‟ function you can have a “Pre Authorization” and “Post Authorization” userexit

in which you can perform any activity you‟d like. You would call the External

Authorization function between the two. In the “Post Authorization” routine you can

check the response and determine what action to take.

Alternatively, you could use USEREXIT_SAVE_DOCUMENT. The Payment Card logic

is called AFTER USEREXIT_SAVE_DOCUMENT_PREPARE and BEFORE

USEREXIT_SAVE_DOCUMENT.

Regards,

Eric Bushman

Paymetric

Tariq Bashir November 14, 2012 at 5:05 pm

Dear Mr. SapGuy:

I have been working in the credit card/payment industry for 10 years now & been

responsible for daily authorization transactions edits and processes. I making an serious

effort to move my career towards SAP based platform. Do you think that my backgroud

will help me understanding SAP if yes the which SAP module? And last any company

that you are aware of that uses SAP in credit card / payment industry?

Regards,

Tariq Bashir

Reply

SAPGuy December 6, 2012 at 8:30 am

Hi Tariq

Sorry for the delay in the reply. I have been traveling.

Having a solid background in the credit card industry is a huge advantage. The credit card

functionality is primarily in the Sales and Distribution (SD) module with parts in the

Financial (FI) module.

The majority of companies that use SAP use credit card functionality. Many companies

also use a bolt-on such as Paymetric to supplement the SAP functionality (see my

previous articles). But there are a few other vendors (who I have never worked with) as

well.

I wish you good luck.

Regards

The SAPGuy

Reply

Donna June 6, 2012 at 4:44 pm

Is anyone getting authorization for a Payment Card on the CRM Side for a Credit Memo?

We get authorization on the ECC Side for the Credit Memo but not the CRM Side. I‟m

not sure if this is related to our Paymetric Implementation or CRM.

It is causing an extra step on the ECC Side. We need to touch every Credit Memo in ECC

to get an Authorization.

Any information is appreciated.

Thanks.

Donna

World Kitchen

Reply

SAPGuy June 6, 2012 at 5:43 pm

Hi Donna

It has been a long time since I touched CRM. However, as I recall (I may be wrong), the

authorization for CRM is a call to R3. I want to refer this to a colleague at Paymetric.

Regards

Paul

Reply

Eric Bushman June 6, 2012 at 5:56 pm

Donna,

SAP CRM has it‟s own connection to Paymetric via the Cross Application Payment Card

Interface (CA-PCI) for Authorization. SAP CRM also should “authorize” a CREDIT

amount just the same as it does for a DEBIT amount.

I‟ve helped other SAP customers setup the functionality in CRM and never seen the

problem you‟re describing. Perhaps the document type isn‟t configured for Payment Card

Processing in CRM? Has it ever worked before in CRM or is this a new implementation

of CRM for World Kitchen?

Regards,

Eric Bushman

Paymetric

Reply

Donna June 7, 2012 at 3:54 pm

Hi Eric,

It has never worked in CRM and we are working on a project to reduce additional

unnecessary steps.

The document type is configured for payment card processing in CRM… I did check

that. PaymtPlan Type is 03 Payment Card and Checking Group is 01 Standard.

All other payment card authorization works.

Thanks.

Donna

Reply

StanS May 22, 2012 at 10:55 am

Hello,

I have an issue after XiPAy has successfully preauthorized a credit card, the invoice

cannot be posted/cleared successfully in SAP, even manually. I‟m a security consultant,

so please forgive my lack of understanding of the process.

It seems that some transactions fail and the AR person can pull them in manually from

XiPay and clear the invoice in SAP/successfully posting the charge. However, some she

tries will not ever process successfully. The ST01 SAP authorization trace is not very

helpful, as the RC=0 for all objects checked. In a QA environment the AR user with

SAP_ALL cannot make these particular charges post. Any idea how I can futher

troubleshoot the process?

Many thanks!

Stan

Reply

Suzi February 8, 2012 at 12:58 pm

I have a question about the $1 preauth.

We have set our authorization period for 7 days so no order will be authorized until it is

within 7 days prior to the requested delivery date. However, we are having an issue with

orders that are only obtaining a $1 preauth even though the start date is within 7 days or

even immediately.

We have put in a user exit to use requested delivery date rather than material availability

date since we use AFS and allocation will go out further than the delivery window

designated on the order. Therefore, in case other materials are allocated they can then be

delivered since we are authorizing the entire order amount.

What can we do to correct SAP from only obtaining a $1 preauth and not authorizing the

entire amount of the order plus the percentage we have added for freight costs?

Our business users are getting very annoyed that the functionality is not working as

expected.

Additionally, when VFX3 or VCC1 are being run, they are not picking up orders and

deliveries whose authorization has expired. Very frustrating. Any suggestions?

Reply

Eric Bushman February 9, 2012 at 11:00 am

Suzi,

In which userexit did you add code to have SAP consider the Requested Delivery Date

instead of the Material Availability Date when determining if the amount of a line item

should be included in the Authorization Amount? I‟d like to have a look at that in one of

my systems to see if the timing sequence of that userexit and the SAP logic to build the

Authorization request are in the correct order.

If you want to FORCE SAP to always send an Authorization Request for the FULL order

value plus the additional percentage you add to account for freight you can do that in the

AUTHORIZATION_VALUE_SPLIT userexit (program MV45AFZH – the same one

where you‟re adding in the percentage for freight). You simply change the same amounts

that you‟re adding a percentage too, or, in the case where a line item was EXCLUDED,

you add a new entry in table OPEN_VALUES to account for that line item.

VFX3 and VCC1 will only pick up documents where SAP has already indicated that an

Authorization is expired. If the Authorization is expired, but you haven‟t tried to create a

subsequent document yet then SAP doesn‟t “know” that the Authorization is expired yet

because that status isn‟t set until you attempt creation of a subsequent document. To

address that we‟d suggest you schedule our “Expiring Payment Card Authorizations”

report to run daily. This report pro-actively identifies expired transactions and resaves the

Sales Order that transaction is associated with so that SAP can attempt a new

authorization.

Reply

Suzi February 9, 2012 at 11:15 am

We added our user exit in AUTHORIZATION_VALUE_SPLIT userexit (program

MV45AFZH) as recommended by our consultant from Paymetric, Bill. It works

sometimes but sometimes it does not which makes it very difficult to determine why.

During our testing before implementation, it worked as expected but then last summer

started sporadically only authorizing $1 on some orders with immediate start dates or

start dates within the 7 day period we configured. I know the common rule is to use

material availability date but since we use AFS and our allocation settings go out beyond

the 7 days, we changed it to use requested delivery date instead. It worked fine in testing

and seemed to be working okay up until last summer when it started only authorizing $1

on some orders with immediate start dates or that were within the 7 day time frame we

configured to authorize within. Any advice is greatly appreciated.

Reply

Eric Bushman February 9, 2012 at 11:50 am

Suzi,

Will you email me the code from MV45AFZH in a text file so I can review it? You can

send it to ebushman@paymetric.com.

As you‟re likely aware, the $1 preauthorization is what SAP will attempt if it is

determined that NO line items fall within the 7 day window of the Material Availability

Date (or in your case the Requested Delivery Date). So apparently SAP doesn‟t think the

line items are eligible.

I‟m guessing, that since you are changing which date to look at in the userexit, SAP may

have already built the OPEN_VALUES tables entries based on Material Availability

Date and that may be too late in some cases to switch to Requested Delivery Date.

Having a look at the code will be helpful!

Reply

Eric Bushman February 19, 2012 at 5:27 pm

Suzi,

I wanted to post on here, for the benefit of others reading this post, the resolution which

together we found for one of the issues you were experiencing – that of SAP requesting

multiple authorizations when you saved a Sales Order instead of just a single

authorization.

It turned out that it was a bug in the code in userexit

AUTHORIZATION_VALUE_SPLIT in program MV45AFZH where you were

overwriting the Material Availability Date with the Requested Delivery Date. The field

that was being overwritten was OPEN_VALUES-SPTAG. That is fine, but because the

date in OPEN_VALUES-FKDAT was not being changed also that caused SAP to

generate multiple Authorization Request lines in Function Module

SD_CCARD_PERFORM_AUTHORIZATION.

It came down to a COLLECT statement in Function Module

SD_CCARD_PERFORM_AUTHORIZATION that would create multiple authorization

lines whenever the OPEN_VALUES-FKDAT value was different from the

OPEN_VALUES-SPTAG value. Once we set OPEN_VALUES-FKDAT to the same

value as OPEN_VALUES-SPTAG the issue of multiple authorizations was solved.

Obscure, but understandable why it was happening once we debugged the issue.

Whether this also solves the issue of the $1 pre-authorization or not remains to be seen.

But let me know if you run into that again and we‟ll have another look.

Eric Bushman February 20, 2012 at 8:05 pm

Suzi,

Another update regarding the solution we found today for the $1 preauthorization issue. It

turned out that the configuration in PRD was different than the configuration in DEV &

QA for some reason.

The Authorization Horizon configured in DEV & QA was set to 7 days, but in PRD it

was set to 1 day. That meant that an item had to be in stock and available to be delivered

within 1 day from the current date in order for SAP to include the amount of that line

item in the Authorization Request.

The resolution was to send a transport of the correct setting of 7 days to PRD. Once that

is transported you should only see $1 preauthorization requests when there are no items

on the sales order which are in stock and available to ship within 7 days.

Jennifer Radden January 24, 2012 at 6:33 pm

Hi Nafran –

Almost all of Paymetric‟s customers integrate SAP with Paymetric via web services

using SAP‟s standard payment card interface (Cross Application Payment Card Interface)

which Paymetric is certified with. I would be happy to discuss this with you or provide

you with documentation.

Thanks,

Jennifer Radden

jradden@paymetric.com

Reply

Cheryl December 5, 2011 at 9:15 am

Hi we have been using Paymetric for a number of years but are now implementing an

ECommerce solution. Since our shipping cost vary so widely we have been using Auto

AR to Authorize our orders (the credit card is retrieved from the order in the appropriate

exit). the problem is that when using the Auto AR functionality the authorization no

longer carries the Ecommerce indicator found in FPLT-CSOUR. Is there an exit that can

resolve this issue – or is my only solution to raise the authorization amount and to do an

immediate authorization (ie – not use Auto AR) ?

Reply

SAPGuy December 14, 2011 at 7:55 pm

Hi Cheryl

I know this indicator is used a lot these days. The merchant factor it in to assess the risk

which in turn affects the CC fees

I have not worked with the ECommerce indicator. I assume that you are setting

something on the order to indicate this order came from the web. I have seen it done a

number of ways. We have an order source field (VBKD-BSARK) at my current

implementation and one of the values is “WEB”. There is another field that is not visible

on the screens on VBAK (I believe it may be VBAK-LOGSYSB) that also indicates the

Order source. This is used by CRM for example to show that the order originated in

CRM.

Using Auto AR seems to be a logical solution way of dealing with the varying shipping

costs.

We implemented a user exit to retrieve a profit center in Auto AR. I believe the exit we

used was ZPCCC_CUSTOMER_AR_AUTO_EXIT_RI. If I recall correctly, you have to

activate it first in Table: /PMPAY/PUSREX.

There are also a few SAP notes that refer to it.Tip: Don‟t limit your search to your

current version. I often can find earlier notes, that while not relevant to your current

version, give me a some insight on a potential solution and where to look. Some possible

search terms are: ECI, E-Commerce, E-Commerce indicator.

Hope that helps. Let me know what your final solution is.

Thanks

The SAPGuy

Reply

Cheryl December 15, 2011 at 8:03 am

Thanks for replying! We did come up with a solution. I altered the user exits for pre-auth

by accessing a field from the calling program of the function module. I‟ve included the

code below if anyone else needs this. In addition it was also necessary to alter the pre

settlement user-exit to find the VBAK-BSARK and set the ecommerce flag. (code also

below)

The reason we did not use the methodology of inflating our authorization to cover the

freight was that the processing bank told us this would result in penalties if the

authorization did not match the settlement amount exactly.

Code for pre-auth

" The following assignment will only work

" when called from the Auto AR Program

lv_temp = '(/PMPAY/PRE_AUTO_AR)it_open_items_selected-vbeln'.

clear: lv_vbeln, lv_bsark.

assign (lv_temp) to .

if sy-subrc = 0.

create object lor_socc.

lor_socc->get_sales_order_for_invoice(

exporting

i_invoice =

importing

e_vbeln = lv_vbeln

exceptions

no_sales_order_for_inv = 1

others = 2

).

" Continue with the logic if the Sales Order is found for the

Invoice

if sy-subrc = 0.

" The PO Type is set to ECOM from the Web Site

select single bsark into lv_bsark

from vbak

where vbeln = lv_vbeln.

check lv_bsark = 'ECOM'.

loop at it_ccaut_in.

* condition for identifying AutoAR WebOrders and set 'E'

if lv_bsark = 'ECOM'.

it_ccaut_in-csour = 'E'.

modify it_ccaut_in.

endif.

endloop.

endif.

endif.

**** Settlement function module changes

**** Coding for Web Orders Processed via Auto AR

**** These transactions must have the CSOUR set = E. We do this based

**** on the value of the BSARK (PO Source) on the original order

loop at it_settab assigning where bukrs = '0003'.

clear l_invoice.

select single belnr into l_invoice

from /pmpay/parcl

where rebzg = -belnr

and rebuk = -bukrs

and rebzj = -gjahr

and buzei = -rfzei.

check sy-subrc = 0.

" Find the sales document for the Invoice and check the BSARK for

" ecommerce (Only the first line item is checked !)

clear l_bsark.

select single bsark into l_bsark

from vbrp inner join vbak on vbrp~vbelv = vbak~vbeln

where vbrp~vbeln = l_invoice.

" if the order is not found or it does not have po source = ecomm

exit

" otherwise update the ecommerce source flag

check l_bsark = 'ECOM'.

-csour = 'E'.

endloop.

Reply

SAPGuy December 15, 2011 at 8:53 am

Hey Cheryl

Glad you found such an elegant solution and thanks for sharing it.

Regards

Paul

Reply

subrata November 25, 2011 at 4:13 pm

Hi Paul,

When payment cards settle, there should only be 1 batch per day per G/L Account.

Since go live, we are seeing up to 3 batches per day settle. We only want to have 1 batch

settle each day with the bank.

If this continues, we may be charged an extra service charge by the bank for multiple

batches per day when there should only be 1.

Regards

Subrata

Reply

Anthony September 15, 2011 at 10:53 am

Thanks Paul. We have considered the “authorization inflation” approach and even have

the user exit coded, but haven‟t implemented. We may yet use this approach.

Coincidentally, we just recently received this not about VOID transactions that may work

for us as well. Of course this creates a possibility of voiding X amount, then authorizing

Y amount and getting declined – now you have no authorization.

Implementing Voids from SAP The Void operation is performed by making a call to the external Void Function Module

from the desired SAP program or user exit. Potential uses cases for voids include when:

The Expiration check function module is called and an authorization is marked as

expired

An order is canceled

An order is deleted

An authorization is deleted

An order amount changes

In lieu of performing a DELTA authorization in SAP, Void the original Authorization

and create a new one for the correct amount. If supported by your chosen Processor and

the Card Issuer, the Void operation makes a call to the Processor and the original

authorized amount is added back to the available credit amount in real-time. Please refer

to the Cartridge documentation for your chosen

Processor to confirm if real-time voids are supported. Otherwise, the transaction is

marked in the XiPay database so no further processing occurs and the funds are made

available once the authorization horizon has passed.

Following are the high-level steps to configure PAS and SAP for voids with XiPay:

1. Create a new RFC Destination for Voids in SAP via transaction code

SM59 with the appropriate security.

a. If needed, see XiPay SAP Integration Guide, Install and Initial

Setup Set Up RFC Destinations in SAP for detailed instructions.

2. Create a Void XAS Program in the PAS GUI.

a. If needed, see PAS Install and Config Guide, Configuration XiPay

Programs for detailed instructions.

3. Create a call to an external Operation called 'XIPAY_CC_VOID' per

the following example and implement your own security objects as

needed.

A call should be made from each user exit or program for which you are implementing

the Void Operation.

Reply

SAPGuy September 26, 2011 at 7:18 pm

Hey Anthony

That is pretty cool. Must be some new functionality, because it certainly was not there

last time I work with PM.

Thanks for sharing that.

Regards

Paul

The SAP Guy

Reply

Anthony September 8, 2011 at 3:26 pm

Hi Paul,

We have been using Paymetric for the past 18 months and have been happy with it. I

have a question that is not Paymetric specific, but CC processing in general. We get a CC

authorization for the scheduled shipment amount at the time the order is saved. But, we

also charge actual shipping costs, in some cases, which are not known until the order is

shipped and PGI‟d. This creates a billing block. We have a process that automatically

gets authorizations for these orders and release them. All well and good.

The problem we are having is that now the customer sees two (or more) charges on their

credit card bill, and in certain situations the billing can really look odd. For example, an

order is authorized for $100, but only $95 ships, and there is a $15 shipping charge

added. The total invoice will be for $110 so an additional $10 authorization is needed.

The customer now sees a $100 charge and a $10 charge. Is there any way that you know

of where the two authorizations or settlements can be combined so that that the customer

only sees one charge of $110?

Thanks,

Anthony

Reply

SAPGuy September 15, 2011 at 8:09 am

Hey Anthony

Apologies for the late reply. I have been on vacation.

We had a similar issue at a client. The way we dealt with it was as follows:

We calculated the maximum freight an order was likely to be charged as a percentage of

the order value. So for example: We calculated that no order would ever have freight

charges exceeding 10%. Then instead of authorizing a $100 order for $100, we would

authorize it for $100 + 10% = $110. That way you only have one authorization. I would

not hardcode that 10%. I would rather put it in a TVAR variable (TCode: STVARV) or

alternatively if you have a good pricing person, save it in a statistical pricing condition.

This way you can refine it on the fly without having to do code changes. Obviously, this

is a user exit.

To answer your question though, it is not possible to “combine” 2 different

authorizations. You cannot use authorizations more than once either. For example: if you

have payment plans (typically used for projects) you have to get a new authorization for

each settlement.

Another way you might be tempted to “combine” authorizations would be to simply

ignore the 2 authorizations and get a new authorization for the whole amount via a user

exit at billing or settlement. As I am sure you know (but it is worth mentioning for other

readers), this would create further issues for the customers. While you would only get one

charge appearing on customer‟s credit card which would use up the new authorization,

the original 2 authorizations would still “consume” the customers available credit on that

credit card until those authorizations expire (7 days to 30 days, depending on the card).

Hope that helps.

Regards

Paul

Reply

Prachi September 9, 2012 at 1:38 pm

Hi Paul,

This is an interesting blog. Thank you!

I seek your inputs for dealing the situation with respect to

additional authorization for Freight amount in the sales order.We use Paymetrics for our

credit card processing.

Our calculation is that no order would ever have freight charges exceeding 10%, so this

value has been hard coded in MV45AFZH.

While saving sales order, if the order value is $100, then our order is authorised with a

total value of $ 110, but we have TWO DIFFERENT authorization lines – one for $100

and one for $10.

During PGI actual Freight was say $4.

So my Billing document-.Header->Payment Card has two lines:

Billing Val Authorized Amt

Net val auth 100 100

Frieght auth 4 10

When I pass this data for Settlement using ZFIPMFCC1 transaction (delivered by

Paymetrics – copy of std FCC1)

I am sending above two lines and hence Customer sees these two lines/charges in his

credit card statement.

So, as of today my customer‟s credit card statement shows:

Reference Billing dt Billing amt Curr

Billindoc#7100000000 06/26/2012 100 USD

Orde#XYZ 06/26/2012 4 USD

Is there any method by which, the customer‟s credit card is charged only once (so that he

sees only one charge item of $104)?

You suggestions would be appreciated. Thank you.

Reply

SAPGuy September 9, 2012 at 4:04 pm

Hi

Is there a reason that you are creating 2 authorizations?

Typically, we would do 1 authorization for say $110 in your example. You are basically

inflating the value that you submit for the authorization. Instead of submitting the order

twice for authorization, you are only submitting it once for $110.

Now, say the actual freight was only $4.

Now your billing document is for $104.00 and thus you have a single settlement for $104

(as you have a single authorization that is more than the $104).

Regards

Paul

Reply

Prachi September 9, 2012 at 4:21 pm

Hi Paul,

We submit the sales order only once for authorization. Which, creates one line for USD

100 (order net value) and another line for USD10. (to cover 10% for freight).

So I am not inflating any value but just covering for my freight that is not known until

PGI.

Is there a way/exit I can combine the two authorizations on a single line in sales order

itself?

Prachi

Ron April 20, 2011 at 9:23 pm

Hi Paul,

Your posts are quite informative.

We have requirement to implement Credit card functionality. My primary question is –

can it be done without 3rd party tool (ex: paymetric) ? Why do we need 3rd party tools ?

Thanks for publishing useful information.

Regards,

Ron

Reply

SAPGuy April 26, 2011 at 8:07 am

Hi Ron

Besides some of the gaps mentioned in this article, a big reason to use a 3rd party vendor

is the certification of the interface to your credit card provider (See this post for more

information).

Is it possible to do it yourself? Absolutely. But, I would suggest you build a dedicated

team of business, functional and developers to do it. It may take you a whole lot longer to

do it than you think. You will also have to deal with the legal ramifications of securing

your credit card information (See this article for a brief introduction).

At the end of the day, I think you will discover that the costs are a lot more than you

think. Much the same way as almost no companies in the USA try to maintain their own

tax rates in SAP (they all use a tax solution such as Vertex or Taxware that does monthly

updates to account for tax changes), I would recommend the same strategy with credit

cards (use a solution such as Paymetric). In my opinion, it is just not worth it doing it on

your own.

Hope that helps.

Best Regards

Paul

The SAPGuy

Reply

SShr April 11, 2011 at 2:04 pm

Hi Paul

Does Paymetric functionality work with noted items? We are still prototyping milestone

type orders and the first step is to create a noted item for downpayment request. if the

credit card info is stored in sales order. Will it automatically settle and change to a

downpayment. I tried creating a request using F-37 and tried using paymetric receivables

Tcode and it doesnot show that particulatr item in open items list!

Reply

SAPGuy April 11, 2011 at 3:32 pm

Hi Sangeet

Couple of things here.

Not familiar with the terminology “noted items”. I assume a down payment is an example

of a noted item. If you are processing down payments in SD, you are making use of

Billing Plans.

Processing Down Payments & Payment Cards in SD

SAP Limitation Standard SAP cannot handle periodic payments with Credit Cards (periodic or milestone

i.e. Progress Billing). It gets the authorization on the order and the first time it bills, it

uses that authorization up. The authorization can only be used once. It does not have the

ability to go back and get another authorization for the next payment on the order.

Additionally, SAP tries to authorize the whole amount instead of only the relevant

payment. Example: 10 Progress Bills of $10,000 over 10 months. SAP would try to

create an authorization for $100,000 instead of only $10,000.

Paymetric Solution is AutoAR. How does AutoAR work? It is actually very similar to Paymetric Open AR. It also runs post billing. However, it

fetches the CC information from the Sales Order, gets an authorization and processes it as

an incoming payment and clearing document.

User Exits in the order and how it works All the magic happens on the order. When a user enters a credit card on the order that has

items that are relevant for Billing Plans (SAP‟s term for Progress Bills), it does 2 things:

Applies a unique Payment Term – “ZAUT-Paymetric Auto AR” for example

It removes some indicators that allow the item to process to billing as a normal

AR (as opposed to billing by CC).

Now when we run the Auto AR Program, we filter by payment terms of ZAUT.

Therefore, Auto AR shows a list of Progress Bills that have already been invoiced. The

Auto AR Program then fetches the credit card information from the sales order, gets a CC

authorization and processes it as an incoming payment & clearing document. This must

now also be settled.

A useful SAP Note 313416.

Processing Down Payments & Payment Cards in FI Processing via F-37 will probably not work. If you review even the standard SAP

programs, they all get information from the order.

Your only option here is to use the Paymetric Open AR module.

Hope that gives you some direction.

Regards

Paul

The SAPGuy

Reply

SShr April 26, 2011 at 1:42 pm

Sorry for replying late. Thank you for all the pointers.

To your question – “I assume a down payment is an example of a noted item”. This

actually is not. Noted Items are ones that are not real financial entries (for example –

Downpayment requests- from sales point it is type – FAZ). These noted items change to

an actual downpayment only when payment is applied. Paymetrics pay open AR

transaction does not show these as open items even though they are in open AR table.

F110 transaction pulls these once special GL indicator is included in the config. Probably

we need to approach paymetrics for solution?

Reply

SAPGuy April 26, 2011 at 5:01 pm

Hey Sangeet

Interesting. I have done some prototyping with down payments quite a while ago, but we

never ended up using them. They decided to process them through FI.

I think your best bet is to approach Paymetric for a solution. I would be curious to hear

what your final solution is.

Regards

Paul

The SAPGuy

Reply

GopiKrishna April 5, 2011 at 5:58 pm

Hi Paul,

We have implemented payment cards through XiPay which works well when we

authorize the payment card at sales order level. However due to business need I had to

pre-auth $1 at order level and then get an actual auth at delivery level , I tried the user

exit but I am stuck with an issue.

Teh problem is that when I call SD_ORDER_PAYMENTCARD_AUTHORISA before

creating delivery it clear some values such as sship to party and the system is unable to

generate a delivery because of that.

I would appreciate if you can let me know if there is any similar issue you faced and any

possible solution.

Reply

SAPGuy April 7, 2011 at 3:05 pm

Hi Gopi

I am sorry. I have not run into this problem. There are 2 ways I would approach this

issue:

Configure the Payment Card authorization to Authorize the card 0 days before

delivery. Schedule the authorization before the delivery due list runs every day. That way

you are using standard functionality.

Create the delivery. On save, call the authorization routine. If the authorization fails, it

will block the delivery. The blocked delivery will appear in the Credit Reps Worklist

(TCode: VKM1)

You could also approach Paymetric and ask them for an old document they have:

“TEC900-005 – Authorization During Delivery Creation Guide.pdf”. It may not be 100%

valid today, but it may give you some ideas.

Hope that helps.

Regards

The SAPGuy

Reply

Keshini March 3, 2011 at 2:34 pm

Hi,

Nice Article. Very informative.

We are planning on implementing payment cards and will work on Paymetric on this as

well.

However i have configured the standard payment card functionality in SAP(Using

function module provided by SAP to test authorizations), and would like to know

whether its possible to authorize the credit card for the value at the delivery save. The

authorization should only cover the value in the delivery and not the amount on the sales

order.

Appreciate if you could please let me know if its possible?

Reply

SAPGuy March 5, 2011 at 10:13 pm

Hi Keshini

Interesting question.

Let‟s first consider what the standard behavior is. A pre-authorization is done when the

order is created. This is usually for a small amount such as $1. It is just to make sure that

the credit card is valid and not blocked or reported stolen. Then depending on the settings

in your system, the real authorization takes place a certain number of days before the

material availability date (MAT). This is the date when the delivery can be created.

On delivery create, the system verifies that the authorization exists and is not expired.

This check also happens for a delivery change. Note, it does not apply for an

authorization on the delivery, it only checks if it has a valid one.

If the credit card authorization has expired, it will set the sales order authorized amount to

zero, set the delivery status to not approved and give you a message to reauthorize the

Sales Order. This can also happen if you change the quantity on the delivery to more that

the order (a setting on the delivery item category controls if you can do this or not).

Note that most of the action happens on the sales order. The CC information is not even

on the delivery.

Here are some classic issues that do occur.

The order is $200. The delivery is only for $100, the remaining $100 is on backorder.

You bill the customer for the $100 and it is settled via the credit card. Now you deliver

the remaining $100. When you invoice it, you get a message “Document 91…. saved

(faulty authorization)”. This is because an authorization can only be used once, even if it

is not fully used up. The only solution is to reauthorize the order for the remaining $100.

Back to your question. It can be done via a user exit. Bear in mind that the Payment Card

checks make use of the Credit Check functionality. The function module used to check

the credit from a delivery is SD_DELIVERY_CREDIT_CHECK. Look at TCode: oVA8

where you define the automatic credit checks for deliveries and orders. Find the check

used on the delivery. In the Checks section, you will see a User 1, User 2 and User 3.

These activate the call to user exits. The user exit for User 1 is found in program

LVKMPFZ1. The function module to call is

SD_ORDER_PAYMENTCARD_AUTHORISA. This should give you a clue where to

look.

I understand what you are trying to do and why. I would however challenge the business

with some questions such as:

1. Why are there so many orders that you cannot deliver fully? In other words, why so

many backorders?

2. If an authorization check fails on the delivery, what do you do now? You have already

allocated that delivery to ATP.

3. How long will it take to get a new credit card or authorization? Do you still want to

“hold” that inventory?

…

I am sure you can come up with half a dozen more

Hope this helps. Good luck.

Warmest regards

Paul

The SAPGuy

Reply

NAFRAN February 15, 2011 at 6:49 am

Hi ,

Interesting blog. But I have a question which I was trying to search the answer and got

into this blog. I would like to know the flowing

you have mentioned

“The solution comprises of a group of SAP programs (imported as a series of transports)

and a separate server called XiPay (actually server is a misnomer, it is actually a piece of

middleware that communicates with the payment processor). There is also an

encryption/decryption server which resides on the same box.”

this means we can use this with out PI . I mean my question is can this be implemented in

a normal R/3 system which does not use PI.

I tried to checking on any documentation and it seems its bit difficult to find any unlike

paypal‟s payflowpro where the documentation is readily available.

Thanks

Nafran

Reply

SAPGuy February 16, 2011 at 9:27 pm

Hi Nafran

Glad you enjoyed the articles.

The solution does not rely on PI at all. We did not have PI implemented in our system.

And in fact at my current client, they have Paymetric and do not have PI at all (we are on

4.7).

Hope that helps.

Regards

Paul

The SAPGuy

Reply

NAFRAN February 18, 2011 at 12:10 pm

Hi Paul,

Thanks for updating me with that info. since most web sites were saying Xipay was

connecting trough SAP PI. I wanted to know if this can really be used with out PI.

Thanks a lot for your info. btw is there any place you know where I can find some

documentation on this product .

Thanks

Nafran

Reply

SAPGuy February 19, 2011 at 8:30 am

Hi Nafran

Your best bet to get any up to date documentation is to contact Paymetric directly. I have

not worked with it for a while now and I have not worked with their new hosted solution.

Regards

Paul

The SAPGuy

Reply

Suzi February 21, 2012 at 9:31 am

Yes, once we retransported the correct value of 7 days, orders within the 7 day auth are

now processing as expected rather than getting the $1 preauth. Thanks again for your

help.