#idy_best-practices

1 messages ยท Page 1 of 1 (latest)

quartz frostBOT
#

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

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

sand shore
#

Hi ๐Ÿ‘‹

We do not currently support card_present as a payment method for Invoices. However, there is a work-around.

#

You can use a Terminal to save a payment method as we document here, and then use that saved payment method to pay Invoices for that Customer.

random token
#

I think I saw that referenced in that older thread. Is the issue of physical test cards not working for testing because they show as expired still an issue?

quartz frostBOT
worthy tundra
#

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

#

When you configure Terminal to save a card for later use there are actually two Payment Methods created. One of them has type card_present and represents the physical card used for the initial transaction. The other one, the generated_card, has type card and represents the non-physical version of the card you can use later when the cardholder and card are not physically present.

#

The documentation linked to above explains how to do this in detail.

#

To put it another way, you can't use a card_present Payment Method the way you're trying to because the card isn't present.

random token
#

But if I want a Stripe Invoice to represent the initial transaction... ?

#

If I go the route of creating a SetupIntent, what is the user experience for the in person payment? Specifically if I am using the LocalMobileReader (Tap to Pay) with Stripe Terminal?

worthy tundra
#

I think another option would be to create the Invoice first and then use Terminal to pay for the Payment Intent it generates, but I've never done that before and I'm not certain it would work.

random token
#

You can't because the Invoice's PaymentIntent.payment_method_types don't include "card_present"

#

Right ๐Ÿ™‚

#

You can't adjust it afterwards with a update either - tried that.

worthy tundra
#

So yeah, you'd have to do the other approach with a completely separate Invoice and mark it as paid out of band.

random token
#

If I create the Invoice and mark it paid out of band, then if I need to refund the invoice, I have to somehow track down the actual paid PaymentIntent?

worthy tundra
random token
#

Do you know what the user experience is like if we use SetupIntent for a Tap to Pay reader?

worthy tundra
#

I'm not sure how to answer that question. What part? The easiest way to see how it works is to try it in test mode.

random token
#

Sure - it just sounds like the presentation on the reader is different than collecting a payment.

#

We can build it first, I was just hoping there was a little more information to use to decide to build it first versus try it and see.

worthy tundra
#

What are your concerns about it?

random token
#

Well, today, the user experience is about what you would expect. You have reached checkout and when we go to collect payment, the SDK takes over and shows an amount to collect and instructions on how to place your card. There doesn't seem to be an amount passed to collectSetupIntentPaymentMethod, so I am not sure what the user experience is.