XF 2.3 Introducing Stripe Checkout, PayPal's REST API and more!

Brand new in XenForo 2.3.0 Beta 2 is support for a few long overdue enhancements related to our payment and purchasable system. Let's look at each of these below!

Stripe Checkout​


Stripe Checkout is Stripe's native and hosted checkout page which not only brings with it some powerful customisability, it also makes accepting new payment methods completely trivial and available in an instant. Allow user upgrades and other purchasables to be purchased with options for "Buy Now Pay Later" (e.g. Klarna, ClearPay), popular region-specific bank redirects (such as iDEAL and Sofort), and popular online wallets (such as Alipay and Revolut). You can even accept payments through PayPal! Through Stripe! 😲

You can enable and configure as many payment methods as you like, and you do this directly through your Stripe Dashboard with zero additional code or configuration required in XenForo. Stripe intelligently and dynamically displays the enabled payment methods they feel will most likely lead to a conversion based on the customer's previous purchases, their geographic location and currency.

This new purchase experience is a drop in replacement for the existing implementation and requires no additional setup or configuration and is available automatically.

PayPal (REST API)​


Our existing PayPal implementation - while absolutely functional - is at least 2-3 generations behind so today is the day we make available a new implementation based on PayPal's current REST API. While functionally this will still be the same as the existing implementation, it is the right time to support PayPal's latest development experience which will continue to receive new functionality and enhancements long in to the future, as well as being more secure and actively maintained by PayPal.

We have implemented this as a brand new payment provider and marked the existing one as deprecated. We are not aware of any immediate plans for PayPal to sunset the legacy Checkout/IPN system we have been using for a long time, so you are free to continue using it. There is no known migration path to move existing customers (particularly recurring payments) to the new APIs but you can enable the new one for new purchases at any time.

The PayPal REST API being available in XenForo should allow developers to implement new, advanced functionality that previously wasn't available.

Ability to update payment details for subscriptions​

Starting with Stripe only, initially, we've added the ability for purchasables and payment providers to be able to "Change payment" for existing recurring payments. In the case of Stripe, clicking "Change payment" takes you to a Stripe Checkout session which allows you to update your payment method.

b7cbwt8dnt.sharedwithexpose.com_account_upgrades.webp


This is a potentially frequently needed piece of functionality which will allow users to, for example, change their payment card after changing banks or having received new card details due to expiry of the previous card. Previously it was not possible for users to update their card details, and usually required the subscription to be cancelled before signing up with new card details.

This is an asynchronous process so once the user provides updated payment details, they will later receive an email confirmation once the new payment details have been applied.

Improved experience for cancelling subscriptions​

It has always been possible for a user to be able to cancel their recurring payment but we didn't do the best job of reflecting that change in the UI. The cancel button would still be displayed after cancellation, and would simply error if you tried to use it again. We now track the cancellation state within the purchasable record and adjust the UI accordingly:

23x.test_account_upgrades.webp


This should hopefully be a much less confusing experience.


That's it for new features in Beta 2. We've got more to come very soon! Thank you to everyone who has helped identify issues and provide feedback for XenForo 2.3 so far.
 
That's your existing payment profile. You would need to create a new payment profile if you want to use the new payment handler.
Gotcha!

