Paymetric (XiPay) Integration through SAP PI

[Baz]

Does anyone have experience of integrating XiPay through SAP PI (7.1)?

My current project is looking to change the way they do business and I am trying to evaluate some alternatives to their current AS400 solution.

I have implemented a slimmed down version into a hosted solution run by NetBanx in the past, but we are looking at a bigger integration into SAP CRM and FI, possibly FS-CD as well! moving from UK processing to a worldwide solution. if successful, this will then be rolled out to multiple countries.

I have read the literature provided by Paymetric and there is talk of "cartridges and adapters" to plug in, but we wish to use PI as there will be interaction between multiple components - Call Centre (interaction centre) online - via websphere applications and by post (scan capture).

At the moment, I am only proposing three solutions to the Project Board, but wanted to try and influence the decision, if possible.

[ericbushman]

Just a side note to add here for anyone considering using PI in a credit card implementation.

PI logs all messages and the data contained in a credit card authorization or settlemetn message will contain card numbers and potentially CVV values. This presents challenges related to PCI DSS compliance if these types of data, particularly CVV values, are stored in any logs in any system by a Merchant.

Paymetric helped champion a drive to provide a solution at SAP which would eliminate this storage of sensitive data which led to the release of OSS note 1256891 - Logging errors in synchronous communication. This note is applicable to PI 7.0 and 7.1 and should be installed by anyone using PI and payment cards. This note provides the ability to turn off logging of a message payload for synchronous messages - which is what the authorization request and response uses. You can still log the message header, but by not logging the payload you will not risk storage of unencrypted card numbers and CVV values.

Paymetric recommends this to all clients and prospects wishing to connect directly from PI to Paymetric's On Demand payment processing service so as to ensure that all PCI DSS compliance requirements are being adhered to.

[Baz]

Hi Eric

we have implemented this Note that you suggested but unfortunately it is not very flexible!

i am in communication with SAP to see if there is any potential scope in extending this further so that only sensitive synchronous interfaces are affected by it. as this is an all or nothing approach it then removes the data vital for error resolution of other interfaces that do not contain sensitive data.

otherwise, this fits the bill nicely!

[eugenecctan]

Hi Baz,

Anything to update on how to prevent particular interfaces? By implementing sap note 1256891 will removes all payload for all interfaces, Sap note 1427557 seems to be the solution for removing just particular interfaces,

details_>
HEADERS Payload is removed before message is displayed. Only
header and manifest are visible in the Message Monitor.
You can use the subparameter to define the value for an interface: To do
this, use transaction SXMSIF to create an entry for the interface. Use '*'
as the component. The system ignores the component during the evaluation.
This entry is displayed in the value help of the subparameter and can be
selected. At runtime, the system first searches for the specific entry. If
it does not find any entries for the current interface of the message, the
system determines the unspecific value.

But I am not sure how to link between transaction SXMSIF with table SXMSCONFDF, any idea how?
Btw, I am implementing on XI 3.0.

Thanks.

Best Regards,
Eugene Tan

[Baz]

Hi Eugene

thanks for the update!

this was the note i sent to SAP!

11.09.2009 - 12:41:59 CET - Info for SAP by Baz

Hi

this is disappointing as this note could be good, but this affects all
synchronous developments.

if this note is implemented and, for example a mapping fails during
transformation, the payload would not be available to be able to test
and isolate the field and data causing the problem which would make the
resolution almost impossible as there is no further data to test.

the note is an all or nothing approach and has the potential to be very
good. but in it's current form, it is restrictive due to unwanted side
effects.

The Integration Engine could potentially be linked to a customising
table to then choose the exceptions rather than the rule for applying
this note....
or even extend the subparameters of the configuration to be linked to
interface name for exceptions to the standard rule...

Looks like SAP chose to do it after all!

i am no longer on that project....

Are you sure you are on the right Basis Version and have implemented that note?