#22maryjane_api

1 messages ยท Page 1 of 1 (latest)

valid shadowBOT
#

๐Ÿ‘‹ 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/1463997226496823502

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

placid charm
valid shadowBOT
prisma canyon
#

Hi there, looking into this now

#

Just to verify, are you saying that when a user signs into link, the change event doesn't show "type": "link" in the "value" field? I did a brief test on my integration where I see a value of "link" there

placid charm
#

If the user was signed into Link previously. Then goes through our checkout the Payment Element detects Link and shows the above component and the type: card rather than "link"

#

In my example I used a brand new user to our site so they have saved their email but don't have any payment methods saved with us. I am passing the user's email to the PaymentElement options under:
defaultValues: { billingDetails: { email: <email> } }

prisma canyon
#

Got it, let me try and recreate

placid charm
#

This new user's email I am passing does not match the email Link has saved with the browser cookie

prisma canyon
#

Got it, thanks for the context

#

Actually, can you provide the full code you used to create the Payment Element? Want to make sure I'm reproducing correctly here

placid charm
#

<PaymentElement
onChange={(event) => handleChangePaymentElement(event)}
options={{
layout: {
type: 'tabs',
defaultCollapsed: false,
},
defaultValues: {
billingDetails: {
email: user?.email,
},
},
fields: {
billingDetails: {
address: {
country: 'never',
postalCode: 'auto',
},
},
},
}}
/>

#

If a user has a saved payment method from a previous purchase with us and saved with Link, most of the time the PaymentElement will look like this and then the "type" will be "link" instead of "card".

prisma canyon
#

Sorry for the delay, just letting you know that I'm still looking into this

#

In my own integration, when I create a Payment Element on a browser page that is already logged into Link, I'm seeing three change events. The first one has value.type: card, the second and third have value.type: link. Which means you would be able to detect this situation. But if that's not what you're seeing, then I may be missing something in my reproduction. If that's the case, can you provide details on what you're using to create the Payment Element (payment intent, setup intent, checkout session, customer session, etc.)

placid charm
#

When I refresh the page I see one or two change events with value.type: card. We are using the payment intent and customer session when we set up the Payment Element. We have the Stripe Element wrapping both the Address Element and Payment Element. We use the customer session client secret to detect any saved payment methods on our customers.

valid shadowBOT
faint vigil
#

๐Ÿ‘‹ Hi there - I'll be taking over for nobs, who has to step away

#

do you have a checkout page, even if on a staging site, where I can inspect your form? Additionally, what is your Stripe account id?

placid charm
#

Is sharing our Stripe account ID here secure or does it not matter?

faint vigil
#

Stripe account ids are not sensitive; people share them on this channel all the time

#

You just don't want to share your API keys ever

placid charm
#

OK thanks. Stripe ID is acct_1DpqseGjO3bEFd6g

faint vigil
#

Okay, so this is a bit messy, but there are two "modes" Link can operate in. In the first, it behaves as a card wallet similar to Apple Pay and Google Pay, and in this case, the Payment Method's type is "card" and the value of card.wallet on the Payment Method is "link"

#

This is what is happening on your Payment Element currently

#

The second mode has a type of "link" and the funding source (card, bank account, etc) is obscured from your integration

placid charm
#

OK, the second one is what I'm used to dealing with when a user saves their payment method via Link (see second screenshot I posted above).

faint vigil
placid charm
#

This is for default

faint vigil
#

is that for the same sandbox as alt-checkout.develop.getsunday.dev/?

placid charm
#

Yes same for test mode

faint vigil
#

๐Ÿ‘

#

could you give me the pmc_123 token?

placid charm
#

I haven't worked with these configs since we first set them up. Do I need to add the alt-checkout.develop.getsunday.dev domain to the "Payment method domains" list? Since www.develop.getsunday.dev in already in there I think it's ok.

#

PMC for test mode is pmc_1KTav0GjO3bEFd6g6Ruvo8wx

faint vigil
#

Yes, you should add alt-checkout.develop.getsunday.dev to your payment method domains but I don't think that is the reason why

#

Just to be clear - is your desired state is that Link payments in the payment element should always generate a Payment Method of type: 'card'?

placid charm
#

Reading through the doc you linked I believe we want type: card bc we need the last 4 digits for future off session payment charges. Let me confirm with another engineer.

#

We actually use the Stripe ID pm_1S3.... for future charges of their saved payment method.

faint vigil
#

Well that would be the case regardless

#

You can't create a payment with just the last4

#

If you want all the link/card payment methods to be pm_123 with type: 'card', then you don't need to do anything and just understand that you won't get a difference between Card and Link in the Payment Method's type property

placid charm
#

Maybe I have it backwards. If you integrate Link as a payment method, then each Link transaction has a PaymentMethod object with a type of link and no wallet hash. That is what I have seen for user's saved payment methods

faint vigil
#

It probably depends on how the card was collected. If you can give me specific pm_123 I can look at it. From what I see internally, you should be getting link type PMs on the Express Checkout Element and card type pms (from link) on Payment Element, Checkout, Card, and Payment Request Button, if you use it

placid charm
#

We use the Payment Element. Here is one that is type of link pm_1SsUkTGjO3bEFd6gfIoaUThi

faint vigil
#

object: {
id: "pm_1SsUkTGjO3bEFd6gfIoaUThi",
object: "payment_method",
allow_redisplay: "unspecified",
billing_details: {
address: {
city: "",
country: "US",
line1: "
",
line2: null,
postal_code: "
",
state: "
",
},
email: "
",
name: ",
phone: null,
tax_id: null,
},
card: {
brand: "visa",
checks: {
address_line1_check: "pass",
address_postal_code_check: "pass",
cvc_check: "pass",
},
country: "US",
description: null,
display_brand: "visa",
exp_month: **,
exp_year: 2030,
fingerprint: "
",
funding: "credit",
generated_from: null,
iin: "
",
issuer: "THE CHASE MANHATTAN BANK",
last4: "
***",
networks: {
available: [
"visa",
],
preferred: null,
},
regulated_status: "unregulated",
three_d_secure_usage: {
supported: true,
},
wallet: {
dynamic_last4: null,
link: {},
type: "link",
},
},
created:
1769114701
,
customer: "cus_TqAxYMKHRbn3rk",
customer_account: null,
livemode: false,
metadata: {},
type: "card",
},

#

type is card. card.wallet.type is "link"

placid charm
#

So in the Payment Element's change event I see type: card for this one so I'll have to check elsewhere for other buttons I want to render.

#

Thanks for your help digging into this. I'll do some more experimenting.