krileonProbably been wondering what I've been doing lately since returning from vacation. I've been working on a rewrite of a large portion of CBSubs Stripe payment gateway. A lot has gone into making it easier to maintain and using latest APIs for a more stable and feature-full payment gateway. Check out the details below!
First and foremost you should notice no negative difference in using the latest CBSubs Stripe. Under the hood a lot has changed, but you and your users should not notice any functional difference when making payments.
What has changed is how API versioning is handled. Previously you needed to select a Stripe version in CBSubs Stripe that would be compatible with your Stripe account. This is no longer necessary. We now version all our API calls and it is no longer something you need to be worried about. The version in your Stripe account will now only impact Webhooks, which we are providing backwards compatibility for.
Next is we no longer allow optional customer objects and strong customer authentication (SCA). These are now enabled at all times and their parameters for toggling them off are now removed. This allows us to better control the flow of payments, associate payments with users, and associate payment methods with users where needed. This then also simplifies your configuration as it's no longer a question of "should I use this?" as in the case of SCA yes you should have always used it as it's more secure payment authentication.
Under the hood we've moved old payment tokens, sources, and payment methods APIs to the newer payment intents API. This applies to many payment methods, including SEPA, and more. The payment intents API is rather significantly easier to use, handles all middle steps (e.g. authenticating bank accounts, 3DS checks, and more), and is faster. This has significantly reduced our maintenance overhead for Stripe and will expedite implementing additional payment methods as they become available at Stripe.
If you're using hosted checkout payments this now supports recurring subscriptions with an initial price and duration different from regular price and duration. Previously this wasn't possible. You will however notice it says the initial duration is a free trial. There is unfortunately nothing we can do on our end to change what that says specifically, but we'll be keeping an eye on the API as time progresses to see where this can be improved.
This leads us into the next note. Subscriptions with a different recurring price and duration from the regular price and duration previously was done with a secondary charge request. This is no longer necessary. We were now able to consolidate this into a single API request reducing chances of failure, increasing speed of payments, and all around being more reliable. We were able to remove hundreds of lines of code bloat due to this simple change.
Now onto the new features. The payment method FPX is now supported for Inline and Checkout payments. The payment method BECS Direct Debit is now supported for Inline payments. The payment method BACS Direct Debit is now supported for Checkout payments. You can also now select payment methods for hosted checkout instead of only accepting card payments. Failed payment webhooks should now properly log for failed recurring payments and failed pending payments.
Last but not least the Stripe Customer Portal has been implemented for recurring payments. This allows users to change their payment method for recurring payments themselves. Currently Stripe only allows change payment methods for card payments. You'll find the new parameter below within CBSubs Stripe to enable this functionality under the Presentation parameters.
Once enabled users can use the Change Payment Method button next to the Unsubscribe button when viewing their subscriptions as shown below.
This will take them to their Customer Portal at Stripe where they can view billing history (optional) and change their attached payment method as shown below.
In addition to this all experimental payment methods include a notice. Experimental payment methods are untested. They are untested due to limitations of those payment processors (strict regulation) and it is not possible for Stripe, at this time, to spoof their API responses to test them. They can only be tested with verified accounts in the country of that payment processor. Some additional restrictions may apply. So due to all of this I am not able to test them. However, they are implemented as per their API has instructed so they should work, but I advise you to take caution and perform a test payment first (link to do this is provided in each notice). See the below for example.
Please let us know if you should have any issues with Stripe payments on our support forums. All payment methods, except SEPA, have been retested. This includes single and recurring payment methods. As for SEPA we were unable to do a test due to Stripe being unable to provide test mode for accounts that do not have SEPA enabled on a live account. We however we able to review API responses for SEPA and since it uses payment intents appears that it will continue to work perfectly fine.