Product update

Version 3.2 includes significant changes to how Stripe payments are processed, but most importantly, it adds support for the Stripe Payment Intents API, which complies with the Strong Customer Authentication (SCA) regulation in Europe. However, we have also removed the Stripe Checkout gateway because Stripe will not be updating it to comply with SCA.

How to test the beta

In order to help ensure the final release of 3.2 goes as smoothly as possible, we need your help testing this beta version.

Testing the beta is very simple. Simply log into your testing site that has Restrict Content Pro installed and activated and navigate to Restrict → Settings → Misc and check the box for Opt into beta versions:

Opt in to Restrict Content Pro beta versions

The beta update will now be available as a standard WordPress plugin update from your Plugins page, though it could take up to a few hours for the notification to appear.

See our FAQ if you have any questions or issues updating to the beta version. If you encounter any bugs, please let us know through our support page.

Note: we do not recommend you test the beta on a live site. Use a testing site. While we do our very best to not cause issues during updates, sometimes issues do slip through unnoticed, so having a staging / testing site is very important.

Stripe Payment Intents API & SCA support

The Stripe gateway has been completely refactored to use the Stripe Payment Intents API instead of the old Charges API. The Payment Intents API complies with the Strong Customer Authentication regulation in Europe by adding support for 3D Secure when it’s required to complete the payment.

If a card requires 3D secure for an automatic renewal payment then this is also now supported on the [rcp_update_card] shortcode when the customer re-enters his or her card details.

Inline card rejection notices for Stripe

The initial charge for Stripe is now handled via JavaScript, which allows us to show inline errors if a card payment is declined.

Inline "Card Declined" error message

This allows for a much better user experience, because the customer can then simply adjust their card details and try again without needing to reload the page.

Right now this feature is only available with the Stripe payment gateway, but we expect to add support for other gateways in the future.

Removal of Stripe Checkout gateway

In version 3.2, the Stripe Checkout gateway has been removed. The Stripe Checkout gateway utilized Stripe’s Checkout API, which opened up a modal with a Stripe-hosted card form.

Unfortunately Stripe is no longer recommending the use of this modal and they will not be updating it to support the Strong Customer Authentication requirements. As a result, we have decided to remove it from Restrict Content Pro.

What happens if I’m using Stripe Checkout now?
If you’re currently using Stripe Checkout then you will automatically be swapped over to our normal Stripe gateway when you upgrade, which uses Stripe Elements.

Will this affect my existing subscriptions?
This change is a design change only; it does not affect payment processing or renewals. Customers who have recurring subscriptions that were created via Stripe Checkout will still have their renewal payments processed by Stripe and picked up by Restrict Content Pro.

What will the registration form look like?
The [register_form] shortcode will no longer open up a modal for accepting card details. Instead, the card fields will be loaded inline using Stripe Elements.

Stripe Elements card form

What if I’m using the [register_form_stripe] shortcode?
The [register_form_stripe] shortcode is here to stay! However, you should expect some styling changes. This shortcode will no longer display a Stripe-hosted buy button or open up a Stripe-hosted modal. Instead, it will output a normal <button> element. Restrict Content Pro does not apply any styling to this button, so it will be styled according to your theme’s stylesheet. When clicked, a new custom modal will load with Stripe Elements card fields inside.

This new modal is entirely hosted on your site (with the exception of the actual card field), which means you will now have more control over styling how the modal and trigger button look with custom CSS.

Important notes for developers

Version 3.2 has seen some significant changes to how the registration form is processed via JavaScript and to how the Stripe payment gateway functions and handles payments. If you’ve added custom code to your site that involves either of these features then we recommend reading through our list of changes below.

Global registration form JavaScript changes

These changes apply to all payment gateways. You may only be impacted if you’re using custom JavaScript to interact with or modify the registration form. Previously, only one part of the process was handled via ajax: the initial form field validation. In version 3.2, we also perform some initial membership processing via ajax. This includes creating the new user account, the pending payment record, and the pending membership record.

Stripe gateway: the first payment is always a one-time charge

