Our first set of releases since Halloween 🎃 builds on the reader-facing improvements we’ve been working on with the WooCommerce-based modal checkout process. All of these fixes and improvements should hopefully add up to a smoother, more customizable experience for readers at a critical moment—right before they decide to give money to your site.

In addition to checkout improvements, we’ve also added features to Newspack Campaigns to segment readers by active subscription product or membership, if using the WooCommerce Subscriptions and Memberships extensions.

In more detail:

Option to cover Stripe’s transaction fees during checkout

Newspack’s modal checkout UI for WooCommerce now supports a feature that allows readers to opt into covering Stripe’s transaction fees for donations at the point of checkout. In the Newspack > Reader Revenue > Stripe Gateway admin page, you’ll now see a new set of options for “Transaction Fees”:

These options let you configure how much extra to add to the transaction’s total. The default values are set to Stripe’s standard 2.9% + 30¢ fee.

When prompted to enter payment details during a donation transaction, the reader is presented with the option to cover Stripe’s transaction fees. If they opt in, the total amount of the transaction will be increased by the configured amount.

When considering the option to enable covering fees by default, please be aware of regulations in your area of business which may require positive user opt-in for added fees.

Note that this feature is currently only available for credit card donations via the Stripe Payment Gateway plugin, which is Newspack’s standard payment solution for WooCommerce-based sites.

Configure your site’s reCAPTCHA v3 threshold

Newspack integrates with Google’s reCAPTCHA v3 to protect several important reader interaction touchpoints: reader account registrations and logins, newsletter signups, donations, and other WooCommerce purchases made through our first-party Newspack tools. reCAPTCHA v3 protects these interactions from bots and other suspicious activity, and works in a seamless, invisible way that doesn’t add any friction on the reader’s part—unless they’re stopped in their tracks by a false positive.

False positives in reCAPTCHA v3 can and sometimes do happen. Because reCAPTCHA v3 works without any direct user input, false positives can be a frustrating, show-stopping issue for readers, leading to lost conversions as readers seemingly have no choice but to abandon their action.

For this reason, reCAPTCHA v3 provides a tool called the threshold, which tells it how strict it should be when evaluating user action attempts. When evaluating user interactions, reCAPTCHA v3 returns a score between 0 and 1.0 that shows how confident the system is in the interaction’s botness vs. humanness. The lower the score, the more suspicious it is. The higher the score, the more likely it is to be human. Read here about how reCAPTCHA v3’s scoring system works.

The default threshold of 0.5 should be optimal for most sites. But if you’re seeing a lot of spam activity or reports of false positives from your readers, you can now tweak the threshold for reCAPTCHA in the Connections admin page. This allows you to decide how strict its checks should be. A higher threshold makes the checks stricter (attempts are less likely to be allowed), while a lower threshold makes the checks more permissive (attempts are more likely to be allowed).

When tweaking the threshold value, we recommend keeping the value as close to 0.5 as possible. At 0, reCAPTCHA will allow every attempt, rendering it totally useless. at 1.0 or higher, reCAPTCHA will reject every attempt, making protected actions impossible to complete. Finding the optimal balance for your site and your readers may take a little experimentation.

Post-checkout options: now available for Donate blocks

The last set of releases added a new feature to Checkout Button blocks, allowing publishers to display an optional action button to readers after completing a successful transaction. This week’s releases make this same feature available to the Donate block.

Dynamic billing names for receipt emails

We now support a dynamic tag to populate the customer’s billing name in customizable receipt emails. When editing the customizable receipt email on the Newspack > Reader Revenue > Emails admin page, you can now use the *BILLING_NAME* placeholder to dynamically populate the customer’s or donor’s name as entered during checkout.

Modal checkout fixes

In addition to the new features described above, we’ve also fixed two issues that some publishers have reported:

Fix: Billing fields for WooCommerce extensions

Our modal checkout templates were missing an expected id attribute for some billing fields, causing extensions that rely on that attribute to fail during checkout. Known plugins affected by this bug include WooPayments and the ELEX WooCommerce Address Validation plugin.

Fix: Post-checkout options for instant payment methods

The new post-checkout button options for Donate and Checkout Button blocks should now work for instant payment methods (i.e. Apple Pay, Google Pay, etc.) as well as credit card-based payment methods.

Campaigns segmentation: Target readers by subscription or membership status

For sites using the WooCommerce Subscriptions and/or Memberships extensions, the Newspack Campaigns plugin now supports segmenting readers based on their non-donation subscription and membership status.

We’ve slightly reorganized the “edit segment” admin page for easier readability. The Reader Activity section has been broken out into three different sections—Registration, Newsletters, and Reader Revenue:

The new segment criteria options are:

• Has active subscription(s): Matches if the reader has an active subscription with at least one of the selected products.
• Does not have active subscription(s): Matches if the reader does not have any active subscriptions with any of the selected products.
• Has active membership(s): Matches if the reader has an active membership with at least one of the selected membership plans.
• Does not have active membership(s): Matches if the reader does not have any active memberships with any of the selected membership plans

Together, these options should provide you with more flexibility in communicating directly to paid subscribers and members, or with readers who haven’t yet purchased specific subscriptions or memberships that your site might offer.

Other changes

Some smaller changes that are still worth noting:

The Mailchimp for WordPress plugin (MC4WP) is no longer recommended

Our first-party Newspack Newsletters plugin and its Newsletter Subscription Form block are a straight upgrade from the MC4WP plugin, which was long the recommended solution for publishers wanting to connect their sites to a Mailchimp account.

Because the Newspack Newsletters plugin integrates seamlessly with other Newspack products, including Newspack Campaigns and reader account features, we now recommend that all sites using MC4WP replace the use of that plugin’s forms with the Newsletter Subscription Form block in Newspack Newsletters. Please reach out to your TAM if you’re unsure about whether or how to proceed with change.

Copy change for Homepage Posts block settings

We’ve heard feedback that a popular feature in the Homepage Posts block was very hard to understand (blame the Product Engineers). So, we’ve changed the wording of the “Use deduplication logic” feature to the more plain-English “Allow duplicate stories”. The feature itself is unchanged, but hopefully its wording clarifies what it does.

Next release cycle

Our next release is scheduled for the week of November 27, or the week after US Thanksgiving. In the meantime, we wish a happy Thanksgiving to all who plan to celebrate.

– The Newspack Product team