In the course of building out Lilac, we’ve run into a stumbling block around Ecommerce. @sambapete writes in Slack here and in this thread that changes edX has made to the ecomm service has blocked custom payment processors from being used in the new Payment MFE (that is, only Cybersource works in the Payment MFE). Further complicating matters, the old ecommerce workflow is currently broken, and no longer PCI compliant - which is why we were defaulting to the Payment MFE in Lilac. To quote Pierre:
It may still come as a surprise to those with a custom payment processor when they will start upgrading / deploying Lilac and discover their ecommerce flow doesn’t work anymore. There is no easy way backwards if they are not warned not to upgrade.
BIG QUESTION: Who in the community is using payment processors aside from Cybersource? Are there any people who are well-versed in ecommerce and able to help out?
We see four remediation paths, 2 long term and 2 short term:
(Long term) Allow the payment MFE to be configured to use other payment processors, and add those payment processors to the codebase alongside cybersource, paypal, and apple pay.
(Long term) Fix the issues in ecommerce that prevent the old payment flow from working.
(short term) Figure out what commits in the ecommerce repo can be reverted to make the old ecommerce flow work again. We’ve identified one, but there may be others.
(short term) Run the old ecommerce flow from Koa, but apply library upgrades. This may be dangerous as API contracts could be broken.
Who does this affect? Who is willing to jump in here and help? @djoy and I are happy to provide some assistance, but both of us are unfamiliar with the ecommerce service. We can help expedite your work/pull requests however we can. We need community experience and expertise to move this issue forward.
Finally, I’d like to acknowledge that communication of the limitations of the new Payment MFE, as well as deprecation of the old ecommerce workflow, was not done well (see this Discuss thread). We needed to be more transparent and louder about breaking changes. To that end, I am running an internal RCA (root cause analysis) in the coming weeks for involved internal teams to capture learnings from this incident and inform us how we can do better moving forward.
We have a few clients clients using custom payment processors (PayTabs and HyperPay).
I think this is the most viable alternative and the one that is aligned with the platform’s long-term goals.
We already took the first steps in making e-commerce payment providers pluggable through these PRs:
These take care of adding pluggability to the old views (the ones that were deprecated).
The next step here would be to merge the e-commerce PR and then add support on the MFEs to use this pluggable mechanism (and maybe some extra endpoints in the service to let them retrieve payment processor metadata). We have not started using the MFE’s on our deployments yet, so there’s no work done for that.
Does anyone have an idea of the effort to implement this mechanism in the MFEs? (CC @djoy).
Maybe we can join efforts in the community and implement this last piece of work together?
Thanks for all the detail @giovannicimolin - the MFE has already been structured in a fairly modular way for the three payment processors that exist today (Cybersource, Apple Pay, and Paypal). They’re not fully pluggable, but they have a fairly consistent interface which we can work with.
In the future if we’re able to make this more fully pluggable, we can go back and clean it up and firm up the abstraction layer.
One wrinkle may be the way the checkout UI works w/r/t credit card fields. With Cybersource, it uses an iframe to embed code from Cybersource that handles CC processing so that the ecommerce service never even sees user credit card numbers. To keep the ecommerce service and frontend-app-payment from needing to be PCI compliant, we might need to find similar mechanisms for other processors.
I’m not 100% up the details there or about what we’d want, but it’s something we’ll have to consider carefully, as some operators may care more about it than others.
For the record, during the contributor’s meeting today 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. Only the MFEs as they stand.
If, however, by Lilac.2 there is a tested patch to resurrect old ecommerce, we agreed we’d merge it in.
We’ll target support for other payment processors on the ecommerce MFE(s) for Maple.
I think that we can avoid complex implementations (pluggable frontend modules) and go for generic implementations of payment providers for the long run as well (let’s leave the complexity of the payment provider to be handled by the backend, while the frontend only renders pages using a common interface).
We worked with HyperPay and Paytabs so far, and both used different payment flows that don’t require PCI certification. Hyperpay: needs some backend requests to prepare the payment flow, then renders an iframe with the payment implementation (so card data never touches e-commerce). PayTabs works similarly: after a request to set up the payment, it’ll return a URL you can redirect a user to fill in the payment information on its own page.
These are two different but very common types of payment flow among payment providers and should cover most use cases.
Most common payment processors in the Middle East are HyperPay and PayTabs.
We are using HyperPay in our implementation. Are we still forced to use the new MFE mechanism? is there a way to use the old ecommerce flow on Lilac?