Ecommerce: Changes to Stripe payment processor

Development Architecture
,
1

Hi everybody!

We just wrapped up a project that upgrades the existing Stripe payment processor in ecommerce to support Stripe payment intents and makes it compatible with frontend-app-payment.

The code is already in master, and is eligible for inclusion in an Open edX named release starting in Palm (June 9, 2023) or later.

Audience

Who Why
Operators who use the existing Ecommerce Stripe Charges-based payment processor Inform of a breaking change
Operators who would like to migrate from Cybersource to Stripe Inform this feature has been implemented
Operators who are running the Cybersource payment processor Inform of significant change to codebase that may require testing prior to deployment
All of the above Solicit assistance with pre-Palm testing of the new feature

What is not changing

  • Cybersource remains the default payment processor for ecommerce and frontend-app-payment. Instances running Cybersource should see no changes.

  • Ecommerce is still officially deprecated and we continue to work on the Ecommerce Replacement Project.

What is changing

  • The legacy Stripe Charges ecommerce payment processor with a frontend in ecommerce is upgraded to a Stripe Payment Intents payment processor with a frontend in frontend-app-payment.

What next?

  • If you use Stripe Charges, we’d appreciate your feedback on the documentation and any volunteers to be an early tester of transitioning from Stripe Charges to Stripe Payment Intents.

    • As we never ran Stripe Charges ourselves, we were unable to test these changes in our deployment. This is why we need your help.

    • Given the speed we were obliged to move on this project, we’d be happy to help support community transitions from Stripe Charges to Stripe Payment Intents to make sure our changes don’t break other people’s deployments.

    • Please reach out in the #ecommerce channel of Open edX Slack if this applies to you.

  • If you use Ecommerce, please consider planning and testing your upgrade to Palm earlier than usual due to this major change in payment processors in Ecommerce.

More information

How to reach us

#ecommerce channel of Open edX Slack

Much obliged,
Purchase Squad, 2U/edx.org

4 Likes
2

Hello!

I tested Stripe for Payment MFE, but I couldn’t perform a test payment. The payment form from the Stripe service appears, but there’s an issue with the secret key. I receive an error message: “This API call cannot be made with a publishable API key. Please use a secret API key. You can find a list of your API keys at [link to Stripe dashboard].”

I used both the secret and public keys from my test Stripe account. I suspect the problem may be related to using test keys. However, I’m puzzled as to why the payment form from the Stripe service appears if it also uses a key, albeit a public one.

I would appreciate any assistance in resolving this issue, as it’s a significant change in payment processors in Ecommerce.

If you have the opportunity to help or have any ideas, please let me know.

Thank you!

3

Hi @Dmytro_Alipov, thanks for reaching out!

Could you provide more context regarding this error?

  • Is the call to Stripe generating the error called from Ecommerce or from Payment MFE?

  • What line of code is generating this error?

  • Are your Ecommerce Stripe settings from these docs appropriately set?

  • When running ./manage.py diffsettings to see your effective configuration, is PAYMENT_PROCESSOR_CONFIG["edx"]["stripe"]["secret_key"] what you expect?

In our testing, Stripe:

  • Expects a publishable key (pk_...) from Payment MFE.

  • Expects a secret key (sk_...) from Ecommerce.

  • Worked the same way with a test key (..._test_...) as a live key (..._live_...)

(For others following along who may be new to this, please see Stripe’s API key docs for a primer.)

Thanks,
Phil

4

Hi @Dmytro_Alipov, did the above work?

Thanks,
Phil

5

Hi, Phil! Sorry for the long answer. I have not yet continued to deal with this issue. In the near future, we will continue and I will describe in more detail the nuances I encountered.

6

No problem! Thanks for the update!