#mark-reckard_best-practices
nimble timberBOT
đ 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/1392224166161420310
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
modern osprey
Hello
There's not much someone can do with a Publishable Key. At most, they can try to confirm the PaymentIntent w/ payment method details. IIRC there's a confirmation limit on a PaymentIntent as well after which the PaymentIntent is automatically canceled.
soft finch
Ok gotcha, so worst case if they already have payment method details and can confirm the payment, they're just taking a backdoor into our public functionality anyway?
soft finch
I suppose rather than using our UI, they could somehow programmatically create payments? I'm not really sure to be honest.
modern osprey
You can't create Payment Intents using the Publishable key. You can only confirm them so there's no way they can use it to "create" new payments.
soft finch
We'll look into rate limits for our endpoint, is this the best place to find information on rate limits? https://docs.stripe.com/rate-limits We have an enterprise-level platform account with lots of connected accounts we accept donations/payments on behalf of. Is there difference for rate limits for enterprise, platform, connected accounts?
modern osprey
Unless you've been approved for a higher rate limit through your previous requests, those outlined in the docs would be the correct rate limits.
soft finch
Ok, I don't believe we're been approved for higher rate limits. Thank you.
Any other best practices you'd recommend for an endpoint that is used to create payment intents?
modern osprey
I think what you've thought through is good enough. When do you create a PaymentIntent on your checkout flow? Is it when the customer lands on a specific page?
If so, you could look into - https://docs.stripe.com/payments/accept-a-payment-deferred This flow allows you to collect payment method details without needing an Intent and avoid creating unnecessary Intents.
soft finch
We have public facing donation pages where we're people can enter arbitrary amounts and we render the payment element accordingly. We've solved working with cards and asynchronous payments (BACS direct debit), but we're trying to make our existing flow work with wallet payments, which is when we decided we needed to add an endpoint to create payment intent in the backend before confirming it in the front end with the Elements object.
nimble timberBOT
modern osprey
Gotcha. The flow I shared above should work with wallets as well
soft finch
Hmm, I'm not sure I follow. This looks like what we're doing already for the most part, including step 4 which is "create a payment intent", which is what we do when the user submits the form.
I don't think we're creating unnecessary intents, we only create one per form submission
dusky flax
Hi, taking over as my teammate needs to step away. Let me catch up.
soft finch
I think our main concern with rate limiting is a spammer finding our endpoint and rate limiting us into an outage for our customers
dusky flax
There are a couple of ways you can integration with Stripe. The options are https://docs.stripe.com/payments/accept-a-payment-deferred and https://docs.stripe.com/payments/accept-a-payment?platform=web&ui=elements if you're building everything on your end.
The first one, you do not create the PaymentIntent first. You collect the payment method details before creating the PaymentIntent.
The second option, you create the PaymentIntent and then use the client secret to render the Elements UI.
If you're not creating un-necessary intents, you do not know need to worry about it. Our rate limits are high as long as you do not make any un-necessary GET calls etc and following the recommended integration paths shared above
soft finch
Ok that sounds good. For spam protection, I think we'll just implement our own endpoint rate limit commensurate with Stripe's so we won't need to worry about an outage. We've discussed this as a team, but I'm curious: does that make sense as a strategy to you? Or maybe overkill?
dusky flax
I think that makes sense. If you get a higher spam, sure.
soft finch
Awesome, thanks so much!