#markus-link-billingdetails

1 messages · Page 1 of 1 (latest)

restive quartzBOT
prime topaz
#

Hi 👋 I will need to look into that, can you help me understand which of our Elements are being leveraged by the checkout flow that you've built?

severe lantern
#

yes, I can send you our account / checkout page over DM

#

or if you can look it up, I can you give you some payment ids or whatever here?

#

(in terms of the elements, we are using pretty much all of them, but in a custom page)

prime topaz
#

Sorry, we don't accept DMs in this forum. Can you provide the information here? Or if you would prefer a more private conversation with our teams you would need to reach out via Support.

prime topaz
severe lantern
#

correct

#

sample payment intent: pi_3MXVCvFBwtBjrU6Z0bcwrt8m

dusk locust
#

markus-link-billingdetails

severe lantern
#

actually, pi_3MXTicFBwtBjrU6Z1LDuLkTh would be a more applicable one

dusk locust
#

@severe lantern we still need a lot more specific details

severe lantern
#

since the second one comes from link, the former was not

dusk locust
#

What exact UI element(s) are you using client-side, do you have some exact code, can we look at a simple reproduction somewhere?

severe lantern
#

yea, so this is probably not the right forum for that, if it is going to be public 🙂

#

but I was hoping to understand if we should expect billing information to be provided on payment data at all when its coming from Link?

dusk locust
#

I mean we should be able to discuss your integration and part of your code in public without any issue or sensitive information being shared. But if you want private support then https://support.stripe.com/contact would be the best place to get help

severe lantern
#

correct; i'm just in the middle of a deployment that we are trying to understand the scope of whats going on, so it would be easier for me to not have to have the additional mental exercise of making sure I am properly anonymizing everything

#

if you cannot answer the general question of if billing information is generally available via link (where the customer enters their email, authenticates via SMS code, and has their saved card data used) then I will reach out to support.

dusk locust
#

I don't really understand your question unfortunately and I need you to provide more specific details about what you are doing. The way you integrate matters

severe lantern
#

pi_3MXTicFBwtBjrU6Z1LDuLkTh in the stripe dashboard has a "shipping" section, but no "billing" section

dusk locust
#

I'm sorry, this is just a PI id with no info about your integration.

severe lantern
#

are you saying that with the proper integration method, it is possible that stripe link PI will contain billing information?

dusk locust
#

I'm saying nothing yet, I'm asking what you're doing so that I can help. I can't answer the high level question without first writing code and debugging this myself and we have 10 different integration paths.

severe lantern
#

it feels to me like there should be answer to "do payment intents created with link ever pass billing information" without having to write code to try to determine the answer

dusk locust
#

As far as I know the answer is yes. So I will say yes. But then you will go back to "but then why didn't it in this case" which is totally fair, and then I need to know what your code is doing to help you debug this.

severe lantern
#

perfect, that is helpful

#

my point was that, if you could tell me its never going to happen because its not supported, that would be a useful datapoint - by virtue that you don't think that is the case, then it seems worth it to continue 🙂

dusk locust
#

gotcha, but really if you tell me what you're doing (and had done that 20 minutes ago) you'd likely have the definitive answer by now 🙂

severe lantern
#

yea, the challenge is 80% of the code for this was written by my colleague

dusk locust
#

But I finally figured out what UI you're using from that PaymentIntent id, so I'm looking

severe lantern
#

so if I knew exactly what "i" was doing, I would have told you 🙂

#

I'm working on figuring it out right now too

dusk locust
#

(also why is your code updating the PaymentIntent dozens of times before confirming it, this is really not optimal and going to cause issues later)

severe lantern
#

so, it looks like right now, when we recalculate our cart total, we are potentially updating the payment intent to include the customer's email in the metadata section

#

it does look kind of "not great"

#

since we could do that plenty of times as they mess with shipping address (Taxes), coupon codes, etc.

#

I think this is an artifact of trying to figure out where we can shove the email value into the metadata bucket, but its probably not the right thing to be doing

dusk locust
#

I mean updating is fine but you make the call over and over sending the same exact value each time (from what I can tell) I would definitely fix that

severe lantern
#

yea, so we are potentially updating the amount, as well as a string value (customer email) in the metadata bucket

#

i think i can just check if either are different before blindly updating the PI

#

and that should avoid doing that over and over for no good reason

dusk locust
#

awesome

#

Do you use the AddressElement too or just PaymentElement? Do you have an example where you got billing details for a normal card payment for example? I'm trying to figure out what the disconnect is

severe lantern
#

we are using the AddressElement as well

#

can you tell from the PI what our account website is?

#

