So I had cloned the offer because it was the exact same, but I'm almost positive I deleted all of the attached info from the person that won last time.

Currently /support and /support/member-benefits send users to the same URL when they submit the form. This will need to change, so we need to make it configurable.

Realizing that changing the /support page settings also changes the site footer, so I'm going to give us a way to keep the footer separate.

So we can tell users what the minimum level is if they don't qualify for mug/water bottle.

1. $x monthly to $x/month
2. $x yearly to $x/year
3. $x one-time to $x one time

This should not affect how any buttons themselves appear, but rather any headings, modals, and plain text areas.

It comes back to a URL like this: https://www.minnpost.com//support/?amount=250&frequency=one-time&campaign&customer_id&swag=waterbottle&atlantic_subscription=true&nyt_subscription=true&decline_benefits

This ought to work, but it doesn't fill in the benefit settings.

Noticing, though I should've sooner, that when the thank you gifts select a level, bronze is level 0. This is inconsistent with how other benefits work across the site, where a non member is level 0.

Like on this URL: https://www.minnpost.com/support?frequency=monthly&amount=8

$8/month is a predefined radio button, but it's not selected. Instead it's in the custom amount field.

We have at least one user who has claimed offers three months in a row. The first of those claims should have prevented them from being able to claim again.

As part of this issue:

• List all failed opportunities. Give users an edit link if they can resubmit them.
• List all Closed Won opportunities

When we have a URL like https://www.minnpost.com/support/?campaign=7010G0000012fXGQAY, the plugin settings should allow for default frequency, amount, etc. settings to be configured for that campaign. They'd be overridden by URL parameters still, but that would be the default.

Noticed this when testing a deletion of bronze and addition of leadership level. It doesn't work at all.

There's a PHP library here. Plaid does not appear to provide its own library, but this one appears to be maintained.

This should allow admin users to configure the content and, to some degree, the appearance, of the site header call to action for donating.

We should do this by using the new hooks in our analytics plugin. Things to edit:

• amount-select.js
• cta.js
• track-submit.js

It's a border, but maybe it should be a background color instead, or a darker border, or something?

Based on the WP user, the Stripe Customer/payment method, and the SF Contact, we'll need to create one time opportunities or recurring donations in Salesforce.

• Setup Google analytics to track entire donation flow
• Track how many people are visiting support page vs. how many people complete the donation
• Identify what would need to get done in order to track individual actions on the donation page
• Nice to have: See people going from donation page to the membership level page and if they come back and finish the donation (does their amount of donation change?)

We need to be able to manage the site footer's donate CTA. At least initially, the idea is to use a small form for this purpose.

As part of this issue:

• Show open recurring donations
• Show pledged opportunities
• Link to donate if user has not donated
• Link to donate history

This is a quick one to go ahead and merge because if header-support.php doesn't exist, it will just continue to use header.php.

We should map the user's Salesforce account ID and then check for it. If it's there, we should use that to load the user's donation history instead of their contact id.

It passes the number with the decimal values but without the actual decimal, so it's $1500 instead of $15.

Upgrade gulp to 4.

This is the path we'll need to take when a user starts a transaction. We'll need to see if the customer exists by email in Stripe, update them if they exist, and create them if they don't, all only if they've supplied a valid payment method.

Based on the Stripe customer, and the logged in WordPress user if applicable, we'll need to check for the existence of a Salesforce contact and update it if it exists, or create it if it doesn't.