#ziwengames_best-practices

1 messages · Page 1 of 1 (latest)

rugged cobaltBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1222195610053116066

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

violet duneBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

pseudo cape
#

Hi 👋 the part of your question about whether you need to worry about the customer's address changing, is likely something you'll want to discuss with your tax advisor and it sounds like that could be tax advice which I'm not able to provide.

I can certainly help with how to adjust your integration so that you collect address information from your customers. How are you integrated currently or planning to integrate?

olive bolt
#

Hi, I have a cat named Toby!

#

Anyway, users must subscribe before accessing the website. They may additionally buy a physical product.

What I've done so far is collect the user's billing information through Stripe Elements and create a payment method off that on the front end. I then pass the address information to the backend, and set the customer object's address based on that.

THEN I create and finalize the invoice, whose tax is based on the address I just set (which was based on the credit card billing information).

#

After payment for the subscription, they can buy additional one-off things on the website. I was thinking of doing the same thing as above except I have 2 decisions on if they use a different credit card:

  1. Change the customer's address to the new address of the cc
  2. Leave it as is from the card used to pay the subscription

The customer also has the option to change which card they are using to pay the recurring subscription invoices.
3. I could do 2 from above and then only change the address based on this card

#

I don't think I neccessarily need help with integration, but could use some of your thoughts! I think 3 would probably be the most practical, as the subscription is the main product and that's what I think I could associate the customer's address with.

pseudo cape
#

I would recommend speaking to your tax advisor about this, especially if you're talking about shipping physical products in which case my thinking (not my advice as I am not a tax advisor and cannot provide that) is that you'd need to use the customer's shipping address rather than their billing address.

olive bolt
#

Ok sounds good! Thank you

pseudo cape
#

Any time!

#

Sorry I couldn't be of more help this time.

olive bolt
#

This is a little tricky but I was wondering theoretically what if the user has two different subscriptions, with two different billing addresses? How would you manage setting the customer object's address? Is there a straight forward way to do this or would we have to look for a work around?

I'm aware to pay for a subscription, it must be created first (which means the address must already be known) (and recurring payments will depend on the customer object's address)

pseudo cape
#

Based on the list here of where we pull addresses from, and in what order:
https://docs.stripe.com/tax/customer-locations#address-hierarchy

It sounds like you want to avoid setting the billing address on the customer object there, and instead maintain the billing address for each payment method on the Payment Method objects instead.

olive bolt
#

I understand, but in order to create the subscription (with the correct tax), I would need to have any one address associated with the user. So I would totally maintain the billing address for each payment method, but before I can even pay for the subscription, the subscription needs to be created first (but it can't because it's missing address information for automatic tax).

Here's an example of a request I tried to make without a customer address:
req_le5l4mH7ek8QJi

pseudo cape
#

If you pass a Payment Method, with a billing address defined, to that request in the default_payment_method field, does that avoid the error?

olive bolt
#

I believe it wouldn't but I was hesitant to do this because my checkout flow is sort of like this so far (can do modifications if needed)

Step 1: Raw cost of subscription without tax
User Input: User enters cc info via Stripe Elements
Server: customer is set to cc address
Step 2: Subscription is created BUT (important) set to payment_behavior=default_incomplete and tax amount can be seen (User Input is just to confirm the amount with the cc supplied)

  • (payment_behavior setting) This is because the user hasn't actually paid yet, so I don't want the subscription to actually start until they pay.
  • The reason I don't want to pass in the Payment Method I just acquired to the subscription.create() API is because they still haven't seen the amount of tax yet. (If I didn't have payment_behavior=default_incomplete and did this, I'd be worried that stripe would automatically charge their card before they even hit next after seeing the tax).
pseudo cape
#

default_incomplete should prevent the payment from happening

olive bolt
#

Wait sorry, to clarify, if I attached the payment method to subscription.create() AND had payment_behavior=default_incomplete, would Stripe not automatically try and charge the card after an hour (and be successful)? Or is it explicitly waiting for me to confirm the payment intent?

pseudo cape
#

It's waiting for you to perform a confirmation

Use default_incomplete to create Subscriptions with status=incomplete when the first invoice requires payment, otherwise start as active. Subscriptions transition to status=active when successfully confirming the PaymentIntent on the first invoice.

olive bolt
#

Ok, I'm trying this out right now with stripe clocks to check

#

I just realized I tried this the other day with resulted in an error: On the frontend with stripe elements, when I create the Payment Method, I haven't associated that with the customer yet. This is because from this document:
https://docs.stripe.com/api/payment_methods/attach
it seems like it's not recommended to attach a payment method like this to the customer. As a result, I wouldn't be able to attach the PM when the subscription is created, because there is no payment method associated with the customer.

Attach a PaymentMethod to a Customer | Stripe API Reference

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

pseudo cape
#

Huh? You're right that you shouldn't be attaching Payment Methods, you should let the intent handle that for you. How is your flow currently structured?

rugged cobaltBOT
olive bolt
#

On the front end, I have stripe elements. On submit, I end up creating a payment method like this:

if (!stripe || !elements) return

...

// Create the PaymentMethod using the details collected by the Payment Element
  const { error, paymentMethod } = await stripe.createPaymentMethod({
    elements
  })

const address = await elements.getElement('address')?.getValue()

...

await axios.post('/api/payments/create_customer', {
  ...address?.value.address
})
olive bolt
#

TLDR
Step 1: user enters cc info with basic price info
Step 2: user confirms payment after seeing tax info

#

The payment intent that I confirm is attached to the subscription object (but this is after I create the subscription)

#

So at this point (step 1), the intent doesn't exist yet

pseudo cape
#

How are you collecting payment method details if you don't have an intent yet. Are you using our deferred intents flow to initialize Elements without an intent?

