#Vilius_Siuksteris-elements-integration

1 messages · Page 1 of 1 (latest)

light spruce
#

Hello 👋
Server is a little busy at the moment, give me a few to catch up and I'll respond as soon as I can 🙂 Thanks

cedar creek
#

thanks

radiant zenith
#

Hello, you are correct that an open invoice's price cannot be changed. You will likely want to wait to finalize the invoice until you know the user's country for sure though that might be tricky with a subscription's first invoice

#

Actually, out of curiosity, do you already have up to step 6 implemented here? I am interested in how you are creating the subscription there if you are doing that already

cedar creek
#

No, this is only a planning stage, we got stuck at this specific stage and are looking for a solution.

radiant zenith
#

Okay gotcha, because as far as I am aware that flow works differently from how subscriptions/tax are typically handled in our API.

#

So basically the end goal is to allow a user to specify their country after you've guessed it and you'd like to display the price to them before they actually buy?

cedar creek
#

Yes, that's right

#

And I also have a related question. If we are using single step checkout, how the price should be updated if customer enters promo code?

radiant zenith
#

Checkout would automatically update the price itself when the user enters a promo code, it would also change the tax based on their location when they change it

cedar creek
#

But how do we implement this using Stripe payment element?

radiant zenith
#

Unfortunately the Tax part of this would be pretty difficult to do with the Payment Element + Subscriptions. The Payment Element requires a payment intent to be rendered, but that would require having a finalized invoice which wouldn't be able to be updated if the user enters a code or updates their address.

cedar creek
#

Okay, thanks. That's what we thought.

#

In addition to customers address, I assume we need to get coupon code just as well (as coupon code requires price recalculation)

radiant zenith
#

Exactly

#

You could do this with the payment element by using that preview API call and then creating/updating a payment intent based on the amount that that calculates and using that separate payment intent in the element. The catch being that you would need to do a bit of extra work to have that payment counted as the first one for the subscription you create. Usually one would either create your subscription with a 1 cycle trial, or create a subscription schedule where the subscription is at a $0 price for its first trial

cedar creek
#

I need a bit more details on this one. We would need to create separate payment intent to do all calculations and recalculations and once we want to make a payment we would need to create a final payment intent which would be paid?

radiant zenith
#

Yeah, for that one it would basically look like:

  1. Preview the invoice based on your IP location guess
  2. Create payment intent pi_123 for that amount
  3. Allow user to change details on page
    3.1 For each change preview the invoice that would cause and update payment intent accordingly
  4. When user is satisfied, they fill in their details and make their first payment
  5. Create actual subscription with first cycle being a $0 price
#

Alternatively, you could just have a page where the user enters their details, you preview the invoice and just show the price, and when they confirm their details are correct, you actually create the subscription and direct them to pay the subscription's first invoice.

cedar creek
#

But how do we handle this step if we cannot update invoice?

3.1 For each change preview the invoice that would cause and update payment intent accordingly

radiant zenith
cedar creek
#

I see now, that makes sense, thank you!

#

One more question. Would we be able to get an invoice for the payment intent which is separated from subscription?

#

This is for display on invoice history

radiant zenith
#

I don't think so but am thinking on if there is a good way to do that

cedar creek
#

Also, what about payment options, how payment element decides which payment options to display for customer? Is it based on IP/location?

radiant zenith
#

Based on a few different factors. First we take all of the payment methods that you have enabled in your dashboard, then it is filtered by which payment method types support the payment's currency and things and if they support subscription's etc if that is relevant

#

Not sure how location based ones work if there are any but I can look

cedar creek
#

If we want to accept payments via WeChat Pay, then we need to have different currency? At the moment we have only USD

radiant zenith