#zak_ideal-sepa
1 messages ยท Page 1 of 1 (latest)
๐ 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/1278384743729074277
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Do you have an example Setup Intent where you're not seeing a Payment Method? My guess is that the payment method wasn't fully setup yet and so you have to check latest_attempt to ensure that it was actually created
if you look at cus_Qk0R6vRUx9lIQu
an earlier test I've done
what I meant to say is that the setup_intent.suceeded webhook returns pm_1PsWQUK2LJ3kGqAoOkplPgM1 not pm_1PsWR0K2LJ3kGqAoWlxO2oV8
I guess I'm trying to understand the logic
to anwer the "not setup yet" guess I don't think it matters because if you resend the webhook it's still sending pm_1PsWQUK2LJ3kGqAoOkplPgM1
Can you show me the Event IDs for the webhooks you're referencing here?
calling retrievePaymentMethod on the customer with pm_1PsWQUK2LJ3kGqAoOkplPgM1 will return null
and the only way to get the actual one that I have found is to query the setup intent with the "latest_attempt" expand
it's just a weird flow... trying to wrap my head around why it's like that
But you said there where 2 webhooks you received with 2 different Payment Methods. Can you find the other one?
ah sorry this is not what I mean
this is the webhook I received
I don't think there was another one
what I was saying is that it doesn't matter if the invoice is paid or not
the setup intent doesn't seem to change
Why would it? The Setup Intent has nothing to do with the Invoice. It just sets a Payment Method up for future usage. From there, the only thing connected to the Invoice is the Payment Method.
let met try to ask differently
why in the case of iDEAL, it doesn't return the expanded view of the setup intent?
since iDEAL is not really the payment method, it would be logical to me
Why doesn't what return the expanded view of the Setup Intent?
when you go through the iDEAL flow... it's always going to return the iDEAL payment method, however like I said, first you can't query the API for retrievePaymentMethod for that PM on the customer because it will return NULL, and second the actual payment method is not the iDEAL payment method, it's the SEPA Direct Debit
wouldn't it be logical for the setup_intent webhook to return the SEPA payment method instead of the iDEAL one?
maybe there is another webhook I should be looking for
I just think the flow is confusing
you get a payment method returned that you can't query on
When I look at my user I see this
yet the setup intent (sane as the one on the screenshot) returned pm_1PsWQUK2LJ3kGqAoOkplPgM1
and when you look at that seti all you see is this:
Can you copy/paste that Setup Intent ID?
seti_1PsWQWK2LJ3kGqAoGZsUx4gX
Okay, going to sort of think out loud here to try and hone in on the issue. So this Setup Intent has had 4 different Events that would result in webhooks.
evt_1PsWR0K2LJ3kGqAo1URTgKHG
setup_intent.succeeded
2024-08-27 20:56:14
automatic
evt_1PsWQXK2LJ3kGqAoNZJsjHo4
setup_intent.requires_action
2024-08-27 20:55:45
evt_1PsWQXK2LJ3kGqAojQFE2my1
setup_intent.requires_action
2024-08-27 20:55:45
evt_1PsWQXK2LJ3kGqAoHtK2Hr8k
setup_intent.created
2024-08-27 20:55:44
The Event you posted (evt_1PsWR0K2LJ3kGqAo1URTgKHG) is the setup_intent.succeeded webhook event, which has the Payment Method that was actually confirmed via the Setup Intent.
The issue you're talking about is: for some reason when you view the Customer in the Stripe Dashboard, you're seeing the SEPA Payment Method ID instead of the iDEAL Payment Method ID. Am I with you so far?
sort of ๐ I think it's logical to see the SEPA because that's what iDEAL sets up
what I don't get is why the setup_intent.succeeded doesn't reflect that
and gives you only the iDEAL PM id that you - apparently - cannot query to get to the SEPA
I see, okay. So I think I understand. What do you need the SEPA Payment Method for specifically?
Just to charge it right?
not even, just to save it and display it in the customer's account
Gotcha. I think the only info you can really display here is going to have to come from the Setup Attempt, which you get from expanding the latest_attempt on the Setup Intent. I assume you've already looked at the iDEAL Payment Method object and confirmed the info you're looking for isn't there?
zak_ideal-sepa
yes, in the SI, we just get:
"payment_method": "pm_1PsWQUK2LJ3kGqAoOkplPgM1",
"payment_method_configuration_details": null,
"payment_method_options": {
},
"payment_method_types": [
"ideal"
],
And querying the API to retrieve that PM, returns null...
only way I found was indeed querying the SI with expanding
but I was feeling like maybe this is not the right way?
It is definitely the right way. That's exactly how we designed that API. The SetupAttempt has the information and its a separate resource so you expand the latest_attempt property
totally fine. Our Expand feature is amazing but it is hard to grasp at first
kinda feel like in the iDEAL situation
the webhook should auto expand though
๐
yeah but if we auto-expand everything then what's the point of expansion :p
Expanding all the related objects is really costly to do. Also it's kinda a breaking change, your code can't know if you are getting a string for the id or the full object.
ah yeah that make sense
but in my integration to differentiate with a credit card, is my only option the payment_method_types?
currently we just call retrievePaymentMethod on the customer but that doesn't work when the PM is iDEAL
(like I said earlier for some reason it returns null but maybe I'm at fault)
yeah sorry that's a bit of a vague question right now too focused on your code. Like what does retrievePaymentMethod mean? What are you trying to really answer?
Like right now you have a SetupIntent, and it's confirmed. The associated PaymentMethod pm_123 has type: 'ideal'. And separately we created another PaymentMethod pm_ABCDEF that has type: 'sepa_debit'
I mean calling https://docs.stripe.com/api/payment_methods/retrieve with pm_123 returns null
Fairly certain that's impossible and you're misunderstanding something. It might return an error but not null
you are right
there is a bug in our "stripe mediator" it looks like
it's adding a customer id to the request but it looks like the iDEAL PM is not tied up to the customer directly
in other word, when i call with just the PM id it works
Just expand both the payment_method and latest_attempt properties and get the full objects
you mean on the SI right?
yes
cool