Support other payment processors

[BbrSofiane]

Slack thread: https://openedx.slack.com/archives/C01AGTSB1LL/p1620648832151800

[davidjoy]

The short answer is no - there's no way to configure other payment processors into the MFE today. That said, the code is fairly modular and it might be possible to put a layer of abstraction in to improve our extensibility here, but I'd expect it to be a "medium" sized project.

[sambapete]

That's a MAJOR issue for us at EDUlib. And I mean almost show-stopper. I will explain later. First, a little bit of historical perspective.

When we first looked at ecommerce, the Université de Montréal wouldn't allow us to use Cybersource or PayPal. Because of internal political / technical issues we had to deploy a payment connector for Netbanx / Paysafe based on the code originally used for Cybersource. The code has been in used at EDUlib since at least our fork for Dogwood (June 2016).

With each new open release of Open edX, I have to do regression testing in order to make sure our payment processor code still works and make subtle changes to ecommerce and sometimes to edx-platform if not.

When we were told recently that we would be forced to use the Payment MFE because the previous code had been deprecated, I started having doubts, big doubts. Was there even a DEPR ticket to warn us that the Payment MFE was coming? I don't think so. Was there even something announced to the Open edX community that other payment providers would no longer be supported? I don't think so.

While waiting for the Payment MFE to land in a production state and made available to the Build-Test-Release working group, I needed to test my fork. What did I do to test it without the Payment MFE? I did some reverse engineering. In the end I modified at least 31 files according to one of my commits in order to use the old payment flow and make sure I could still use my Netbanx / Paysafe processor as it was used in Koa and previous releases. I had to reuse code from Koa in some instances.

That would probably not be supportable through Maple or future releases of Open edX. I can just imagine the fun I will have doing a rebase for Maple now...

And what about the other Open edX instances that might be using Stripe or any other payment provider? Will they have to do the same reverse engineering as I did?

I cannot accept the current situation. I am sorry.

[sambapete]

I was made aware of https://discuss.openedx.org/t/deprecation-removal-legacy-frontend-implementations-depr-17-depr-42-depr-109/3193 by Kyle McCormick. Yes there is a mention of DEPR-42 with regards to the ecommerce basket page. We are using a hosted payment solution and we do not go through the ecommerce basket page. That might explain why I missed it.

Unfortunately, it does not mention that “Custom payment processors will no longer work.” either...

[davidjoy]

@sambapete I'm wondering how much work it'd be to add another payment processor here:

https://github.com/edx/frontend-app-payment/tree/master/src/payment/payment-methods

When the payment MFE was originally created, there was some care taken to try to have a consistent payment processor interface/API for the three that are already there.

In lieu of a more pluggable system, I expect it wouldn't be too onerous to add a fourth and some configuration to allow the application to call out to it instead of Cybersource or Paypal. It's been a while since I was in the code, of course, but that's what I recall.

That's the frontend half, anyway, which admittedly is what I'm personally more familiar with. Assuming other processors would be called directly from the MFE - rather than needing to go through an ecommerce backend in the platform - it may not be terrible to add new ones.

[sambapete]

@davidjoy I guess this could be a possibility.

Not being a developer, that would be difficult for me to implement and make sure to convert properly the code from the payment processor we developed in Python (based on the code from cybersource.py) in ecommerce and to recode it in JavaScript / React. Especially in the context where it is also an hosted payment page that does not require the basket page from Open edX. Therefore, PCI was never an issue for us because we handed the payment entry and transaction to the hosted page at Paysafe. No credit card data on our side.

I haven't looked yet, but I wonder where you add the account information for the account used in cybersource, paypal or stripe now? Is it still in ecommerce?

[arbrandes]

During the contributor's meeting we decided that at launch Lilac would release as is: with no support for the old ecommerce flow, and no support for other payment processors.

If, however, by Lilac.2 there is a tested patch to resurrect old ecommerce, we agreed we'd merge it in.

Support for other payment processors will be built by Maple.

[sambapete]

Because the current payment processor (Paysafe) we use at EDUlib isn't compatible with the Payment MFE, I needed to understand how the Payment MFE works with Cybersource in order to better understand what needs to be done for another payment processor in order to be PCI Compliant. Paysafe has a similar system than the Cybersource Flex MicroForm in order to capture and tokenize the credit card information data.

I created a test account at Cybersource in order to be able to test the Payment MFE with this account.

I was able to make the Payment MFE work with a test account at Paypal, but that solution redirects the user to a Paypal hosted payment page which is quite different than what is being done for the credit card information needed by Cybersource.

When configuring the Payment MFE and trying to use it with Cybersource, I get like a skeleton trying to load but no errors messages in either ecommerce or lms.

All I get are the credit card information where I cannot enter any card information and the following information when looking at the javascript console in Chrome or Firefox.

We can see calls to Segment and New Relic being blocked. We do not use Segment or New Relic. Is there a reason why Segment and New Relic are used by default in the Payment MFE? Should it be documented somewhere? And how to change the logging for the Payment MFE?

Since Segment and New Relic are definitely not the default for Open edX instances, I discussed briefly it with David Joy a few weeks ago.

David told me that MFEs can be configured to use a different logging service (or a dummy one), but not via .env configuration… I’d prefer people not have to fork to change that.

The relevant doc being https://edx.github.io/frontend-platform/module-Initialization.html#~initialize - the initialize function can take an alternate loggingService implementation… but that requires editing the index.jsx file! Ugh.

Not being a Javascript expert or a React expert, I feel like I am running in circles just "trying" to make it work. I am definitely out of my depth here.

Has anyone, outside of edx.org, been able to use the Payment MFE with Cybersource? I mean being able to process a transaction, not just being able to install the Payment MFE?

Knowing that someone was able to use it would go a long way in allowing us to better understand what I am doing wrond and document what needs to be done in order to resolve it.

[sambapete]

Just FYI

I tested the scripts available in https://github.com/CyberSource/cybersource-flex-samples-node

They work with the keys provided and with the keys I created at Cybersource. So I know the CyberSource Flex SDK works.

Neither the keys provided nor the keys I created at Cybersource work with the Payment MFE. I still get the skeleton loading with no idea whatsoever is going wrong.

I am out of ideas...

[BbrSofiane]

Past Maple, this is now superseded by the overall question around the deprecation of ecommerce.

[sumanchapai]

I am sorry @BbrSofiane, what do you mean when you say deprecation of ecommerce?