Version 3.2 released with Stripe SCA compliance

Restrict Content Pro version 3.2 is our first Strong Customer Authentication update, with a focus on the Stripe gateway. Our Stripe gateway now uses their Payment Intents API, which adds support for 3D secure. We also took this opportunity to add inline card rejection notices for Stripe. However, as part of updating our Stripe gateway to comply with SCA regulations, we’ve had to remove the Stripe Checkout gateway – but this will not impact your payments or subscriptions.

Stripe Payment Intents API & SCA support

The Stripe gateway has been completely refactored to use the Stripe Payment Intents APIinstead 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.

Upgrade to version 3.2

Version 3.2 is available today. The update can be installed directly from the Plugins page for all customers with a valid license. Do not have a license yet or need to renew a license? Head over to the pricing page to purchase one or to your account page to renew an existing license.

Similar Posts


  1. Will the [register_form] be affected for standard paypal payments?

    On another note, if there was a function in RCP to send short emails to subscribers according to subscription level that would be a major addition to functionality. Or is there is a plugin to do that according to level without subscribing to third party services?

    1. The PayPal Standard gateway hasn’t had any changes. It’s up to PayPal to make any SCA changes on their end.

      We don’t have any plans to build our own mass mail tool at this time, but Restrict Content Pro does integrate with a variety of email marketing plugins, including MailChimp. Our MailChimp Pro add-on allows you to add customers to different mailing lists or groups based on their membership level. You could use that to segment and send different emails to customers on different membership levels.

  2. Hi Ashley,

    To start with thanks for the excellent and quick support you provide.

    There is one problem with using third party mass mail tools: some customers with their own domain name make a new email address for subscribing to a blog that is specific to that blog. In case the mass email third party sells those emails then you can get into trouble because the customer will think you sold it. especially from countries that have strict laws, such as Canada.

    Does the above make sense as a valid reason to have built in mass email in subscription package? Any suggestions for something that integrates with RCP but does not go through third party?

    1. Hi Michael,

      All the mass mail tools we integrate with are very reputable. I’m afraid we don’t have any plans to build our own mass mail tool at this time. We do integrate with at least one “self hosted” mass mail tool plugin (MailPoet), so that’s always an option if you prefer to keep it all in house.

Comments are closed.