#CheckMate-payment-intent

1 messages ยท Page 1 of 1 (latest)

wispy needle
#

๐Ÿ‘‹ Happy to help

opaque mauve
#

Hi @wispy needle

wispy needle
#

There's no expiry to the PaymentIntent. Could you share what you are looking to achieve?

opaque mauve
#

suppose I create payment intent with 200 dollars now. In next 15 mins price changes to 400 dollars. So previous payment intent should be null . How do I achieve that ?

#

Basically I want payment-intent which expire every 15 mins . Is that possible ?

#

@wispy needle are you there ?

wispy needle
#

Discord is a bit busy at this moment. Looking into it now

#

Stripe doesn't handle expiry of a PaymentIntent. This will be done at your server. One possible way I can think of is:

  1. Create a PaymentIntent (pi_123) with $200
  2. Set 15 mins timer in your system
  3. After 15 mins is up, update pi_123 to $400 if the payment is not paid
opaque mauve
#

okay cool

#

Have one more question.

wispy needle
#

What's the question? ๐Ÿ˜„

opaque mauve
#

What is the use of this client_secret

#

?

wispy needle
opaque mauve
#

What is much of difference between client_secret and payment_intent_id. What is so secret about client_secret. It can be viewed in client_side and payment can be done with it.

wispy needle
#

Client secret is used for client-side retrieval using a publishable key whereas it can't be done with payment_intent_id alone

opaque mauve
#

I have one more small question

#

Here it is written that client_secret is retrievable by publishable key..But how exactly do I do that. What request should I send to get client_secret using publishable key ?

#

Can you please send a cURL

soft saddle
opaque mauve
#

No that is retrieve a payment_intent using a c lient_secret

#

I am asking for retrieving client_secret using publishable_key

#

The how part is not mentioned though.

soft saddle
#

you're misunderstanding unfortunately, that's not possible

#

The client secret of this PaymentIntent. Used for client-side retrieval [of the PaymentIntent object] using a publishable key.

#

that's what it means

opaque mauve
#

Sorry I am not understanding it clearly... There is a phrase "RETRIEVABLE WITH PUBLISHABLE KEY" beside some of the parameters like currency , client_secret etc.

#

What does it mean exactly ?

#

could you please explain

soft saddle
#

It mean that when you retrieve the PaymentIntent using a publishable key (with the client_secret) then a subset of the fields on the object are returned from the API(for security reasons there's lot of sensitive info that shouldn't be exposed on the frontend), that subset being the ones marked as 'retrievable with publishable key'.

#

is there a specific problem you're trying to solve here?

opaque mauve
#

Okay got it.

So as I understand,

There are three keys :
secret_key,
publishable_key,
client_secret,

Now to confirm a payment_intent, you can do it using either of

  1. only secret_key
  2. publishable_key and client_secret
    (or are there other ways... if yes please tell )

Is the above correct ?

Not trying to solve a particular problem here .. Just trying to understand the docs better.

soft saddle
#

that all sounds right. I wouldn't call the client_secret a key. It's just an extra value that if you have access to it, lets you do more with a publishable key than without it, scoped to a specific object.

opaque mauve
#

Cool got it. Thanks for the help.

#

I have one more small question.

#

the payment_intent_id could have been kept secret itself. Why do we need client_secret ?

soft saddle
#

because we don't consider the ID to be secret

opaque mauve
#

okay cool

#

But why have ya'll taken the call to not consider ID to be secret ?

#

and a separate ID (client_secret) that should be kept secret ?

#

What was the use case ?

soft saddle
#

because IDs were never secret before, wouldn't make sense to add a new object to an existing API where users likely store the <obj>.id field in logs or databases and try to tell them they should treat one specific type of object differently. The ID also appears in lots of places like CSV exports or URLs or in the dashboard.

#

the use case is that we want to perform a sensitive operation(attempting a live payment on a real payment method) entirely from the frontend without a round trip to your server every time, so to avoid that being easily abusable, the frontend can do it, but it needs the involvement/agreement of your backend to use a secret API key to get a required extra "token" (the client_secret) and supply it to the frontend.