#jbodily-elements-redirect

1 messages · Page 1 of 1 (latest)

wispy quiverBOT
solemn epoch
#

jbodily-elements-redirect

hardy sandal
#

More info: I've cloned and tried out the Checkout demo, but the demo's default is to redirect to https://checkout.stripe.com/ to finish payment, which is not conducive to our flows. I'm hoping to rig up an in-app solution that is 3 steps: 1) collect info, 2) review payments, 3) finalize. On step 2, we'd like to be able to show applied tax and promotions. Again we'd like to do this without leaving our checkout flow

solemn epoch
hardy sandal
#

It's not preferrable, no. I'm curious because with Elements, we can embed the form on our page. This means we're able to collect payment information and then do the work of starting the subscription in our backend. Is that best practice?

#

Or is there a best practice?

#

Or is there a way with elements and our backend to submit something to Stripe akin to a checkout session so we can get precalculated tax, discount prices, and dates of future initial payment to then send that back to our client?

solemn epoch
#

I'm sorry I'm not entirely following you

#

Checkout is an entire product, it does a lot of things: tax, shipping rate, discount calculation, etc.

#

If you don't want a full page redirect, you can not use it, in which case you do need to use one of our UI Elements, we have a few

#

which one are you using right now?

hardy sandal
#

We load https://js.stripe.com/v3/ and use window.Stripe to create a card element. We collect their payment info, but don't currently have a way to display the associated tax and promo effects.

solemn epoch
#

ah okay

hardy sandal
#

How does one get estimated tax and promo information with UI elements solutions? I'm envisioning us sending to our backend the fact that the customer has stripe_customer_id xyz and that that customer intends to start our SPECIAL subscription. What endpoint do we hit from the server to get a preview of that transaction?

solemn epoch
#

yeah no that is basically impossible. We don't have any other UIthat does show the tax, promotion code, etc. and no plan to build one soon at least

#

so you'd build all of this yourself

hardy sandal
#

See my comment above^ Is there no API we can hit from our servers that says "If customer x starts sub y then taxes are z and promo application is valid"?

#

That would be a call not from Stripe's UI Elements, but would be after we use UI elements to collect info and then I'm assuming there's some way to use the primary python API to get more details?

solemn epoch
#

I don't really understand that question.

#

Sorry, you likely integrated years ago, our API and offering changed multiple times since

#

for example our recommendation is to create the Subscription first and then confirm client-side the payment

#

So I'm struggling to understnad what part is blocking you/unclear

hardy sandal
#

🤔 How do we show taxes to be charged in that scenario

#

If we want a "confirm/review your purchase" page, how would we show the exact totals someone will be charged?

solemn epoch
#

who is calculating the tax in the first place though. Are you using Stripe Tax and automatic tax calculation? something else?

hardy sandal
#

Yes, we have a Stripe Tax integration

solemn epoch
#

okay so it can't be a 4 years old integration in that case since that shipped barely a year ago

#

So what is your question? Just how to display the calculation?

hardy sandal
#

We just added the tax integration this summer...

solemn epoch
#

gotcha so you have a multi-years old integration, but you do add new features regularly

#

that's the part I was missing, I thought you wrote this in like 2018 and now were looking at potential improvements

hardy sandal
#

After I use elements to collect the customer's information, I would like to display this:
ORDER SUMMARY:
Subscription: 9.99
Discount: 50% off first charge
Pretax Total: 4.99
Tax: $0.24
Total Now: $5.23

<btn>Confirm Purchase<btn>

This is a page I would host and code. But how do I get the discount and tax totals via our server (assuming our server now knows the customer and the product the customer intends to purchase).

solemn epoch
#

so this is all still before Subscription creation?

hardy sandal
#

Yes. I'm assuming the customer wants to know what they are being charged before they create a subscription...

#

Even if the tax were "estimated," that'd be fine...

solemn epoch
#

But it's all due to the fact that you are approaching this "the opposite way" from what we recommend.
The newer, correct path is
1/ Create a Subscription with all the information
2/ Client-side confirm the payment with PaymentElement

There's no more "collect card details upfront" because that doesn't work in many non card-payments flow

hardy sandal
#

Maybe this would work?

solemn epoch
#

That's quite a different approach, not what I'd ever use unless you do B2B and want to use real "quotes" as a concept

hardy sandal
#

Why do you encourage making a subscription before the user intends to pay for it?

#

In our integration that will result in a lot of incomplete subscriptions

solemn epoch
#

because that's the only way to accept many of the local payment methods that require an action like going to the iDEAL website/app to approve the payment

#

it;s been the canonical integration path for well over a year now. And it makes handling 3DS a lot easier too which is more and more common worldwide now

hardy sandal
#

So how do I start a subscription but NOT have it try to charge the customer out the gate?

solemn epoch
#

you pass payment_behavior: 'default_incomplete'

#

or really move to Checkout and let us do all of this for you 🙂

hardy sandal
#

Gotcha. I think this makes more sense.

#

So you create the subscription and then you're managing the invoice from that point on?

orchid turret
#

Hi, stepping in as koopajah needs to step away. Catching up now

#

Can you clarify what you mean with 'then you're managing the invoice from that point on' in this context?

hardy sandal
#

Meaning the subscription is incomplete and it holds a reference to an invoice that needs to be paid for the customer to be moved forward in our system.

#

Or maybe it's payment intent? How do I not let the customer exit the flow before the subscription is paid? Do I need longpolling/sockets to my client to be checking that the payment has happened, or—once the subscription (incomplete as it is) and the customer's payment info have been created—is there an API event that I can hit that's like "PAY NOW" and then it doesn't resolve until the user's payment on the network resolves?

orchid turret
hardy sandal
#

Thank you