#peter_braganza - payment intents

1 messages ยท Page 1 of 1 (latest)

brittle eagle
#

Hello. Let's chat in here

#

One moment while I catch up with threads

safe thorn
#

Ok

#

Background: We create the payment method first, pass it to the backend, create the payment_intent and try and confirm it. Then pass the response to the front end. If it requires action, we handle this on the front end

#

Reason we do this, is because we sometime mix subscription setups with one of payments

#

And also sometimes we have more than 1 stripe account (we use stripe connect with direct charges), so we create the payment method on our platform in this case so we cna charge on the 2 accounts

devout owl
#

Hi there ๐Ÿ‘‹

Yes you could use idempotent requests here to repeat the same request(s) to reduce the risk of duplicate charges. This functionality is built into our API, and you can read more about it here:
https://stripe.com/docs/api/idempotent_requests

You can also put a note on the page to your customers telling them not to refresh the page, I see this approach pretty often in the wild.

safe thorn
#

If we make a request with an idempotent key and the card is declined, and they enter a new card and we send a request with the same idempotent key, would that be ok?

craggy hatch
#

no you would get an error in that case since you are re-using the idempotent key with different parametets

safe thorn
#

Right, so it must be the same parameters

#

So really this wont help our cause?

#

If they refresh the page

#

I think the most robust option is to use webhooks

#

and create PI when the page loads

craggy hatch
#

With PaymentIntent you don't really need idempotency keys since the PaymentIntent can only be successfully confirmed once, unless you create separate PaymentIntents which you shouldn't for a given customer

safe thorn
#

Ok, so low hanging fruit is just "dont refresh page"

#

Question is, why at peaks times do we have this issue

#

Is it a stripe things

#

Do you throttle requests

craggy hatch
#

depends what you call "peak time" and "throttle"

safe thorn
#

We sell tickets to events, and sometimes have lots of people trying to buy them from the same stripe account at once

craggy hatch
#

We have rate limits: https://stripe.com/docs/rate-limits
But you, as the developer, should be handling this already in your own code. It's also quite rare for a business to reach those limits

safe thorn
#

I think its more likely our server

#

We wait for the payment intent response to come back (from our backend) before we stop the spinning wheel on the payment screen

#

So when they click pay, we send a request to our backend, then create the payment_intent, confirm it and pass the response to the front end

#

Its the response coming back which hangs

#

Although it is successfull on stripe

craggy hatch
#

yeah that's hard to say. You should consider creating the PaymentIntent earlier in your flow instead of when they click Pay

safe thorn
#

Yes, buts its because of what I said:

#

Background: We create the payment method first, pass it to the backend, create the payment_intent and try and confirm it. Then pass the response to the front end. If it requires action, we handle this on the front end
Reason we do this, is because we sometime mix subscription setups with one of payments
And also sometimes we have more than 1 stripe account (we use stripe connect with direct charges), so we create the payment method on our platform in this case so we cna charge on the 2 accounts

craggy hatch
#

gotcha

safe thorn
#

How would you advise?

#

I did have a good conversation with karlecho, is there ahyway I can find that conversation is Discord?

craggy hatch
#

I don't really have a good recommendation if you have such a complex set up

#

you can search

safe thorn
#

Can a customer be created without a payment method?

#

Just thinking we could do this

#

1/ Create customer

#

brb!

craggy hatch
#

๐Ÿ™‚

safe thorn
#

back

#

Ok, so

#

1/ Create customer

#

2/ Create subscription

#

3/ Add any additional payments to the subscription or create an invoice before creating a subscription

#

4/ Get the latest invoice and thus payment_intent client secret

#

5/ Send it to front end and confirm

craggy hatch
#

my colleague @wet tide is going to take over and they can help if you have a follow up question

wet tide
#

๐Ÿ‘‹ catching up here @safe thorn! Give me one moment.

#

The flow you outlined mostly seems fine. Are you running into a specific issue with it? I don't really understand step 3 in terms of context of "additional payments" but otherwise looks good.

safe thorn
#

We have the case where people setup a subscription and pay one off charges at the same time

#

We currently do this is 2 steps, by creating a payment method, then a customer, then charging, the setting up a subscription

#

When we are trying to change the flow to create a p_i when the page is loaded

wet tide
#

Hey sorry @safe thorn, missed this follow up.

#

What collection_method are you using for your Subs?

safe thorn
#

card

wet tide
#

Collection_method is send_invoice or charge_automatically.

#

This will determine whether we finalize the initial invoice for a Subscription immediately or not.

#

If you use send_invoice, there is a 1 hour delay for finalization where you could add invoice items to the initial invoice if you so desired.