#denjaland_api

1 messages · Page 1 of 1 (latest)

jaunty cradleBOT
#

👋 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/1369017615678439554

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

wet axle
#

hello! i'm not completely sure i understand the question - are you looking for how to verify for certain that a customer has paid?

grave trench
#

Hello. I'm working on a new integration for a customer, and I'm always a bit confused as to what object exactly to map to a payment. In theory, I'd say a charge == a payment, but would it be okay to just use payment intents and consider them as a payment in our system?

#

I guess my question is: when I create a paymentintent, we now create a payment object in our system which already references the payment intent with stripe

#

so when we get the webhook back, we are fetching the payment and updating its data (status / amount...)

#

in previous integrations we always did that on the level of charges, but I'm a bit doubting now whether it would not be enough to look at the payment intents unless I'm missing a use case where that would not be mappable 1-to-1

wet axle
#

the PaymentIntent is exactly what it sounds like - it's an intent to pay. a Charge would technically correspond more directly to the actual payment. but for most intents and purposes you can use the status of the PaymentIntent to track whether or not a customer has paid, so if i understand your question correctly it should work just fine for your purposes.

for example our doc that walks through how to verify that payment has succeeded specifically recommends listening for the payment_intent.succeeded event - not the charge.

grave trench
#

that is exactly why I was doubting whether we should not just check for payment intent status

#

but what if we have 2 charges for 1 payment intent - I guess that is possible fr instance when we have a sepa credit transer, and the customer pays in 2 times?

wet axle
#

i'm actually not sure off the top of the head what the behavior would look like in that event - i think the recommendation would still be to look for payment_intent.succeeded but let me double check some things

grave trench
#

that would be most appreciated. I think we can make our implementation a bit more elegant by just checking the payment intents, and get everytthig from that object, and just ignore charges 🙂

wet axle
#

ok, everything i'm reading suggests that you can definitely just listen to payment_intent.succeeded but i am still reading up on details

grave trench
#

yes, but listening to, and only looking at the payment_intent object is also still a nuance I'm not sure of

#

nevermind - I need to check the charges...

#

check pi_3RLRvVQJdLpJXNmo0n5dgdlG - the pi still has received_amount set to 119427 even though there has been a refund on the charge re_3RLRvVQJdLpJXNmo0fhG4SsX.
so I still need to do a sum(amount_captured - amount_refunded) from the charges to know the net amount I believe.

#

okay - I'll just stick to the original implementation I guess :-). thanks for checking into it though. It's been a while since I worked with your API, and still love it, but sometimes there are these tiny quirks left and right that make me thing "damn" 😉

wet axle
#

gotcha - that makes sense. and yeah, if your end goal is to figure out the net amount after refunds etc. then you would not be able to get all of that info directly from the PaymentIntent

#

the PaymentIntent will tell you basically everything you need to know up until the point that payment succeeds, but i don't think it holds data on refunds

grave trench
#

it doesn't indeed - I just hoped that the 'amount received' would update to what it received, but it doesn't after refunds 🙂

#

thanks again though - still and always lovely to chat to your team - by far best dev support out there.

wet axle
#

always appreciate the feedback, and we're happy to chat with you too 🙂