(sorry i'm beating around the bush here, just trying to be careful whats on a public forum)

dusk locust
#

no I can't, so I need you to be crisp/detailed about what exactly you are doing so that I can help figure out what's the disconnect

severe lantern
#

pi_3MXWtvFBwtBjrU6Z2ncT87dT

dusk locust
severe lantern
#

I believe we are, correct

dusk locust
#

how are you initializing the AddressElement?

severe lantern
#

<AddressElement id='stripe-shipping-address-element' key={key} options={{ mode: 'shipping', blockPoBox: true, allowedCountries: ['US'], fields: { phone: 'always', }, validation: { phone: { required: 'always' }, }, display: { name: 'split', }, contacts: contactOptions, }} onChange={addressOnChange}/>

dusk locust
#

ah of course you use React lol

severe lantern
#

yea sorry

#

all the kool kids use it

#

what can i say

dusk locust
#

ah all good, I just struggle a lot with it myself 🙂

severe lantern
#

so, one thing that is fuzzy but I think may be a thing

dusk locust
#

and you only have one AddressElement, in shipping mode

severe lantern
#

I'm half remembering now, there was talk about how you can only wire up one AddressElement with the rest of the elements

dusk locust
#

yeah but I'd expect the Link and Card flow to work the same conceptually

severe lantern
#

so we have the CardElement too

dusk locust
#

hum

severe lantern
#

and you can uncheck same-as

dusk locust
#

CardElement or PaymentElement

severe lantern
#

and it lets you add a Country and ZIP, but it isn't adding anything else

dusk locust
#

yeah so PaymentElement instead I assume

severe lantern
#

so I'm wondering if we are getting the billing address when they are checking "same as"

#

and not when they don't?

dusk locust
#

sorry that's why I keep asking your exact integration 😅

#

okay let me test your theory about the checkbox locally, give me 5 I'll be right back

severe lantern
#

import { PaymentElement, useElements, useStripe, LinkAuthenticationElement, AddressElement, AddressElementProps, LinkAuthenticationElementProps, PaymentElementProps,} from '@stripe/react-stripe-js';

#

here is exactly what is being pulled into react-land

#

I'm looking over how they are being used now

#

<PaymentElement id='stripe-payment-element' onChange={paymentOnChange} options={{ business: paymentElementBusinessOptions }}/>

#

it does not look like the import for LinkAuthenticationElement is actually used (needs to be cleaned up) so its really just PaymentElement

dusk locust
#

yeah

#

I can't even get the AddressElement and Link to play together right now so debugging that first

#

will take some time but I'm pairing with a colleague

severe lantern
#

hmm

#

"When the Address Element is in shipping mode and used with the Link Authentication Element in the same Elements group" I read this as, "When you are using both..." not "you need to use both"

#

note right above that section: "There can only be one Address Element per Elements group. If you need to collect both shipping and billing addresses, use the Address Element in Shipping mode and use the Payment Element to collect only the necessary billing address details."

#

thats what I was half-remembering before - we couldn't mount an AddressElement in both shipping and billing mode

#

"Link in Card Element is enabled automatically" - so that is another vote for like "don't need to use LinkAuthenticationElement" explicitly when you are using the Payment Element, I think

#

based on these docs, it is starting to feel more like our integration is at least, at a high level, as expected (single address element, in shipping mode) but also expected is not getting much from the billing side when stripe decrees it not necessary?

dusk locust
#

¯_(ツ)_/¯ no idea right now sorry, I'm trying to make sense of it myself

severe lantern
#

alright, well that makes me feel slightly better

dusk locust
#

I did say a lot of curse words out loud to my colleague about it so yeah it's not just you 😅

#

but are you sure you aren't using the LinkAuthenticationElement at all in your code?

severe lantern
#

yes and no

#

so, I am confident we are not in that one file... heh

#

// When a user logs in, the PaymentIntent gets a customer and the email is the Stripe Customer's email read-onlyreturn <LinkAuthenticationElement id='stripe-link-element' onChange={linkOnChange} />;

#

but in the logged-in-user path, then, yes

#

(and yes, shame on me for inferring too much based on the original file's name vs. a global search)

swift rapids
#

👋 I'm hopping in since @dusk locust has to head out - give me a bit to catch up (and we've got some folks we're talking to internally)

severe lantern
#

take your time!

swift rapids
dusk locust
#

I mean there's absolutely no reason to do that though right?

#

Like no developer should ever pass billing_details on PI confirm, when they are explicitly using AddressElement which collects and passes the information for you automatically

#

My current understanding is that this is a limitation of AddressElement + Link for now and we won't pass billing details unfortunately and there isn't yet a way around it @severe lantern I'm sorry

severe lantern
#

gotcha, thank you both

#

after reading the docs more, I think that this is basically "Expected behavior"

#

the biggest downside is 3rd-party anti-fraud investigation - not having the billing to compare

#

(presumably Radar can get to it of course)

dusk locust
#

Correct!