#jeffreyb_best-practices
1 messages ยท Page 1 of 1 (latest)
๐ 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.
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?
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?
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
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.
you should just do a PaymentIntent with setup_future_usage: off_session
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.
ah i see, that's our recommended flow, so it's perfectly fine to use that flow
Awesone, thank you Alex ๐
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?
sorry, but which guide are you following? Can you point me to it? If you're using the Express Checkout Element, you only need to register your domain. The instructions for how you register your domain are covered here : https://docs.stripe.com/payments/payment-methods/pmd-registration