#Skarmoryman-paymentintents

1 messages · Page 1 of 1 (latest)

rigid glade
#

@surreal holly hi! hmm, what do you refer to as "charge ID" specifically? It's a bit hard to give a general answer here, PaymentIntents are a state machine and there are multiple ways to create them and not every way will attempt to charge a payment method, so it really depends on your context

surreal holly
#

If I understand correctly, a successful payment intent creation will create one successful charge. Basically I’m wondering the scenario where the payment intent does not lead to a charge creation. Let’s say I input a card that gets declined. Etc

#

@rigid glade

rigid glade
#

a successful payment intent creation will create one successful charge

no, since as I said, it depends how you create it

#

a PaymentIntent confirmation is what creates a charge

#

but you can just call the API to create PaymentIntent with nothing but an amount, and then add the payment later, and then confirm it later, and it's the confirmation that attempts the payment.
Or you can pass everything upfront and pass confirm:true on creation, and that attempts the payment immediately.

#

let’s say I input a card that gets declined
if you confirm it with a card that is declined, it creates a Charge(you can inspect the charges field of the PaymentIntent for a list of historical attempts to create a successful charge)

surreal holly
#

@rigid glade Thanks for your answer. I just submitted a test card that gets declined. I then checked on the Stripe dev portal and I do see a charge ID.

However, when I created the payment intent with this call,

response = stripe.PaymentIntent.create(
payment_method=stripe_paymentmethod_id,
confirm=True, # confirm that customer intends to pay with provided payment_method -- Always True in our case
description=description,
amount=amount,
currency='CAD', # do not ever touch this
customer=stripe_customer_id,
metadata=metadata
)

I simply receive back a Stripe exception that I can catch with a try, except. I do not receive back a regular payment intent object. Can you confirm that this would always be the case with how I am using the payment intents api?

example:
CardError(message='Your card was declined.', param=None, code='card_declined', http_status=402, request_id='req_DMvGcgZWX25Pu3')

rigid glade
#

I can catch with a try, except. I do not receive back a regular payment intent object.
you get both actually

surreal holly
#

@rigid glade I see. Thanks for you help.

When a charge fails, the payment intent/charge id would be irrelevant for me.
I am safe to simply use the try except to always catch these cases right?

i.e. With how I am calling the api, if there is no exception raised, then a I know the cc charge was successful?

rigid glade
#

also your code is a little backwards(you presumably create the PaymentMethod first, send it to your backend server and then create the PaymentIntent, which is the old way of doing things in Stripe, it's generally recommended you instead do : create PaymentIntent -> confirm on the client side to process the payment -> handle webhooks for success notification (https://stripe.com/docs/payments/accept-a-payment ))

surreal holly
#

@rigid glade Appreciate you letting us know. I will look into changing the order.

Just curious whats the reason the new method is recommended?

Other than that I am good, thanks.

rigid glade
#

because it works better for things like 3D Secure

#

in your integration, if the card requires 3D Secure(which most cards in Europe will), your PaymentIntent confirmation will fail and you have to go back to your frontend and have the customer complete it , so it's more back-and-forth. What you are building in that code approach you mention is https://stripe.com/docs/payments/accept-a-payment-synchronously which as noted, is possible, but not the first recommendation.