Wishlist: Upgrade to Stripe v3 (elements)

Bug #1774892 reported by Garry Collum on 2018-06-03
92
This bug affects 17 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Unassigned

Bug Description

Evergreen currently uses stripe version 2. Version 3 (https://stripe.com/elements) is now available. Some of the new features, such as real time credit card validation and auto-generated PCI compliance documentation, would be helpful to both our patrons and staff.

Garry Collum (gcollum) on 2018-06-03
tags: added: wishlist
Changed in evergreen:
status: New → Confirmed
Jeanette Lundgren (jlundgren) wrote :

If we don't upgrade to v3 then Stripe Evergreen sites will need to file for annual compliance using the PCI Data Security Standard Self-Assessment Questionnaire A-EP (https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2-SAQ-A_EP.pdf) for partially outsourced e-commerce merchants using a third-party website for payment processing. This places the compliance burden on us not Stripe.

If we do upgrade to v3, the vendor will continue to file for compliance:

Stripe: For some context, the PCI Council has published a series of changes to eligibility requirements for Self-Assessment Questionnaire A (SAQ A). These require that businesses use input fields hosted by a payments provider in order to be eligible for the simplest PCI validation method (SAQ A). We've designed Stripe Elements with these changes in mind so that you can continue to validate using SAQ A without losing much of the flexibility and customization of a form hosted on your website if you migrate to v3.

Terran McCanna (tmccanna) wrote :

Marking this High importance since it directly impacts multiple current Evergreen implementations.

tags: added: billing opac
Changed in evergreen:
importance: Undecided → High
Changed in evergreen:
importance: High → Wishlist
importance: Wishlist → High
Martha Driscoll (mjdriscoll) wrote :

NOBLE chose Stripe as our credit card processor because our exposure to PCI compliance was minimal. We need/want to implement v3 and see this as a high priority.

Jason Stephenson (jstephenson) wrote :

This is also very important for us at CW MARS, so I will start on an implementation.

Here is a Google Doc with my notes on what needs to be done. If anyone has any comments on it, please add them here.

https://docs.google.com/document/d/158OraVN0GUlScpcPyY9msazToMiEbBBmKrSBvWLUFx0/edit?usp=sharing

Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
Changed in evergreen:
milestone: none → 3.next
Lugene Shelly (lugene) wrote :

This is also important to the SPARK consortium. We have libraries that would like to offer Stripe for credit card payments. We're on version 3.3.

Changed in evergreen:
status: Confirmed → In Progress
Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
status: In Progress → Confirmed
Andrea Neiman (aneiman) wrote :

CW MARS has signed a contract with Equinox to work on this bug based on Jason Stephenson's outline in comment #4

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Jason Etheridge (phasefx) wrote :
Download full text (4.2 KiB)

Top commit at collab/phasefx/lp1774892-stripe-v3 in the working repo.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=734dd176ce8075fafa8c9227af99e34a3d2d790d

This commmit changes the OPAC to use https://js.stripe.com/v3/ instead of https://js.stripe.com/v2/ for processing payments through Stripe.

Additionally, it disables the "internal" credit card form in the staff client when Stripe is the payment processor (or if the processor is not set at all), as that does not currently work.

It also does not replace Business::Stripe's use of the "Charges API" with the newer "Payment Intents" API on the backend, but credit card details are still not sent to the Evergreen server.

It's easy to get test environment keys from Stripe without needing to provide credit card details, etc.: https://dashboard.stripe.com/register

Once registered, go to https://dashboard.stripe.com/test/apikeys

The Publishable key should go into Evergreen's "Stripe publishable key" library setting (credit.processor.stripe.pubkey)

The Secret key should go into the "Stripe secret key" setting (credit.processor.stripe.secretkey).

You should also set "Enable Stripe payments" (credit.processor.stripe.enabled) and "Allow Credit Card Payments" (credit.payments.allow) to True, and "Name default credit processor" (credit.processor.default) to Stripe. For my test system, I used the CONS org for all these settings.

Test plan using Concerto:

In the staff client, go to /eg/staff/circ/patron/71/bills (or use patron barcode 99999376864)
Bill the patron $20.

Log out of the staff client or use an incognito window for the public OPAC.
Log into the OPAC as patron 99999376864 (password leona1234).
The Account Summary with the $20 billing should come right up.

Click Pay selected charges.
For the card number, use 4242424242424242, which should show up as Visa.
For the MM/YY, CVC, and ZIP fields, any valid looking data should work, and the form will warn you about expired dates realtime.
Click Submit payment.

The bill should be paid and a receipt generated. I noticed that the charges summary in the upper right does not change until after a new page load, but that's an existing bug.

If you go to https://dashboard.stripe.com/test/logs?method[]=post&method[]=delete&direction[]=connect_in&direction[]=self
you should see an entry for POST /v1/tokens and one for POST /v1/charges corresponding to your test activity.

Log out of the OPAC and back into the staff client.
Bill the same patron another $20.
Change the "Name default credit processor" (credit.processor.default) library setting to PayPal.

Log out of the staff client or use an incognito window for the public OPAC.
Log into the OPAC as patron 99999376864 (password leona1234).

Click Pay selected charges.
At this point, you should get the original credit card form and not the one you used for Stripe. I haven't actually tested this with PayPal credentials, but bonus points for anyone giving this area extra scrutiny.

Proceeding with the same credit card details and submitting the payment should result in "Credit card processor not enabled" (assuming no PayPal credentials have been configured).

Log out of the OPA...

Read more...

tags: added: pullrequest
Changed in evergreen:
assignee: Jason Etheridge (phasefx) → nobody
Jason Stephenson (jstephenson) wrote :

CW MARS is testing this.

Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
John Amundson (jamundson) wrote :

I have run into a major issue while attempting to test this.

Using the old version of Stripe, it is possible to select a subset of charges from a patron's full list and submit a payment just for those. With the new version, I can select a subset, but the payment is applied to the FULL list of charges.

This is a major bug in my eyes. For example, let's say a patron has 3 separate charges: one for $1.00, one for $2.10, and one for $76.00. As the patron, I know I have the $76.00 book and plan to return it. So I choose to pay only the $3.10 owed in other charges. I enter my credit card payment and submit. There is no confirmation screen or subtotal listed. The payment processes. And then I'm told the payment went through for ALL the charges. I am now out $76.00 that I may not have.

I tested this twice, both times with the same results. I used card 4242424242424242.

Because of this behavior, I did not get very far in my testing.

Before stopping, though, I noticed a few other things.

On our server, the Charges page displays differently prior to the patch. I don't know if this is due to a customization on our side or has to do with the patch. I tested pre and post-patch in the same exact browser, (Chrome v83.0...)

With the old version of Stripe, the subtotal would display on the credit card form. It no longer displays. This means the patron will no have idea the payment was for the whole list of charges until after it is made.

We also had custom text on the old payment form that is lost with the new one. Jason Stephenson writes "The main payments form still includes the refund policy in the same way, and it should have picked up our custom version."

You can see a collection of relevant screenshots here: https://docs.google.com/document/d/1c-JJteH5Z6bt_bFdhH5Y_0NOPNRfnK-MmX7ElHCohy0/edit?usp=sharing

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody

This is a very big bug indeed. We would need to have this fixed before
implementing.

Dawn Dale, PINES Services Specialist - Circulation

Georgia Public Library Service | University System of Georgia

2872 Woodcock Boulevard, Suite 250, Atlanta, GA 30341

tel: 404.291-2800 | <email address hidden>

<https://www.facebook.com/georgialibraries>
<https://www.twitter.com/georgialibs>

Join our email list <http://georgialibraries.org/subscription/> for stories
of Georgia libraries making an impact in our communities.

On Thu, Jul 9, 2020 at 2:50 PM John Amundson <email address hidden>
wrote:

> ** Changed in: evergreen
> Assignee: Jason Stephenson (jstephenson) => (unassigned)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1774892
>
> Title:
> Wishlist: Upgrade to Stripe v3 (elements)
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> Evergreen currently uses stripe version 2. Version 3
> (https://stripe.com/elements) is now available. Some of the new
> features, such as real time credit card validation and auto-generated
> PCI compliance documentation, would be helpful to both our patrons and
> staff.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1774892/+subscriptions
>

Jason Etheridge (phasefx) wrote :

Thanks John! I'm looking at this.

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Jason Etheridge (phasefx) wrote :

I've added 2 more commits to the branch, for a total of 3 commits at the tip.

This should fix granular transaction selection, restore the refund message, and the last chance form. It also refactors the code a little bit for readability, and fixes some minor HTML errors in the generic payment form.

Let me know how it looks. Thanks!

Changed in evergreen:
assignee: Jason Etheridge (phasefx) → nobody
Changed in evergreen:
assignee: nobody → John Amundson (jamundson)
John Amundson (jamundson) wrote :

Thanks, Jason and Jason.

I performed heavy testing on the OPAC side, (various cards, blocked cards, variety of subset of charges, etc). Everything looked great, so I'm adding my sign off.

I have tested this code and consent to signing off on it with my name, John Amundson, and my email address, <email address hidden>.

That said, I was not able to test the behavior in the staff client since we have customization that stops the Credit Card option from appearing.

I was also not able to test the setting change to PayPal.

At this point, additional testing is encouraged, especially in the two areas I mention here.

tags: added: signedoff
Changed in evergreen:
assignee: John Amundson (jamundson) → nobody
Dawn Dale (ddale) wrote :

Jason,

I have tested the staff client portion and it does exactly what you say it
will do.
I have tested this code and consent to signing off on it with my name, Dawn
Dale email ddale@georgialibraries .org.

Dawn Dale, PINES Services Specialist - Circulation

Georgia Public Library Service | University System of Georgia

2872 Woodcock Boulevard, Suite 250, Atlanta, GA 30341

tel: 404.291-2800 | <email address hidden>

<https://www.facebook.com/georgialibraries>
<https://www.twitter.com/georgialibs>

Join our email list <http://georgialibraries.org/subscription/> for stories
of Georgia libraries making an impact in our communities.

On Mon, Jul 13, 2020 at 3:30 PM John Amundson <email address hidden>
wrote:

> Thanks, Jason and Jason.
>
> I performed heavy testing on the OPAC side, (various cards, blocked
> cards, variety of subset of charges, etc). Everything looked great, so
> I'm adding my sign off.
>
> I have tested this code and consent to signing off on it with my name,
> John Amundson, and my email address, <email address hidden>.
>
> That said, I was not able to test the behavior in the staff client since
> we have customization that stops the Credit Card option from appearing.
>
> I was also not able to test the setting change to PayPal.
>
> At this point, additional testing is encouraged, especially in the two
> areas I mention here.
>
> ** Tags added: signedoff
>
> ** Changed in: evergreen
> Assignee: John Amundson (jamundson) => (unassigned)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1774892
>
> Title:
> Wishlist: Upgrade to Stripe v3 (elements)
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> Evergreen currently uses stripe version 2. Version 3
> (https://stripe.com/elements) is now available. Some of the new
> features, such as real time credit card validation and auto-generated
> PCI compliance documentation, would be helpful to both our patrons and
> staff.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1774892/+subscriptions
>

Jason Stephenson (jstephenson) wrote :

Thanks, everyone: Jason, John, and Dawn.

I have pushed a signoff branch to working/collab/dyrcona/lp1774892-stripe-v3-signoff. It adds John's, Dawn's, and my own signoff.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/lp1774892-stripe-v3-signoff

I am also adding the needsreleasenote tag and updating the milestone.

More testing is welcome, particularly of those sites using something other than Stripe for payments.

tags: added: needsreleasenote
Changed in evergreen:
milestone: 3.next → 3.6-beta
Jason Stephenson (jstephenson) wrote :

For anyone who is interested in using this now. The code applies cleanly to Evergreen 3.2.10, so I suspect that it will backport cleanly to 3.3, 3.4, and 3.5 as a local addition.

Jason Etheridge (phasefx) wrote :

Thanks Jason! I've pushed a commit to your collab branch with release notes.

Andrea Neiman (aneiman) on 2020-08-03
tags: removed: needsreleasenote
Galen Charlton (gmc) wrote :

Pushed to master for inclusion in 3.6. Thanks, Jason, John, Dawn, and Jason!

Is there reason not to backport this to 3.4.x and 3.5.x?

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers