Stripe Question: 'Prebuilt Checkout page' or 'Stripe Elements'?
We're building the checkout flow for getassigned.com at the moment. I've seen a few sites start to use stripe's Pre-built, low code checkout page, so I'm wondering if anyone has an opinion on it.
I'm trying to decide whether to use Stripe's 'Prebuilt Checkout page' or 'Stripe Elements' to make a custom payment flow. Any feedback or thoughts would be great!
EDIT: For anyone who cares, we decided to use the Stripes payment element to keep the domain consistent and attribution tracking in tact throughout the checkout flow. I think it looks pretty good (screenshot below)
Trending on Indie Hackers
Google Whisk - Generate images using images as prompts, not text prompts
After 19,314 lines of code, i'm shutting down my project
Need feedback for my product.
40 open-source gems to replace your SaaS subscriptions 🔥 🚀
We are live on Product Hunt
We built PriceWell on top of Stripe Checkout and Customer Portal. We have the same flow as you (create Stripe customer in the background) and haven't found an issue using the Billing Portal to offer upgrades (including entering a credit card). We have a paywall in front of features that aren't supported on the free plan so users are really forced to pay if they want to use them.
Thanks for the info!
Interesting timing for me on this question as I am working on this right now.
For 2 years Navexa has been using Stripe's Card Element to capture credit cards, but recently I decided to switch to the pre built checkout. However....
I found a couple of big issues for our flow using the pre-built page that we are now using Stripe's new Payment Element on a custom page.
When a customer registers with Navexa we automatically put them on a Stripe subscription behind the scenes with a free trial for 14 days. This is so our billing analytics package (Profitwell) can track trials and conversion rates etc. We do not ask for a credit card upfront.
Now heres the problem with the pre-built page... You cannot launch a Checkout session with an existing subscription. Has to be a new one. So that left me with the option of having to use the billing portal instead to allow a customer to add their card for the first time.
However I felt that for the intial purchase, dropping them in the billing portal wasn't a nice flow as there was no conversion focused flow there about adding a card.
So thats what lead me back to using Stripe Payment Element, which allows multiple payment options like GPay and Direct Debit etc and now I can use copy related to our product on the payment screen, while still leveraging "Powered by Stripe" logos, to convey trust.
Hope that helps.
That's actually super helpful and pretty much in-line with my thinking. We ended up going with Stripe Payment Element too. I updated the original post with a screenshot of what it looks like. I think it looks good.
I use the pre-built checkout and customer portal for PowerImporter.
It's great!
But there are a few caveats if your customers can have multiple subscriptions with the same account. 👇
Great post! Thanks for the heads up. I think we’re going to try using Stripes payment element which seems to be a nice hybrid. Between full code and no code.
I liked the pre-built for being easy to get going. However, I ended up having lots of with lots of trouble with failed payments and didn't have a lot of options. It was postpaid, usage-based billing.
I wish it was easier to do pre-auth checks on cards for subscriptions.
I have a client whose actually running into the same probably (tons of failed payments) this was for sure another concern.
The pre-built checkout is great. I think it also adapts to the payment methods that are common to your customers location. I can also recommend the payments gem if you're using rails. It just took me a couple of hours to build a subscription checkout including the customer dashboard.
What is the payments gem?
Is that their new payments element?
It's a gem (package) for ruby on rails that supports stripe as a payment processor. It makes the integration of stripe into a rails app even easier. You basically just have to add one line to your user model and add a controller for the stripe webhooks. It's just called pay (not payments as I said in the first post).
Interesting! Thanks for explaining. (I'm for sure a marketing guy first, not a dev, so the extra info helps a ton!)
Prebuilt page!
I recently switched my SaaS from using a customized Stripe elements flow to using their pre built checkout and customer portal (which didn't exist when I built the first version).
You get things like upsells to annual plan, switching plans, invoice list, all included! Also take into account that nowadays you need to support secure checkout with 2FA if you use elements, which is a hustle to work with and prebuilt page takes care of it for you.
Save yourself the time and frustration :)
Good to know, I think initially we’re going to try elements because Ideally is like to keep everyone on the domain for session attribution. Id also like to capture the purchase value in Google analytics
Used Stripe's solution because it was quick. Have no plan to switch.
Good to know. Thank you!
I used to use Stripe elements, but I recently switched over to using checkout for https://mylinks.ai
Reasons:
Anecdotal but levelsio got a pretty significant signup increase from using Stripe checkouts: https://twitter.com/levelsio/status/1449821367734444033
Forgot to mention, but implementing Stripe Checkout took less than a day.
Interesting! Thank you for the detailed feedback. It's something I've flip flopped on for a bit now. Though It looks like the prebuilt option doesn’t allow for GA tracking, so that decides it for me. I think we’re going to try elements.
We’re also considering A/B testing them to double check conversion rate. luckily, I'm in no rush with this, so I will report what I find!
What events do you plan on tracking? You should be able to fire events from a thank-you page if you're mainly looking for purchase events. And I believe there's the Measurement Protocol if you want to send events from the backend (haven't used it).
Just the basics, checkout started, and successful purchases but I'd want to make sure the value is associated with the event so that value can be attributed to each channel.
I would also want to attribute actions following purchase back to the original source. It would seem when a person comes back to the site after purchasing, that would start a new session attributed to direct instead of the actual channel they came from
Stripe checkout and customer portal easily. Stripe elements requires a lot of custom code and error handling.
Got it! Is that the case even with the new payment element? https://stripe.com/docs/payments/payment-element
Nice, this actually looks like it solves your use case better.
Sweet. Going to try it. Could be a disaster, but who knows. haha
How does it handle SCA and RBI etc?
No clue! Haven't read that far into it yet.
My SaaS ($1000 MRR) uses Stripe checkout. Initially I was thinking "Use this checkout thing for now, and then build your own payment page". I still haven't built my own payment page.
I agree with @alxmaroi, Stripe's checkout page does seem more trustworthy.
I would create my own payment page if I thought it would convert better. Not sure that it would though.
This seems to be the consensus. Though luckily we're in no hurry. Initially, I'm going to go ahead and try the new payment element which seems to be a feature that takes care of a lot of the issues people have run into with the card element.
I have 0 data to back this up, but I believe using Stripe Pre-built (or something like PayPal Checkout client-sided) is actually better for a new project. Not just because it's easier to implement, but it also feels more trustworthy for your users.
Think about it, if you didn't know anything about coding, would you feel safer entering your CC in a random website, or via Stripe's own website?
That's interesting. My only thought there would be if a lay person knows what Stripe is and in the scenario they don't, would it still look more secure being on a new domain?
Not sure if this helps out, but we have the pre-built, low code checkout page at the moment because it was much faster to set up, but longer term it lacks the flexibility we need so we are planning on switching to Stripe Elements.
I would say it depends on how much time you have. If you need something done asap, you can put up the prebuilt page in like an hour. If you have more time and need more flexibility use the Prebuilt Checkout page
I think I'm going to try the Prebuilt Checkout page. We've got some time and I feel like if it's turning into a pain, we can fallback on the pre-built thing.
This comment was deleted 2 years ago.
Mostly domain design consistency, but also session attribution and being able to track the value of the purchase in Google analytics.
This comment was deleted 2 years ago.
Thanks for the info. We ended up going with the payments element (not the card element. ) I added a screenshot of what it looks like in the original post. I think it looks good!