#jeffreyb_best-practices

1 messages ยท Page 1 of 1 (latest)

sage ravineBOT
#

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

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

covert elk
#

This is what it is showing when we try to use a setup intent

#

Woops, sorry the message got cutoff:

My questions are:
Is it possible to override or inject a custom amount into the Apple/Google Pay sheet when using a SetupIntent?
If not, is there a recommended approach for displaying a non-zero amount during the setup flow while still storing a payment method for later use?
Are there any concerns or limitations with our current workaround using a PaymentIntent instead?

main charm
#

sorry, that's not possible with a SetupIntent. Also, I would actually just use the deferred Intent flow with mode="payment". Can you share more on why you are using a SetupIntent first?

covert elk
#

We only decided to test a setup intent first because that's what we did when we first integrated credit cards.

Our current implementation works as follows: the client generates a confirmation token and sends it to our server. The server then creates a paymentIntent using that token, which in turn returns a paymentMethod. We store the paymentMethod ID in our database. Both the confirmation token creation and the Payment Intent include the setupFutureUsage: "off_session" flag.

#

We just wanted to confirm that this solution is okay to use

main charm
#

no, to be clear, it's not recommended to do a SetupIntent, and a PaymentIntent immediately after :

  • The flow that you described results in additional API call that are unnecessary due to the SetupIntent. This contributes to your rate limits. As your business grows bigger, this isn't really sustainable.
  • Depending if your business chooses to shift to interchange pricing, you are essentially also incurring additional unnecessary costs due to the SetupIntent.
  • And like what I mentioned earlier, there is no way to display a non-zero amount for a SetupIntent.

What are interchange fees? For businesses that accept card payments from customers, these fees are a key part of doing business.

#

you should just do a PaymentIntent with setup_future_usage: off_session

covert elk
#

Sorry for the confusion, but we are not using a setup intent anymore for our digital wallet integration.

We are just using a payment intent but we create a confirmation token first to obtain the card details

#

Our original solution was to use a setupIntent. But since we experience the GPay sheet showing $0, we pivoted to use a confirmation token/payment intent.

main charm
#

ah i see, that's our recommended flow, so it's perfectly fine to use that flow

covert elk
#

Awesone, thank you Alex ๐Ÿ™‚

drowsy nova
#

Iโ€™ve added Apple Pay to my Stripe account and also uploaded the Stripe verification certificate to my Apple Developer account.

Now, I need to verify the domain by hosting the .well-known/apple-developer-merchantid-domain-association file.

Can you please guide me on how to download this file from Stripe so I can upload it to my domain and complete the verification process correctly?

main charm