olive bolt
#

Yea, I am

pseudo cape
#

Thinking

olive bolt
#

In this case, would it make more sense to use a setup intent instead at step 1?

#

To resolve the problem where the PM isn't attached to the customer (which is needed to preset the PM on createSubscription(...) to see the tax without setting customer object's address)

pseudo cape
#

My biggest hesitation with that, is that can lead to (though not common) scenarios where customers have to complete authentication twice. Once for the Setup Intent then again for the first payment of the Subscription.

olive bolt
#

agreed, I thought about that too

pseudo cape
#

Taking a step back, the Customer doesn't exist here yet, right? Like this is for their first Subscription, before the possibility they might have multiple addresses that you need to worry about?

olive bolt
#

On step 1 before they submit anything, correct

pseudo cape
#

Hm, I'm wondering if it makes sense to try to store the address information at the Customer object level until you know you need to maintain multiple addresses for them.

olive bolt
#

That's what I've been doing so far. The reason why I ask the question in the first place is because what if on the website, they decide to buy another non-physical product with a different cc with a different address?

I can update the customer object address to the new address so that the one-off item is charged tax for the new address. But then the subscription will also be charged the new address (based on the tax address rules), when I want it to be charged with the address of the first credit card.

pseudo cape
#

What's the structure of the flow for the one-off payment? Could you remove the address from the Customer object (I'm not entirely sure we'll let you do that without throwing an error) at that point and start setting the address on the Payment Methods instead?

olive bolt
#

The structure of the one-off payment is currently wrong, because I'm using a static tax rate instead of automatic_tax. But when I change it, I'd imagine it to be the same kind of flow:
Step 1: choose payment method (frontend will create it if it's new, or user can select an existing method)
Step 2: invoice created, tax will be shown based on the payment method selected, then on user confirm, invoice will be paid

"Could you remove the address from the Customer object..." I could, but then on step 2 if the address is removed, couldn't it potentially show the wrong tax, because it's based on a different card's address (or potentially not let me create the invoice or have tax as 0 because there's no associated address)

pseudo cape
#

I'm honestly not sure, we're pretty deep into edge case territory it feels. It's very possible this is a scenario that we don't let you handle well today. The ideas I've been sharing are the only ones coming to me to possibly build what you're describing. If that's still not leading to the desired behavior, then a drastically different approach like maintaining multiple Customers per customer may be needed.

olive bolt
#

That's ok, I appreciate the help. Honestly I might just consider one of these two solutions

  1. Use setup intent on step 1 (may risk user having to authenticate twice) - although you're talking about SCA right, only if the card is on always authenticate?
  2. I'm just gonna keep the tax amount from the first address they put (not sure how this will fare with regulations)
pseudo cape
#

Yup, SCA is what I was referring to for the first one. My understanding is that most issuers wouldn't prompt for authentication twice there, but it could happen.

olive bolt
#

Makes sense, I think for non edge cases though, this would solve the whole issue it seems,

#

PM is now attached to customer -> can apply to create invoice default payment method-> can now see tax info

olive bolt
#

Hi, if you're still here, do you know if the shipping address is attached to the payment method? I currently can't find it but wanted to ask. For physical items, I'm trying to see if I can get the tax to be based on the payment's shipping address

silent delta
#

Hi 👋

My colleague had to step away.

#

We generally attach Shipping Addresses to the Customer object and Billing Addresses to the Payment Method object

rugged cobaltBOT
olive bolt
#

Ok I see. If the the shipping address of the customer is present, but the customer is buying a non physical item, I believe stripe will still charge tax based on the shipping address right?

winter mesa
#

Hello! I'm taking over and catching up...

olive bolt
#

Hello no worries

winter mesa
#

Yep, that's correct! That's how we determine the address to use.

olive bolt
#

Does this mean that shipping addresses take precedent over billing -- as in the developers decide what state to tax the customer: if shipping is provided, automatic tax will always use that otherwise use billing

winter mesa
#

Yes.

olive bolt
#

If I don't have AVS, couldn't the user put an arbitrary billing address to get the lowest amount of tax

winter mesa
#

Not sure I understand? Can you provide more details?

olive bolt
#

Np,

So I'm aware that automatic tax is based on addresses supplied by the user. Suppose customers know the lowest taxed region. Couldn't they simply supply this location in the billing address when making a purchase, assuming I don't have AVS enabled?

winter mesa
#

I suppose they could, but why would you have AVS disabled?

olive bolt
#

I think I need Radar to have it enabled

#

Unless I'm misunderstanding

winter mesa
#

Yeah, there's a built-in Radar rule for it that all Stripe accounts have that you can turn on or off.

olive bolt
#

If I don't have Radar, then I don't have AVS, right?

winter mesa
#

Everyone has these Radar rules. What do you mean?

olive bolt
#

Apologies if I'm misunderstanding, but I think my company doesn't have this enabled?

Screenshot_2024-03-26_at_1.34.21_PM.png
winter mesa
#

That control is used to enable or disable Radar on Setup Intents, which isn't relevant to what you're asking about (Setup Intents have no amount, and thus no tax).

#

There should be a Block if Postcode verification fails rule listed there.

olive bolt
#

oh I see I'll take a look at that

#

Thank you

olive bolt
winter mesa
#

Yeah, if you're using Stripe Tax and a shipping address is set on the Customer that's what we'll use.

olive bolt
#

I don't know if you saw my thread with Toby, but do you know if it's possible to have the tax be calculated by the shipping address entered by the customer on Stripe Elements instead of the Billing address? I currently don't see a shipping address field on the payment method object (without setting the customer objects shipping address)

winter mesa
#

To clarify, do you mean the shipping address entered into the Address Element in shipping mode?

olive bolt
#

Yea