Skip to Content

Credit Card Processing in SAP. Advantages Realized with ESOA

In this blog am going to share with you the advantages of ESOA, the business has realized interms better ROI and improved transaction efficiency compared to the legacy credit card processing in SAP.


The current business process of the client performs only an offline or batch authorization when a credit card sales order is created in SAP. A customized Z table was used to maintain the list of credit card sales orders created. Every 30 minutes a batch job runs to pull all such credit card transactions and send to the payment gateway through an FTP requesting authorization with the payment gateway. To ensure security of the payment card details, the credit card sales order details were zipped and locked with an encryption key. Once the payment gateway receives the request for authorization, it decrypts the zip file containing credit card orders. The encryption and decryption keys are understandable between the business and payment gateway so that they can exchange the data. After validation with the clearing house the payment gateway sends the status of authorization as either success or fail again in a zip file with encryption. Once the data is received to SAP, it was decrypted to proceed for further processing of delivery and invoice. To complete a cycle of authorization it takes about 45 minutes time.


Legacy Process Flow



New Process


The disadvantages of existing process:


  • The authorization was always made for 1$ since it was not real-time, just to ensure whether the card was valid or not.
  •  Freight amount was never taken into consideration resulting in further issuance of credit / debit memos to settle difference amount.
  • The process of getting a sales order authorized / settled takes about 45 minutes time. Because of this Rush Orders could not be handled.
  • Since the authorization requested is only for 1 $ there were many cases of payment not received.
  • When a payment is not received as expected, the business suffers interms interest, capital and time waste because of manual effort involved to collect the payment.
  • Lot of custom code and Z table maintenance to record credit card transactions.


In order improve the existing business process; we have suggested the client to use the SAP’s NetWeaver technology to implement online real-time authorizations / settlements.


In this process whenever a sales order is entered into the sap system with the required sales order details and saved, it kicks the authorization function module. The proxy generated in R/3 system was used to generate a SAP-PI understandable XML file with the credit card sales order details. The WebService developed in java run on the J2EE engine and consume the SOAP XML and translate the XML data into a name value pair. It’s done because the payment gateway can understand only a name value pair.


We had evaluated the following 4 options to meet the payment gateway’s requirement of receiving name value pair information from PI to be able to process the transaction.


  • Use a 3rd party adapter
  • Use the Java Proxy
  • Developing a custom adapter
  • Use a WebService


However we did not go in for a 3rd party adapter as the TCO (Total Cost of Ownership) would go up. We tried using a Java Proxy but as we had some environment specific issues which could not be solved in our time frames had to give up on this too. Developing a customized adapter has an issue in meeting the time frame. Apart from that there is a need to have such custom adapters certified by SAP which may again stretch the time lines.


Finally, we had deployed a WebService as the development effort was comparatively less; the option of re-usability was there enabling it to be used in heterogeneous nature of landscapes in enterprises. If not for a WebService the integration of different applications so far has been done using manually declared interfaces, messages and agreements between the business partners.


SAP  –> PI  –> Payment Gateway



legacy process





  • Online real time authorization.
  • Since the credit card is blocked for the amount of sales order created the chances of settlement going through is almost certain.
  • Transaction efficiency and ROI are increased.
  • Manual effort to collect default payments is reduced.
  • Secured Network Connection through PI using the encryption algorithm.
  • PI monitoring of the payload enabling to find the reasons for failure if any.


With all the above mentioned advantages now the whole processing time for an authorization just takes about 5 to 10 seconds. Rush orders are also handled well with this speed of processing. Each order created in SAP can be authorized independently without having to wait for a batch job.

You must be Logged on to comment or reply to a post.
  • Sadhu – one other disadvantage, until just recently, with the ESOA integration is that the PI system logs ALL data in the authorization request payload.  This means that all credit card numbers and CVV2/CVC2/CID values are logged in PI – thus bringing any merchant using PI integration into non-compliance with the PCI requirements.  Merchants should never store credit card numbers in an unencrypted format and should never store the CVV2/CVC2/CID values in ANY format.

    Paymetric identified this issue when working with a customer to implement the Enterprise Service interface for payment card processing in ECC 6.0 with Paymetric’s Payment Processing Service (XiPayNet) using Paymetric’s SAP-certified XI Content and subsequently raised the issue with SAP.  The good news is that a patch for PI 7.0 & 7.1 was recently released which allows you to prevent logging of the payload of synchronous messages.  This patch is described in OSS note 1256891.

    I would strongly recommend that anyone implementing the Enterprise Services for Payment Card Processing using PI apply the patch in 1256891 in order to maintain PCI compliance.

      • Hi Ravi,

        The authorization which is basically a synchronus call and you can turn off the logging globally for all the interfaces but when a synchronus message fails payload will be exposed and by implementing the note 1256891 you can prevent the logging of the sync payload even in the case of failures.

        PI should come up with facility where we can prevent the field level logging and also preventing the logging for a particular interface instead of globally.