If a customer signs up for a new recurring membership, the first payment (the one due immediately) is always processed as a one-time charge in Stripe. A subscription is then also created with a delayed start date. This will appear in Stripe as a trial period, as using their trial parameter is the best way for us to delay the start of the subscription until the next billing cycle.

Stripe gateway: no longer uses Stripe Coupons or account balances

In the past, all Restrict Content Pro discount codes were synced with Stripe Coupons, and these Coupons were then used when applying recurring discounts. Instead of applying a Stripe Coupon we now create unique Stripe plans for each price / duration combination. If someone signs up for a “Bronze” membership at $10/month, then RCP will automatically create a Stripe plan at $10/month. If someone signs up for the same membership with a 50% off discount code, then RCP will automatically create a new Stripe plan at $5/month.

Discontinuing our use of Stripe Coupon codes allows for a lot more flexibility in registration prices. If you use the rcp_subscription_data filter to change the recurring_price, then this amount will now actually be used for the Stripe subscription (whereas in the past it was not).

Restrict Content Pro utilized Stripe Customer balances to account for signup fees or credits. In version 3.2 this is no longer necessary because the initial payment is always a one-time charge, so we can specify the exact charge amount instead of using balances to change the amount on a subscription invoice.

Stripe gateway: changes to the rcp_stripe_charge_create_args filter

The rcp_stripe_charge_create_args filter used to be applied to the arguments passed through when creating a new Stripe Charge. This filter is now deprecated because we no longer use the Charges API. We have introduced a new filter called rcp_stripe_create_payment_intent_args, which filters the arguments used to create a Payment Intent. Compatible arguments from the old filter will still work, but we recommend updating any custom code to use the new filter.

Full changelog

  • Important: Stripe Checkout gateway has been removed. If you’re using it, you will automatically be changed over to our normal Stripe gateway, which uses Stripe Elements. The [register_form_stripe] shortcode still functions, but it may look different.
  • New: Updated the Stripe gateway to use Payment Intents API. This complies with SCA regulations.
  • New: Stripe card declined notices now appear inline and no longer require a page refresh.
  • New: Added %update_billing_card_url% template tag, which serves as a direct link to the “update billing card” page for the membership associated with the user’s most recent payment. Recommended for use in the Renewal Payment Failed email.
  • Tweak: Changes to registration form JavaScript. Initial membership processing is now handled via ajax. Testing is recommended if you have custom code that interacts with the registration JavaScript.
  • Tweak: The first payment in a Stripe subscription is now always a one-time charge. The subscription is created with a delayed start date (until the next billing cycle).
  • Tweak: Stripe gateway no longer uses Stripe Coupon codes. Instead, new plans are created for each duration/amount combination.
  • Tweak: Stripe gateway no longer handles signup fees via customer account balance. They are incorporated into an initial one-time charge that handles the first payment.
  • Tweak: The “rcp_stripe_charge_create_args” filter is now deprecated and replaced with “rcp_stripe_create_payment_intent_args”. This is due to replacing the Charges API with the Payment Intents API. Some arguments may now differ.
  • Tweak: Stripe error messages are now able to be translated.
  • Fix: Stripe gateway doesn’t use the “recurring_price” that’s passed into the gateway class.
  • Fix: Stripe incorrectly applying one-time discounts after a free trial.

Release date for 3.2

The beta version of 3.2 is available today and we hope to release the final version on or near the 10th of September.

Ashley Gibson

About the author: Ashley is the development lead for Restrict Content Pro. When not working on Restrict Content Pro, she enjoys weightlifting and reading.

4 comments

    1. Hi Steve,

      You can download the beta from your account area if you’re interested in testing it. We haven’t yet published a beta release post, but it is available. We’ll be publishing a release post later this month. We got a bit delayed with that with our focus on SCA.

  1. The inline card declined notice is brilliant – so much more elegant.
    It’d be great to be able to customise the message…

    “Sorry – your card has been declined – you may want to try a different one” etc…

    Thanks,
    Mark

Comments are closed.