I have spent the past 5 months working with Paymetric’s solution for SAP credit cards and I must say I have been impressed.
I first came across Paymetric in 2002 when supporting Credit Cards from the CRM side and they have come a long way since then. I was impressed with their expertise at that stage but their solution was not as comprehensive as it is today.
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.
{ 24 comments… read them below or add one }
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
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) ?
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
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.Hey Cheryl
Glad you found such an elegant solution and thanks for sharing it.
Regards
Paul
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
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:
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.
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
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
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
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
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
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!
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
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?
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
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.
Hi Gopi
I am sorry. I have not run into this problem. There are 2 ways I would approach this issue:
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
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?
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
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
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
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
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