#camel-checkout-legacy

1 messages · Page 1 of 1 (latest)

marsh troutBOT
indigo wagon
#

HI 👋

Can you share the exact text of the warning you are receiving?

strange nova
# 
You’re using the legacy version of Stripe Checkout.

We released a new version of Checkout in April 2019, which supports mobile wallets and other payment methods:
https://stripe.com/docs/payments/checkout

Learn how to upgrade to the new version:
https://stripe.com/docs/payments/checkout/migration
indigo wagon
#

Are you creating Checkout Sessions on your front-end?

#

WIth Stripe.js?

strange nova
#

We load it from https://checkout.stripe.com/checkout.js

#

And no, we don't create Checkout Sessions on our front-end. That's the "new" mechanism.

#

The old version presented customers with a modal dialog that collected card information, and returned a token or a source to our website

#

Which we then sent to the server, and from there to Stripe in order to update the customer's payment method

indigo wagon
#

So we "Deprecated" that flow quite a while ago but we won't actually shut it down. However, we are no longer updating it so we strongly recommend you update your integration to use server generated Checkout sessions

strange nova
#

OK, got a question about server-generated checkout sessions

marsh troutBOT
burnt sand
#

camel-checkout-legacy

strange nova
#

In our app, we have a 14 day trial. When a customer first signs up, we create a subscription. Then we give them the ability to add a payment method.

In the current mechanism, it uses the old version of stripe checkout. Customer enters their card info into a modal, Stripe returns a token, we send it to the server and then make a call to Stripe to add it as the customer's source. Then, when the trial period ends, Stripe automatically charges that source.

How would this work in the new mechanism with Checkout Sessions? Do we use mode=setup when initially creating the checkout session?

burnt sand
#

@strange nova that works though we highly recommend having Checkout just create the Subscription with the trial for you

strange nova
#

But that would require us to collect credit card info from the customer at the time of sign up, no?

burnt sand
strange nova
#

Hmm

#

In our current flow, when a new customer signs up, we first create a Stripe Customer, then take the returned customer_id and create a Subscription. We provide two plan_ids in this API call (our pricing is based on user seats and we have two types of users, and each plan_id represents one of them)

#

How would this work with Checkout Sessions?

burnt sand
#

You create a Checkout Session id with the relevant information, it's one call then send them to our hosted Checkout page (or render it embedded on your website). It really "just works".

strange nova
#

Can we avoid sending them to the hosted/embedded checkout page during signup? Basically, we don't want to show any sort of purchase page during the initial flow

burnt sand
#

You could but then you basically keep your current flow mostly and don't use Checkout at all for that.

strange nova
#

OK, so then we would use Checkout only for updating the customer's payment method during their trial

#

using mode=setup as I mentioned previously

burnt sand
strange nova
#

With setup=mode, should the rendered Checkout form display any previously entered credit card info? So that the customer has a way of seeing what card they may currently have on file?

burnt sand
strange nova
#

this seems to only cover payment and subscription modes

#

how does it work with setup mode?

#

for example, on the second day of their trial, customer fills in their payment info

#

then they come back a few days later

#

how do they know which card they previously entered?

burnt sand
#

You really should use the Customer Portal for this, not Checkout

#

no different from what you have today honestly since Legacy Checkout never showed previous card(s)

strange nova
#

legacy checkout never showed previous version cards, but the stripe response to adding a source includes last4 and expiration so we store those in our db and then show them to the customer as a "this is the card you have on file" (we checked and verified that this doesn't break PCI rules)

burnt sand
strange nova
#

OK, that makes sense

#

Last question (kind of unrelated to checkout): when a customer has multiple payment methods, how do we set one of them as the preferred/default, for the purposes of which one should be used to pay our subscription's invoice?

burnt sand