#alex_api

1 messages · Page 1 of 1 (latest)

lucid driftBOT
#

👋 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/1342260298060664885

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

shy lichen
#

Hello! The error is correct, Payment Methods of type card_present can't be saved for future use. However, if you've followed the correct steps to set up the card for future use, there should be a generated_card Payment Method of type card that you can save for future use. See here for details: https://docs.stripe.com/terminal/features/saving-cards/overview

verbal pagoda
#

Hi Rubeus, ok let me take a look at the link you provided

#

ok so I have looked at that documentation

#

If the customer isn’t in your checkout flow when you charge the customer, set off_session to true. This causes the PaymentIntent to throw an error if customer authentication is required.

#

does this apply to setup intent as well?

#

I thought creation of setup intent defaults off_session to true

shy lichen
#

Let's back up a bit. Can you tell me more about what you're trying to build? For example, are you taking a payment at the same time you're setting up the card for later use, or are you only saving the payment info without taking an immediate payment?

verbal pagoda
shy lichen
#

Okay, so yeah, that's the guide you want to follow. Give that a try and let me know if you run into any issues.

verbal pagoda
#

I believe that is the guide I have been following

shy lichen
#

Ah, okay, which variant are you using? Server driven or another one?

verbal pagoda
#

A few things to call out, one is that we cannot use the server driven approach because we are not using an S700 or a WisePad, so we are using the react-native steps.

shy lichen
#

Okay, which step are you having trouble with?

verbal pagoda
#

And the other is that we are trying to recognize our users on repeat visits, which means we are attempting to link the payment method to a customer only after we have attached the payment method to the setup intent.

#

in other words, we are looking at that payment method fingerprint to determine if this is a repeat user or not

shy lichen
#

To clarify, you're trying to identify them based on the card they're using?

#

Gotcha.

verbal pagoda
#

yes

shy lichen
#

Okay, so what's blocking you from moving forward?

verbal pagoda
#

"If you didn’t provide a customer during SetupIntent creation, you can attach the generated_card to a Customer object in a separate call."

#

this is the step that is failing for us at the moment

#

So maybe what I'm failing to understand is how we get that generated card value, because right now it sounds like I'm trying to attach the payment method itself

shy lichen
#

Where req_zd0bw21pRlwnFM is an example of that failing?

verbal pagoda
#

yes

#

this is the snippet where I get the payment method, but this returns a payment method, not a generated card:

const paymentMethod = await this.stripeService.getPaymentMethod(setupIntent.payment_method.toString());```
shy lichen
verbal pagoda
#

ok so using this snippet from the docs:

(
  '{{SETUP_INTENT_ID}}'
,
  {
    expand
: ['latest_attempt'],
  }
);```
shy lichen
#

Yep.

verbal pagoda
#

then something like:
setupIntent.payment_method_details.card_present.generated_card

shy lichen
#

Nope.

#

It would be something like setupIntent.latest_attempt.payment_method_details.card_present.generated_card

verbal pagoda
#

copy that

#

and generated_card will be an ID that I can attach directly to the customer?

shy lichen
#

Yeah, it'll be a Payment Method ID. That Payment Method will be of type card, not card_present.

verbal pagoda
#

copy that

shy lichen
#

It will work like any other Payment Method.

verbal pagoda
#

ok thanks for clarifying that Rubeus, I should be able to take it from here

shy lichen
#

One of the key things to understand about Terminal is that, when saving cards for future use, Terminal creates two different Payment Methods. There's a card_present Payment Method which represents the physical card used at the physical Terminal reader, and then there's the card Payment Method (the generated card) which is the one you use for card-not-present transactions later.

verbal pagoda
#

well, one more question, will both the generated_card and the paymentMethod of type card_present have the same fingerprint?

#

ok, thanks for spelling that out that helps me understand those objects and their use cases

shy lichen
verbal pagoda
#

ok cool I'll take a look at that. thanks for your help!

shy lichen
#

No problem! Once you get it working in test mode it should be a lot more clear. 🙂

verbal pagoda
#

ha, yeah, about that

shy lichen
#

It's certainly not intuitive until you see it in action and conceptualize card_present vs. card.

verbal pagoda
#

we do most of our terminal development in live mode because we only generate a sort of dummy payment method when we don't use live mode keys. are we missing something or is that what everyone does?

shy lichen
verbal pagoda
#

yeah, so we do have test cards

#

However with tap to pay on Android, they don't work

#

sorry I know that's not very helpful. We have tried to use our test cards with Tap to Pay on Android but have not been able to get a successful read using them. Our mobile dev has this workaround where a button shows up to "simulate a card tap", which I believe is a stripe thing, but I could be wrong.

#

but yeah if using test cards is supposed to work, I will get him in this discord to talk to someone on Terminal team to sort that out, because it's making us somewhat crazy.

shy lichen
#

As far as I know the physical test card is expected to work with Android tap to pay in test mode, but let me double check...

#

Could it be that in test mode you're configured to use a simulated reader instead of the actual hardware?

verbal pagoda
#

that is entirely possible, I'm not hands on with the mobile codebase. If you can confirm that about tap to pay in test mode that would be great and I'll get him in here to sort it out with someone on your team.

shy lichen
#

Yeah, it should work. I can't find anything explicitly stating it works because... of course it works, you know? If it didn't work there would be explicit documentation that it didn't.

This is the best evidence I could find, an issue where physical test cards with tap to pay on Android had a bug that was then fixed, all back in 2023: https://github.com/stripe/stripe-terminal-android/issues/397

verbal pagoda
#

ok perfect, thanks I'll take this back to the team

shy lichen
#

There's an explicit statement from someone at Stripe saying it's supported.

verbal pagoda
#

haha ok, well we will revisit our assumption then and see what we get, thanks so much very helpful as always

shy lichen
#

So could be you're using an older version with a bug that's since been fixed, or you're inadvertently using the simulated reader instead of the actual reader... those are my two leading theories.