93

Working with Paymetric SAP Credit Card Solution

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.

Paymetric Solution

Paymetric Solution

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.

​The SAPGuy

SAPGuy
 

  • NAFRAN says:

    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

    • SAPGuy says:

      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

      • NAFRAN says:

        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

        • SAPGuy says:

          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

  • Keshini says:

    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?

    • SAPGuy says:

      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

  • GopiKrishna says:

    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.

    • SAPGuy says:

      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

  • SShr says:

    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!

    • SAPGuy says:

      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

      • SShr says:

        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?

        • SAPGuy says:

          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

  • Ron says:

    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

    • SAPGuy says:

      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

  • Anthony says:

    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

    • SAPGuy says:

      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

      • Prachi says:

        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.

        • SAPGuy says:

          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

          • Prachi says:

            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

  • Anthony says:

    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.

    • SAPGuy says:

      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

    • Matthew says:

      I’m hoping Eric would reply to this thread to let everyone know if they have completed this with any customers.

      Thanks,
      Matthew

      • Eric Bushman says:

        Matthew,

        Yes, there are several Paymetric customers who have implemented this functionality. As Anthony points out, this is something that should be implemented from a call in a Userexit as it isn’t supported by standard SAP functionality in any way.

        I think the most commonly used Userexit is USEREXIT_SAVE_DOCUMENT_PREPARE, but you could make the call from any Userexit or Enhancement Point that you would like.

        Regards,

        Eric Bushman
        Paymetric

  • subrata says:

    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

  • Cheryl says:

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

    • SAPGuy says:

      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

      • Cheryl says:

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

  • Suzi says:

    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?

    • Eric Bushman says:

      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.

      • Suzi says:

        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.

        • Eric Bushman says:

          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!

          • Eric Bushman says:

            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 says:

            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.

          • Suzi says:

            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.

  • StanS says:

    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

  • Donna says:

    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

    • SAPGuy says:

      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

      • Eric Bushman says:

        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

        • Donna says:

          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

  • Tariq Bashir says:

    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

    • SAPGuy says:

      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

  • Sarang Gujrati says:

    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

    • Eric Bushman says:

      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!

      • Sarang Gujrati says:

        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.

        • Eric Bushman says:

          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.

          • Sarang Gujrati says:

            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 says:

            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 says:

            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 says:

            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

  • Jshah says:

    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.

    • SAPGuy says:

      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

    • Eric Bushman says:

      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

  • Jshah says:

    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

    • Eric Bushman says:

      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

      • Alex says:

        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?

        • Eric Bushman says:

          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

  • Amit Mulay says:

    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

  • Lesley says:

    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 says:

      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.

      • Lesley says:

        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

        • Eric Bushman says:

          Lesley,

          My pleasure!

          Do you mind sharing how you automated the requests?

          Regards,

          Eric Bushman
          Paymetric

          • Lesley says:

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

  • Sharad says:

    Hi,

    Some great inputs given here about the CC functionally. Thanks to all of you!
    Our Business problem is that we have an Order which has two line items. Delivery and Billing with Accounting is made for the first Line item and latter the Delivery and Billing for the Second line item is made without accounting document. Per the process the Order will need an Authorization of CC for the amount of the second line item and then we can go to the change of billing document and release it into accounting.
    But for the here the CC is expired and the Business doesn’t have a New CC. They cannot cancel the Billing document and they want to close the second Billing document. Can this be done?

    Thanks in advance.

    • Eric Bushman says:

      Sharad,

      Sorry for the late response – I hope you’ve been able to clear your document already.

      The general process I recommend to “clean up” documents that are stuck in this kind of situation is to put a “dummy” manual authorization on the Sales Order. Just make something up. Then you can release your Invoice to Accounting.

      Here’s where it can get a bit tricky. You don’t actually want to send that to the clearinghouse so you need to disable the connection. Either temporarily change the RFC destination in transaction SM59 so that you’ll get an RFC error or use a custom version of FCC1 that allows you to only simulate the Settlement.

      Then you’ll then want to Settle that transaction in a batch by itself and then immediately use transaction FBRC to reverse the Invoice and put the liability back on the Customer AR account.

      Once you’ve reversed the document you can choose how to collect on it or you can choose to write it off.

      Good luck!

      Eric Bushmam
      Paymetric

      • Matthew Fee says:

        Sharad,
        What our company does in situation is apply a business card on the order, so we can clear the invoice.
        This means the business rights off the loss, but as a trade-off we are not disabling any RFC connections and possibly interrupting credit card processing for everyone else in the company.

        Thanks,
        Matthew Fee

  • Tariq Bashir says:

    Hi Leslie-
    We use an edit to allow credit card transactions to come in for a decision for up to 30 days from its expiration date.
    example- card expiration date 02/2013, and a transation comes in on 03/2013, it will not decline becuase of expired card.

    Friends-
    I have 8 years of credit cards, authorizations and credit line management experience from a large financial institution. I am seeking a career oppertunity SAP Credit Card world. Please keep me your mind -).
    Take care.

    Tariq Bashir
    Minneapolis, MN

  • Shekhar says:

    First off, I would like to state that we are not using Paymetric for our credit card processing because of some inexplicable reasons best known to our client. Having said that I wanted to pose a question for folks who read this blog because I am looking for a solution to this problem I am facing.

    We get an authorization on a sales order when it is saved. When we change the shipping point on a line item we run into situations where the tax amount increases. This naturally increases the sales order value but on saving the sales order we do not get an authorization to cover the increased tax amount. How can we get the system to get an authorization for the change in order value because of the tax increase? The system works fine and gets a new authorization when we increase the order qty. What/where should I be looking at to get this taken care of? I looked at the ‘authorization requirement’ and that is the standard reqt ‘001’ we are using.

    Thanks in advance for your help.

    Shekhar

  • Javier says:

    Dear all,

    The client where I am working in, has in mind to implement the outgoing payment through Paypal, and not directly between SAP and Vendor. My client is doing 12000 payments/month, so we need to make sure that our payments are going to be done 100%.

    We have seen that Paypal offers Xipay, for Account payable between SAP and the vendors through Paypal.

    We are quite worry of how to control these payments:

    *We are going to include a new fiel called something like “Paypal ID” to include in the Vendor Master Data, and we are going to customaze a Payment Method called “P” for Paypal payments, and we are going to include a validation that when we execute an outgoing payment and select “P” as payment method, “Account field” in the Master Data must be filled in.

    *We think that our Paypal account will have a dedicate G/L account to make the reconciliation on the Month end? do you agree with that? how would you do that since for creating a paypal account we only need a email account an a password?

    *We are worry in house to registrer our paypal account in the “House Banks” in SAP. The house bank depends on “Bank Key” and “BAnk Country” but our Paypal Account will be in general for our company (Of course in the backend on the paypal account it will have linked one or more account numers). Any idea of how to implement a paypal account as a house bank in SAP?

    Thank you in advance for your help.

    Yours Sincerely.

    Javier.

  • Prakash says:

    Hi

    I could find this blog very much useful which provides different issues and its solution. Thanks to all for contributing.

    I have an issue which similar to Eric Bushman contributed in 2012. When a Sales Order is created and saved, credit card authorization is triggered for multiple times. It’s not even at all times, but maximum of 3 times. Some times 2 and some times 3. Sales Order is having only one line item but authorization is taken for 2 or 3 times (Note no changes to the sales order and deliver completed within 5 days. Time horizon maintained as 30 days). When authorized for 2 or 3 times the amount is blocked for usage in customer credit card. Problem for us is it is not happening for all the customers hence we were not able to debug in SAP. It is happening on random basis. We are using the userexit given in include MV45AFZH for adding 10% to cover the freight. No other issues except multiple/several authorization. Any inputs on this issue appreciated.

    Regards
    Prakash

    • Eric Bushman says:

      Prakash,

      The standard business logic in transaction VA01 should only call the external Authorization function (which you’ve added to SAP configuration) a single time when the Order is saved. In order for it to be called more than once the Order must either be saved multiple times (manually or automatically) or code has been introduced to cause this to happen. This may be happening in what I refer to as a “Pre-authorization userexit” which has also been added to SAP Configuration.

      When you look at the multiple authorizations, are the Authorization times all the same or within a few seconds or are they further apart in time by, perhaps, a few minutes or hours? Are the authorization amounts always the same or do they differ?

      Trying to determine why multiple authorization is happening is very difficult to debug, as you’ve pointed out. One thing you could try is to add code to the Authorization routine that you are calling which writes out (to a spool or table) the user name, date & time-stamp, amount and transaction code when the routine is called. That may help you see enough information to determine what is happening.

      Regards,

      Eric Bushman
      http://www.paymetric.com

      • Prakash says:

        Hi Eric

        Thanks for your inputs.

        It happens within few seconds/minutes. Authorization amount is same and it does not differ.

        Regards
        Prakash

  • Anne says:

    Hi, Paul
    This is a great blog!

    We are using Paymetric and I am hoping you can answer my question about how (under what circumstances) authorizations are passed from the sales order to the delivery in SAP.

    There was a valid authorization in the sales order which was completed to invoicing but no accounting document was created. We figured out the problem and were required to cancel/reverse everything back to the order and create two separate deliveries. The authorization was still valid. The first new delivery was created and taken through invoicing with creation of the accounting document. This “consumed” the authorization.

    The second delivery was then created and invoiced but no accounting document was created because of insufficient funds. Using VA02, we resaved the order, which reauthorized the transaction. This allowed the accounting document to be created.

    How is it that the second delivery “carried” valid payment card information when the authorization was already “consumed” by the first delivery? I was under the impression that everything would have to be cancelled/reversed back to the order again so the delivery would have a valid authorization for invoicing. Obviously, I was wrong.

    Can you explain this to me?

    Thanks,

    Anne

    • Eric Bushman says:

      Anne,

      That’s a great explanation of your issue! All the detail is very helpful in understanding your question.

      Let’s start with a simple answer and then work into the detail. Simply put, in order to post an Invoice to Accounting, SAP requires that a previously “unused” and “unexpired” authorization (or group of authorizations) exist on the Sales Order, for a sufficient amount to equal or exceed the Invoice value, in order to post the Invoice to Accounting. If there is no valid, unexpired authorization of sufficient amount on the Sales Order then SAP will NOT post the Invoice to Accounting until that condition is true.

      Now let’s walk through this in a little more detail. Let’s suppose that you create a Sales Order with 2 line items. The first is a $70 line item and the second is a $30 line item. You save the Sales Order and SAP obtains a $100 authorization against a Visa card you entered. Now you have $100 reserved on the Visa card that will allow you to create a Delivery and an Invoice.

      Three days later when you create the Delivery you learn that the $70 item is actually NOT in stock. But because you have a $100 authorization on the Sales Order, which is not yet expired, SAP will allow you to create a Delivery for just the $30 item. That night when your Billing run executes, SAP will also allow you to create the Invoice for the $30 item and will copy the details of the $100 authorization from the Sales Order to the Invoice Header and use that information to post the Invoice to Accounting. When you run the Settlement job SAP will send the details of the $100 authorization, but only for the amount of the Invoice – $30. SAP then updates the authorization record on the Sales Order to mark it used or “consumed”. This means SAP will never attempt to reuse that authorization code again for any subsequent Deliveries or Invoices, even though you technically only used $30 of the $100. And FYI – the extra $70 that you did NOT use will eventually be released by the Issuing Bank back to the Cardholder’s credit limit.

      Two weeks later the $70 item is finally in stock and you are ready to ship it to the customer. In order to do so, SAP requires that a new authorization for $70 be obtained on the Sales Order. You can have SAP attempt to obtain a new authorization by resaving the Sales Order in some way. Let’s assume that you manually resave the Sales Order in VA02 and SAP obtains a new $70 authorization. Once the new $70 authorization exists, SAP will allow the creation of a Delivery and also an Invoice that can be posted to Accounting. There is no need to reverse or cancel any documents in this case as SAP is using the new authorization to guarantee the payment of the new Delivery and Invoice.

      Once the second authorization of $70 is submitted in a Settlement request (after you’ve successfully posted the new Invoice to Accounting) the process is complete. The customer will see two charges of $30 and $70 on their statement reflecting the separate authorizations you processed for the two separate Sales Orders/Deliveries/Invoices. You will receive deposits of $30 and $70 as well.

      I hope that helps explain the logic SAP has built into their Order-to-Cash processing when using a payment card.

      Regards,

      Eric Bushman
      http://www.paymetric.com

      • Anne says:

        Hi, Eric
        Thanks for the detailed explanation, but I am still in need of more information.

        Your explanation above makes total sense, but below is the timeline of my scenario. All occurred on the same day.

        1st Delivery 11:36:41
        1st Invoice 11:37:43
        2nd Delivery 11:58:33
        2nd Invoice 11:59:17 (no accounting document created because of insufficient funds)
        Sales Order Changed – Saved – Transaction is reauthorized for the second invoice 13:22:07
        2nd Accounting Document Created – 13:49:34

        In your scenario above, the new authorization occurred before the second delivery so it makes sense that an accounting document was posted.

        However, in my scenario, no settlement run occurred between the first and second deliveries. Is that why the authorization in the order was still “green” and allowed the accounting document to be posted after reauthorization?

        I thought after the first delivery/invoice the original authorization was consumed and never to be used again, but the same payment card information was carried on the second delivery. It had, to some extent, been consumed; the accounting document would not post because of insufficient funds (until it was reauthorized). It seems like half of the conditions were true and half were not. Can you sort that out for me?

        Thanks again.
        Anne

        • Eric Bushman says:

          Anne,

          Thank you for the more detailed description of your issue. This helps me understand the flow better. Let me add some comments to the timeline you listed:

          1) Order created an a single authorization obtained (is that correct? I don’t believe you said there was more than one authorization on the sales order initially)
          2) 1st Delivery 11:36:41 (SAP guarantees and allows creation of the Delivery with the open authorization on the sales order)
          3) 1st Invoice 11:37:43 (SAP guarantees and allows the creation of the Invoice with the open authorization on the sales order and marks that authorization as “consumed”)
          4) 2nd Delivery 11:58:33 (This surprises me as the first authorization on the sales order should be marked as “consumed” and cause the Delivery to be placed on a credit hold for insufficient authorization when you attempt to create it)
          5) 2nd Invoice 11:59:17 (no accounting document created because of insufficient funds – this is correct according to my expectations as the first authorization is marked as “consumed” and SAP doesn’t have a valid authorization on the sales order with which to post the Invoice to accounting)
          6) Sales Order Changed – Saved – Transaction is reauthorized for the second invoice 13:22:07 (also correct according to my expectations – this second authorization is needed to release the Invoice to accounting).
          7) 2nd Accounting Document Created – 13:49:34 (I would expect this to be the case after receiving the second authorization)

          You also asked the following:

          “However, in my scenario, no settlement run occurred between the first and second deliveries. Is that why the authorization in the order was still “green” and allowed the accounting document to be posted after reauthorization? ”

          SAP marks the authorizations as “consumed” as soon as they are used to post an Invoice to Accounting. That you hadn’t run Settlement yet won’t matter. And the “green” traffic light you should have seen on the order would have been the second authorization response. The “green” traffic light on the first authorization response would have disappears after it was “consumed”.

          Does that help?

          Regards,

          Eric Bushman
          http://www.paymetric.com

  • Dilmeet says:

    Hi Eric,

    Lovely blog and wonderful answers.. Looking for guidance from you on the same lines..

    My doubt is about the Payment Card Integration process. I tried to find relevant material on all possible sites, but couldn’t really get clear answers to my questions, so seeking your help here.

    Once a Functional Consultant has finished the relevant config for SD – FI in SAP:
    1. What is the role of a functional consultant post the config. ?
    2. Who handles the the implementation of CA-PCI/API for it and how is it done ?
    3. Who, would handle the DSS or any other security software/application(s) that are needed for safe handling of customer info while processing the credit card transaction?
    4. Assuming the company decides to go for Xipay and XiSecure on demand, what would/should be the next steps, post the SD-FI settings?

    Please share your knowledge to clear my doubts.

    Thanks In advance.

    Regards.

    • Eric Bushman says:

      Dilmeet,

      Paul does a wonderful service running this independent forum. It’s nice to have a place to ask questions and have input from so many people. Thanks Paul!

      Let me answer your questions from my perspective:

      Q1. What is the role of a functional consultant post the config. ?
      A1. In my experience, once I am finished configuring the payment card processing business logic, I also assist with testing the functionality. This could include integration testing, Unit testing, scenario testing (order entry, billing, settlement), etc. I also often am involved in end-user training – helping end users understand the functionality and how to use it. There’s usually plenty still to do after the configuration is complete. And perhaps even some adjustments to configuration based on all that testing and training.

      Q2. Who handles the the implementation of CA-PCI/API for it and how is it done ?
      A2. Paymetric provides a “plug-in” for the CA-PCI interface. In the base implementation there is no coding required. The CA-PCI is enabled via configuration and the establishment of the RFC destinations in transaction SM59 or via web service integration such as through PI. Should a company wish to pass any data that is NOT in the standard CA-PCI (for example, to qualify transactions at a Level 2 or Level 3 interchange rate) then there may also be some ABAP coding required to map the required data that is not passed in the standard CA-PCI.

      Q3. Who, would handle the DSS or any other security software/application(s) that are needed for safe handling of customer info while processing the credit card transaction?
      A3. Paymetric provides tokenization to secure the card numbers by replacing RAW card numbers with tokens and storing the encrypted card numbers in Paymetric’s Cloud data vault to help Merchants address Section 3 of the PCI DSS requirements. In addition, Paymetric’s Data Intercept solutions can be implemented to capture and tokenize card numbers BEFORE certain Merchant systems are exposed to the RAW card numbers. For example, Data Intercept for SAP allows SAP end users to enter the card data (type, number, exp. date, cardholder name, CVV, etc) in a browser session rather than in the SAP GUI itself. The RAW card number is never exposed in the SAP application in this case, only the token. From that point forward, the token is the only value ever stored in the SAP database and also is passed through the CA-PCI during authorization or settlement calls rather than passing the RAW card number.

      Q4. Assuming the company decides to go for XiPay and XiSecure on demand, what would/should be the next steps, post the SD-FI settings?
      A4. Once the configuration for the SAP Payment Card Processing business logic is in place, and the CA-PCI interface has been connected to a Merchant’s test account in Paymetric’s On- Demand environment, the next steps are testing, certification and go-live. Testing the SAP business logic and the integration to Paymetric. Once that is complete, certification to Paymetric’s environment will be completed to ensure all required data is being correctly passed. Finally there is go-live and post go-live support.

      I hope that helps!

      Regards,

      Eric Bushman
      http://www.paymetric.com

      • Dilmeet says:

        Eric,

        That helped a ton !!

        Thanks is pretty tiny a word to say to you right now, but still i’d say, Thanks a lot… I couldn’t find an expert to guide me on my questions, guessing that’s because this area is pretty niche and you (you and Paul) were literally like THE last hope i had…

        Thank you so very much ..

        Regards,
        Dilmeet

  • M Syed says:

    Hello,

    We have a complete billing scenario where the customer is not billed until all items on the order have been completely shipped. The order is put on billing block and is released automatically when everything has shipped. This could result in multiple deliveries but only one invoice is generated. The issue we are having is SAP/Paymetric creates an individual authorization for each delivery. This causes confusion for the customer with multiple authorizations for a single invoice. We would like this to be changed so that the customer would always get a single charge for the amount of the invoice. I don’t believe there is any standard SAP configuration to change this behavior.

    Any suggestions/ideas are appreciated.

    Thanks!

    • Eric Bushman says:

      M Syed,

      Paymetric doesn’t create deliveries, nor does Paymetric initiate authorization requests. That is strictly business logic provided by SAP. Paymetric only reacts to the SAP business logic and responds when an authorization request is made.

      That said, the scenario which you describe shouldn’t necessarily result in multiple authorizations. That assumes, of course, that the all of the line items are entered on the sales order during order creation and not added in sales order change mode. Can you describe the flow of the order in more detail?

      Here are a couple of possibilities to ensure that only a single charge is made to the customer’s card when the end result is a single invoice, regardless of the number of deliveries that are created:

      – Utilize Paymetric’s Auto AR program to make payment against the final Invoice amount. (NOTE: This requires all deliveries to have been shipped BEFORE the payment is processed and may be considered an unacceptable risk.)

      – Add code to userexit AUTHORIZATION_VALUE_SPLIT (in program MV45AFZH) which will ALWAYS force SAP to attempt a new authorization for the FULL order value when the sales order is saved. (NOTE: This may also require that additional userexit code, in other userexits, be applied to VOID existing authorizations during sales order save.)

      There may be additional possibilities, but those options will depend on the exact workflow that causes multiple authorizations to occur in your system.

      Regards,

      Eric Bushman
      http://www.paymetric.com

    • SAPGuy says:

      Hi M Syed

      In addition to Eric’s reply, I would like to add the following.

      Something sounds a bit odd. Typically, you would only require one authorization for the whole order even if the are multiple deliveries.

      There are 2 cases I can think of where new authorizations may be required for the deliveries:

    • If the delivery PGI takes long enough, the authorization from the sales order may already be expired. The effect of this would be that the delivery would go on “credit hold” pending a new authorization request. If this is the case for more than 1 delivery, you would have multiple authorizations.
    • Alternatively, if you allow over-deliveries or add freight charges to a delivery, there may not be sufficient authorization to cover the delivery
    • Another user exit option that could be explored at billing time would be to check for multiple authorizations. If multiple authorizations exist, void them and force a new authorization request.

      Browse the comments to see a suggestion for “Implementing Voids from SAP”

      Hope this helps.

      Best regards
      Paul
      The SAPGuy

  • M Syed says:

    Thank you Eric and Paul for your suggestions.

    Our process is something like this. The order is entered, payment card info is added to the order, order is put on billing block and saved. There is an existing code in user exit MV45AFZH that changes the dates in OPEN_VALUES to today’s date. Below is the code.

    loop at open_values.
    open_values-sptag = sy-datum.
    open_values-fkdat = sy-datum.
    MODIFY open_values.
    endloop.

    this forces the card to authorize for the full order amount. But, after creating delivery if someone tries to save the order in VA02, the system creates a new authorization for each delivery.

    Here is an example

    Item 100 – 25 EA – $250
    Item 200 – 25 EA – $250

    Initial authorization is gotten for $500 + tax.

    Item 100 – 10 EA out of 25 EA are delivered – first delivery

    Order saved with VA02, new authorization for the amount of $100 + tax

    Item 100 – 10 EA out of open 15 EA are delivered – second delivery

    Order saved with VA02, new authorization for the amount of $100 + tax is created.

    We want to change this behavior to prevent any further authorizations when there is an existing authorization for the full amount.

    Thanks!

    • SAPGuy says:

      Hi M Syed
      I was wrong. The standard system behavior is to create a new authorization for each delivery created. This is despite the fact that each delivery may be created on the same date (ie. Material Availability date is the same) and you may have a single authorization created for the order. The first delivery “uses” up the authorization and each subsequent delivery requires another one. See SAP Note 914811 [FAQ- Authorization Problems-Why?] (points 4 & 5) where it describes the behavior and the rationale. The only way you can change this is via a user exit (MV45AFZH – AUTHORIZATION_VALUE_SPLIT). They have a few examples there. Alternatively, you can look at SAP Note 166699 [Authorization split, delta authorization] for some other examples – I have seen someone mentioning that they used this note to create a solution. There is another note referred to SAP Note 202054 [All schedule lines within the horizon will be authorized]. For some reason, I cannot access this note, they may be updating this note. But I think this is similar to the code you have already implemented.
      Hope that helps.
      THE SAPGuy

      • M Syed says:

        Thank you Eric and Paul. We were able to write code in the user exit and it seems to work. I am pasting it here for the benefit of others. Now it authorizes for the full amount and does not create a new authorization for each delivery.

        IF xvbak-faksk = ’36’ OR vbak-faksk = ’36’.” complete billing

        IF t180-trtyp NE chara. ” if not in display modus

        REFRESH open_values.
        LOOP AT xvbap WHERE updkz NE ‘D’.
        READ TABLE open_values WITH KEY posnr = xvbap-posnr.
        IF sy-subrc NE 0.
        MOVE ‘VA’ TO open_values-zeitp.
        MOVE sy-mandt TO open_values-mandt.
        MOVE sy-datum TO open_values-sptag.
        MOVE xvbap-posnr TO open_values-posnr.
        MOVE ‘C’ TO open_values-vbtyp.
        MOVE sy-datum TO open_values-fkdat.
        MOVE ‘0001’ TO open_values-etenr.
        MOVE xvbap-waerk TO open_values-waerk.
        CLEAR f_kzwi6.
        MOVE xvbap-kzwi6 TO f_kzwi6.
        f_kzwi6 = f_kzwi6 / 100.
        MOVE f_kzwi6 TO open_values-oeikw.
        MOVE ‘Z2’ TO open_values-abfor.
        MOVE ‘3’ TO open_values-abstp.
        MOVE f_kzwi6 TO open_values-oeikw_ges.
        IF xvbap-vbeln NE ‘ ‘.
        MOVE xvbap-vbeln TO open_values-vbeln.
        ENDIF.
        APPEND open_values.
        CLEAR open_values.
        ENDIF. ” if sy-subrc ne 0
        ENDLOOP. ” loop at xvbap

        * Get open delivery values
        CALL FUNCTION ‘SD_CCARD_GET_OPEN_DELIVERIES’
        EXPORTING
        i_vbak_vbeln = vbak-vbeln
        TABLES
        i_s132 = open_values
        fxvbap = xvbap
        fxvbfa = xvbfa.

        * Get open invoice values
        CALL FUNCTION ‘SD_CCARD_GET_OPEN_BILLINGS’
        EXPORTING
        i_vbeln = vbak-vbeln
        TABLES
        i_s132 = open_values
        fxvbuk = xvbuk
        fxvbfa = xvbfa.

        LOOP AT open_values WHERE zeitp NE ‘VA’.
        CLEAR: open_values-oeikw,
        open_values-olikw,
        open_values-ofakw,
        open_values-oeikw_ges,
        open_values-olikw_ges,
        open_values-ofakw_ges.
        MODIFY open_values INDEX sy-tabix.

        ENDLOOP.
        ENDIF.
        ENDIF.

        LOOP AT open_values.
        open_values-sptag = sy-datum.
        open_values-fkdat = sy-datum.
        MODIFY open_values.
        ENDLOOP.

        • SAPGuy says:

          Hi M Syed

          I really appreciate you sharing what you ended up doing. That is really helpful.

          Best regards
          Paul
          The SAPGuy

  • SAP SD says:

    Hi Paul, Eric,

    This is a great post and very informative!!
    I am looking for an answer to a very strange issue we are facing , we have implemented Paymetric credit card solution and due to our business requirements we have Authorization split on sales order (based on number of deliveries) basically delivery due list is mimicked and authorizations are taken accordingly.Now It works great when we have deliveries delivered in a sequence (PGI’d) as they are authorized.

    For e.g.
    Three Auth 20$ 275 $ 40$ on Sales order works great if the deliveries are created.

    Now the issue is when the sequence is not the same as created,

    e.g. Delivery 2 was first PGI’d and Invoiced ( the invoice amount is 275.02 $) 2 cents off because of rounding. Now we saw that the Invoice actually referred to two Authorizations ( 20$ and 40$) , strange? Now susequently Delivery 3 was PGi’d and Invocied 2 days later and i see that it actually picked the Authorization of 275$ from the order, which i believe is because there was only one Unused authoirzation left. Now the Delivery 1 as expected had error and we had to reAuth the order.

    Now the issue is why did system pick two authorization of 20$ and 40$ for Delivery 2 Invoice (which is actually 275.02 $) and also we saw that only 20 $ + 40 $ is Settled and passed to accounting (accounting document stands partially cleared).

    Any help is much appreciated !!!!

    Thanks
    S

    • Eric Bushman says:

      S,

      The issue describe is such a common issue that SAP has released OSS note 693746 to address it.

      The note describes how you can modify SAP’s business logic for determining which authorizations should be applied to an Invoice/Accounting Document when they are created to try to find a “better match” between the authorization amount and the Invoice amount. Have a look at the note and the code changes that SAP recommends.

      Regards,

      Eric Bushman
      http://www.paymetric.com

      • SAP SD says:

        Thanks a lot Eric ! A good coincidence that i came across two SAP notes 693746 (as you suggested) and 621966 yesterday evening. We are implementing them. Thanks again!

        S

  • Lata says:

    Hi

    we are integrating a non sap website to CRM, and CC is getting authorized in website. but when order is created in CRM using Idocs, it is trying to re-authorize in CRM.
    How can we skip authorization in CRM, we have CC token and auth resp code etc in Idoc

    Thanks

    • SAPGuy says:

      Hi Lata

      I have not worked in CRM for a very very long time. So I am not sure if this will apply. Very often the CRM configuration is adopted from ECC.

      The authorization typically takes place on Order Save. So the idea would be to have a custom check to see if there is an authorization present. If there is, do not call the authorization check.

      3 Ideas to investigate:
      1. TCode: OV9A – Maintain Authorization Requirements

      Menu Path

      Requirement Routines

      The idea would be to create a custom routine as assign it to the check group.

      TCode: OVPG – Maintain Checking Groups

      Payment Card Checking Groups

      2. Remove the Payment Guarantee procedure from the sales order via a user exit.
      To be honest, I am not sure this would work for your situation. We have used this in the past when the business requirement was to allow all authorizations to occur in AR via Paymetric’s Auto AR module. We drove this for very specific payment terms. But as I say, I am not sure this would work for you as you want to retain the authorization.

      3. Maintain a Check in the Authorization routine iteself
      You will find the authorization routine for the clearing house in:

      Clearing House Authorization / Settlement
      Clearing Account Functions
      Authorization Routine

      This may be your best bet as you can control the authorization call.

      Hope this helps.

      Let us know how you resolve this.

      Signing out
      The SAPGuy

  • >