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:
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.
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
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.
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
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 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.
- 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: 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.