#avneetsingh_11747
tropic hamletBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- avneet-paymentintent-idempotency, 4 days ago, 76 messages
forest tusk
this answers your question: https://stripe.com/docs/api/payment_intents/create#create_payment_intent-amount
Amount intended to be collected by this PaymentIntent. A positive integer representing how much to charge in the smallest currency unit (e.g., 100 cents to charge $1.00 or 100 to charge ¥100, a zero-decimal currency).
obsidian rapids
Got it thanks. Just to confirm if I want to charge user with any decimal amount lets say 20.56$, I can use double or float?
forest tusk
no, you misunderstood
to charge $20.56, you pass amount: 2056
2056c == $20.56
see above
A positive integer representing how much to charge in the smallest currency unit (e.g., 100 cents to charge $1.00 or 100 to charge ¥100, a zero-decimal currency).
obsidian rapids
Ok
forest tusk
does that help?
obsidian rapids
So amount needs to be passed in cents during payment intent creation that Stripe will automatically divide by 100 to convert in dollars?
forest tusk
yes and please try it in test mode, all of this is easily doable in test mode and you can look at the Dashboard to check what amount the PaymentIntent was created for
obsidian rapids
Ok in that case Can I change data type of amount in long to int?
or even in long it doesnt matter because anyways we will passing the amount in cents that stripe will automatically charge in dollars
forest tusk
doesn't matter, if the Stripe library has long type then just keep that, just pass/set a positive integer in that variable
obsidian rapids
One more question, I saw in Stripe documentation about idempotent key to prevent duplicate charge. This key can be generated using UUID. Lets say we are creating a payment intent using idempotent key which will be unique each time as UUID will generate a random no. If a transaction is successful, I would still be able to create duplicate transaction with the same amount and currency because idempotent key would be different (meaning different payment intent and a different client secret), right?
Is this a bug?
forest tusk
what's a bug, the way you have the above implemented you mean?
obsidian rapids
How can I prevent duplicate charge?
forest tusk
if you're doing
Lets say we are creating a payment intent using idempotent key which will be unique each time as UUID will generate a random no
then that's wrong, since you want the same idempotency key for certain cases e.g. when there's a network timeout and you couldn't tell if the API operation went through or not, so you want to "replay" what happened on the original API request
I recommend thoroughly reading through https://stripe.com/docs/error-low-level#idempotency as that will answer your questions
let me know if that answers your question
obsidian rapids
Ok
So, in general cases we don't need idempotent key. I was thinking of saving payment status in my DB so that if there is another payment attempt, it will first check whether the transaction was successful in the DB and accordingly it will prevent subsequent charge attempts.
forest tusk
it will first check whether the transaction was successful in the DB
except in cases where there's a rare 500 on the API request or a network timeout so you don't know if the transaction succeeded or not and the customer tries to pay again
in those cases, your second API request should use the same idempotency key as before to get the same replayed reponse of the first API request. Your solution won't work for this specific case, right?
to clarify - your approach is mostly good and will work for majority of cases, just stating which cases it will not work for
obsidian rapids
Got it
obsidian rapids
> it will first check whether the transaction was successful in the DB
except i...
What do you mean by using same idempotent key? Idempotent key will always be unique as it will be generated using UUID so during network failure how can I pass same idempotent key to avoid duplicate charge?
bold ibex
Hi there 👋 jumping in as my teammate needed to step away. The purpose of making an idempotent request is because you don't know whether the previous request succeeded or not, in case you don't receive a response. In that case you reuse the idempotent key of the request that you didn't get a response for, that way we know you're trying to make the same request again. If we received the request before, then we will respond with the same response we sent before. If we did not receive the request before, then we will process it for the first time.
You should generate a new idempotent key for every unique request, you should only reuse them to recover from network issues where you do not know if we received the request you tried to make.
obsidian rapids
In that case, I should be storing idempotent key in my DB so that if there is a network failure I can retrieve the key from DB and pass it with request rather than generating a new random key using UUID, right?
bold ibex
Mm, I don't think it needs to be stored in your DB, but I guess it could be. You'll only need the idempotent keys while you're actively making the request, and you'll know pretty quickly whether you need to retry the request. It seems to me like it would be costly timewise to write/read that key from the DB.
obsidian rapids
If there is a network failure and user wants to retry the request by logging back to the application, express checkout element and payment intent will be created again that will call for a unique idempotent key generation. Not sure how can I re-use the same key.. 😦
bold ibex
You shouldn't wait that long. You don't need to wait for your user to tell you to retry a request for a network failure, you should automatically do that so you know what happened to that previous request and can provide your user with the proper context. If you don't retry the request, you don't know if a Payment Intent was created or not, you can't assume one wasn't created.
obsidian rapids
Does the stripe response captures network failure status code or something?
bold ibex
Huh, this is for recovering from a network failure. Imagine the typical flow:
You make a request -> it reaches stripe -> we process it -> we respond -> you get our response
Now imagine after sending a request, you never hear back. That leaves you uncertain of how far the request got in the flow. Did it reach Stripe? Did we process it? Did we respond and that got lost? You don't know, and making the same request again, reusing the same idempotent key, is the way to find out. If we received the request before, then we will respond with the same response we sent before, meaning there is no risk of the duplicate request causing duplicate payments. If we did not receive the request before, then we will process it for the first time and respond normally.
bold ibex
Any time!