#shwallie

1 messages ยท Page 1 of 1 (latest)

tardy rivetBOT
glass tendon
#

Hello! For tax calculations you typically only need billing details, not shipping details, but this becomes more difficult if you're trying to use the Payment Element instead of Checkout or the hosted Invoice payment page.

full mountain
#

Okay - yah, I'm initializing my customer with their IP address initially. But that's the only geo information we have for them when they're presented with the payment element. I was hoping that the country/postal code they supply with their payment details could be used to calculate their tax more accurately.

glass tendon
#

Then create the Subscription with that Payment Method and the billing details that were collected.

full mountain
glass tendon
#

No.

#

You would use the Payment Element without an Intent to create a Payment Method will billing details, then you create the Subscription after that.

full mountain
#

So

  1. Create the Payment Element with either $0 (for free trial) or $X.XX for non-Free trial
  2. Create the Subscription with that payment method as the 'default_payment_method', the optional 'trial' information, 'payment_behavior': 'error_if_incomplete', and the price_id
  3. Listen for webhooks for when the subscription is 'active' and provision our service for the customer?

Then... Done? Sorry - I'm having a trouble understanding how to get from point 1 to point 2. Do I still need the PaymentIntent?

glass tendon
#

Creating a Subscription will create an Invoice for the first subscription period, and that Invoice will create a Payment Intent to collect the funds to pay that Invoice.

#

So you would not be creating or dealing with the Payment Intent directly.

tardy rivetBOT
full mountain
#

Okay:

  1. Create payement element with either $0 (for free trial) or $X.XX for non-Free trial
  2. Inspect payment method to grab country/zip code for customer tax
  3. Create the Subscription with that payment method as the 'default_payment_method', the optional 'trial' information, 'payment_behavior': 'error_if_incomplete', automatic_tax: { 'enabled': true}, and the price_id
  4. Return the subscription's payment intent client secret to the client
  5. Client uses the clientSecret to 'confirmPayment'
  6. Listen for the 'invoice.paid' webhook to provision client with our service (or should we listen to a 'customer.subcription.(created|updated)' event?
tidal salmon
#

๐Ÿ‘‹ hopping in here since rubeus has to head out soon

#

For step #3
Is there a reason you're using 'payment_behavior': 'error_if_incomplete', ? If your plan is to return the client secret back to your frontend and call confirmPayment client-side then you should do payment_behavior: default_incomplete

full mountain
#

Oh - sure. No reason - I guess I just wanted to make sure the subscription didn't start unless their payment was completed successfully. It feels like we're fighting to force a payment method to be validated before provisioning the free trial.

#

Am I still listening to the same webhooks after Step #5 to provision services for the client? I feel like the free trial vs the non-free trial have the potential to trigger different hooks.

tidal salmon
#

Yeah so for subscriptions that aren't paid successfully we'll transition them to incomplete after 23 hours of not being paid - so you aren't just left with an unpaid subscription forever

#

And for the webhooks - I believe they should both be triggering invoice.paid events if that's what you want to rely on (it sounds like that's what you want given you don't want to provision until you're sure they've paid)

full mountain
#

Okay thank you. I'll prototype something. Can I reply to this thread in the future if I need more support?

tidal salmon
#

We tend to close threads if they've been inactive more than an hour, but you can always just re-ask in the main channel and we'll be able to help ๐Ÿ™‚

full mountain
#

Okay - cool, thanks for the help. I hope this works
๐Ÿคž