Do you know if there will be any issues if I set this up on my 2.3.0. test from while still using the legacyPaypal on the live forum (with existing IPN = https://cafesaxophone.com/payment_callback.php)
 
Yes and XF already had Stripe but now has Stripe Checkout.

I read the page and it said

Stripe Checkout is a pre-built payment form optimised for conversion. Embed Checkout into your website or direct customers to a Stripe-hosted page to easily and securely accept one-time payments or subscriptions.

Increase sales with a better payments experience
We obsess over every detail of the checkout page

Designed to reduce friction
Let your customers breeze through the checkout by making it easy for them to input and reuse their payment information and by helping them spot errors in real time.
Address auto-complete
1-click payment using Link
Real-time card validation
Descriptive error messages
Third-party autofill
Card brand identification
Payment method reuse
Adjustable quantities

Optimised for any device
Provide an optimal experience across mobile, tablet, and desktop with a responsive checkout, and offer Link, Apple Pay and Google Pay out of the box.

Your brand, your Checkout
Customise Checkout’s colours, fonts, shapes, and brand settings to match the look and feel of your site. Embed Checkout directly into your site or direct customers to a Stripe-hosted page.

My conclusion was it helps the checkout process.

Which makes the product well named.
 
Is there a way to use the old PayPal payment provider information instead of setting up a new one with the API?

Nevermind, I see Legacy
 
One thing I noticed about your PayPal REST implementation is you can simplify the setup for XenForo sites. Specifically, you can use an API call to create/update the necessary webhook events being listened for (and also capturing the Webhook ID).

This is really all you need to do (this is my payment profile for PayPal REST, so ignore some of the stuff about Platform App blah blah):

1712517641661.webp


In my implementation, the "magic" happens within verifyConfig() in the payment profile.

PHP:
$webhook = $payPalRepo->createWebhookIfNeeded('', [], $tokenInfo['access_token']);
$options['webhook_id'] = $webhook['id'];

The createWebhookIfNeeded() method reads what events are there, and updates/creates as needed.

Anyway, just a thought if you wanted to make it easier for XenForo license holders (and also probably less support tickets for people needing support).
 
I had issues with this during development. It was my originally preferred approach. Not sure if there was something funky going on with the sandbox API at the time and I can't recall the details but maybe I should.give it another try.
 
I had issues with this during development. It was my originally preferred approach. Not sure if there was something funky going on with the sandbox API at the time and I can't recall the details but maybe I should.give it another try.
It definitely works (in both sandbox and production). Not sure if you are using a library for the API calls (not at a computer to look), but I rolled my own library. Either way, it works, so not an issue with the PayPal API side (for once).
 
Hello, can someone please clarify for me, if with the new Paypal API it will now be possible to:

1. Cancel Subscriptions without the user needing to do so from their paypal.com account.
2. Change the price of subscriptions.
3. Subscription returns
 
...
Biggest ever upgrades to Stripe Connect

Stripe Connect is used by software platforms like Shopify to embed payments and financial services. This provides businesses running on Shopify with access to Stripe products like Payments and Treasury, directly from their Shopify account.

Today, Stripe announced its biggest ever upgrades to Connect, now with 17 embedded components, including 10 for payments. These embedded components make it easy for platforms to integrate fully functional financial services into their website. For example, with the Stripe Capital embedded component, platforms can drop a prebuilt UI into their site and immediately start offering loans to their eligible customers, all powered by Stripe.

With today’s upgrades to Connect, businesses can also now choose more precisely which capabilities they want to own and which to offload to Stripe—and change their choices as their business grows.
...


This was published today. I wonder what opportunities or impact it might have on the XF integration...
 
It doesn't really impact XF directly other than it seems like what we've implemented will automatically receive those improvements.

Though I'm slightly unsure whether "Stripe's Optimized Checkout Suite" is the same as just "Stripe Checkout".
 
Though I'm slightly unsure whether "Stripe's Optimized Checkout Suite" is the same as just "Stripe Checkout".
No, Optimized requires usage of the PaymentIntents API.
 
Although Stripe Checkout uses dynamic payment methods and Link. The only part of that suite we are not using is “Elements”.
 
@Chris D
In the past I have contacted a number of major Payment Service Providers and asked them to provide an integration. At first several were very willing. After they looked at what was needed, they all declined. Do you feel that you have made it much easier now for such parties to create an integration with their platform and its worth asking again?
@Chris D I'd still be very interested to learn your thoughts about ease of integration if you can find the time.
 
To elaborate on my question: After xenforo 2.0 introduced A generic payment framework, I enthusiastically contacted a number of PSP's and asked them to consider adding XenForo integration to their platform. One of the PSP's I contacted was Stripe, as they have previously implemented various of my suggestions into their platform.

Various PSP's were interested. The PSP's that were asked for SDK and I pointed them to the developer docs. They investigated the XenForo dev docs to see how easy it would be to implement an integration. The result was the same: after investigation they all let me know that they found the implementation too difficult. I'm not sure if this was due do the code itself or to the availability of SDK/clear documentation on the topic. I asked for clarification, but didn't get any.

As you have now implemented Stripe and PayPal REST API, I assume that you may have encountered similar difficulties that the PSP's encountered. Have you made any changes to the XF generic payment framework to make it easier to create payment profiles for new PSP's or payment methods? Do you think the PSP's would encounter the same issues they encountered before or have XF payment profiles easier to implement in any way?
 
Have you made any changes to the XF generic payment framework to make it easier to create payment profiles for new PSP's or payment methods?
No.

Do you think the PSP's would encounter the same issues they encountered before or have XF payment profiles easier to implement in any way?
I don’t know what issues they may have encountered before so I’m unable to comment.

The payment framework is basically the same as it has been since 2.0.

If you’re able to pass on any feedback they might have been provided that would be constructive but otherwise it seems to me they probably just don’t want to or don’t see it in their interests to do so.
 
Side note on the cancellation side of things, I ran out of time so I didn't actually add cancellation support for the PayPal REST handler yet, but we'll try and get that into Beta 3 once I've gotten over the initial trauma of working with PayPal.

Running 2.3.3, I just test-purchased a PayPal recurring subscription and a Stripe recurring subscription. Only the Stripe one is showing a cancel button. Has cancellation for PayPal subscriptions made it into 2.3.3? Unfortunately I'm in a country that does not have PayPal-via-Stripe, so I need to use your native PayPal option.
 
Back
Top Bottom