#alpha_paymentintent-finalize

1 messages · Page 1 of 1 (latest)

sonic hollyBOT
#

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

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

junior heronBOT
jolly frost
#

alpha_paymentintent-finalize

#

@lilac adder what's your question exactly? You said you want something and then linked to the exact documentation that offers this

lilac adder
#

I need to integrate Stripe Connect. I need to finalize payment on the server because I have some essential business logic to carry out transactionally with payment confirmation. Our system has constraints so that we cannot provide return/redirect URLs. We are happy not to use payment methods requiring the redirection. We do not want to rely on Webhooks to finalize payment order because we've had experience where webhook did not hit our server, and hence we did not deliver order for successful payments. Please suggest a solution

jolly frost
#

Sorry you copy-pasted the exact same question with no additional info. I read your question, I understand it fully. You found the exact docs on how to do this. Can you please explain what is blocking you?

lilac adder
#

I see, apologies - 1) It askes for return_url which we don't have, 2) It does not say how can I set redirec=never, 3) In case of action_required, I again need to rely on a subsequent call to know if payment was successful - which prevents the payment and our custome logic being transactional (atomic)

#

Keypoint: We can't provide redirect/return URL, we do not want to relay on webhook or susequent call which breaks the atomicity of payment+custom logic.

#

In fact we have already lost significant part of revenue just because the payment_successful webhook never reached our server

#

Therefore it is crucial that Payment Confirmation and Order Finalization are transactional, i.e. either both fail or both succeed. While per this article and other documented examples I could not find how to make Payment Confirmation and Order Finalization atomic.

jolly frost
#

Webhooks are a crucial part of integrations like yours. Trying to avoid it is a real mistake especially as a platform.

just because the payment_successful webhook never reached our server
this would be something you should debug. We retry Events for up to 3 days, multiple times in a row.

#

What payment methods to you plan to handle? Card and nothing else?

lilac adder
#

Correct - but 1) How can I debug a request that never hit my server AT ALL, and 2) I mentioaned it's near real time food ordering system - meaning a if I ordered a burger now, web hook fails but a retry passes tomorrow, I will sleep hungry. This has happened to us on multiple occasion. The webhook are never guaranteed to delivered on time, and disallow for operations to be transactional, while in the payment world atomicity is prime concern

jolly frost
#

How can I debug a request that never hit my server AT ALL
we can help and your hosting provider can help too.
ordered a burger now, web hook fails but a retry passes tomorrow, I will sleep hungry
yes but we retry minutes later after a first failed delivery. Also webhooks are a back up solution to ensure you didn't miss any. They aren't the default integration path. There's a real browser redirect that happens during the payment that you can rely on for the majority of payments

lilac adder
#

Re " back up solution to ensure you didn't miss any. They aren't the default integration path" exaclty! I am trying to find a 'default integration part' that guarantees atomicity.

#

Re "we can help and your hosting provider can help too", thank you for the offer, but in busy time 100s orders get placed in minute, in the lates incident webhooks missed our server for 4hours, hundreds of payment succeded but order not delivered. We are facing legal consequences

jolly frost
#

yeah sorry you seem quite set in your approach. It's not the right one but I definitely can't force you. So let's ignore this for now

Can you please share an exact code and related API request where you get an error?

lilac adder
#

Sorry, what gave the impression that I am "set in"? If I was already set in, I wouldn't seek help here. I am open to change as long as the Payment Confirmation and Order Finalisation is guaranteed to be atomic

#

And sorry, I didn't say I get an error - I said webhook never hit our server. Theoretically speaking however reliable infrastructure is, theoratically stateless nature of HTTP communication never guarantees the operation atomicity where the operation spans multiple http requests

#

I am seeking a solution that spans a single http request

jolly frost
#

All good, I just don't think I can undo that mindset where you think it's so common for Events to never reach your server that you have to work around it and it's not going to help you much
So let's recenter on your question: you mentioned "some error" but you didn't share detailed information. Can you, as the developer, share the exact code where your create a PaymentIntent and the exact error you get

lilac adder
#

Sorry mate, I said NO ERROR, it is NOT a coding error, it is the communication error. The problem is not with the code, it is with the architecture. OK, imaging it's a greenfield project and I want the Payment Confirmation and Order Finalization atomic. Please suggest me a solution

jolly frost
#

😅

#

I have to run but @sharp scarab is taking over for me. They will be able to help you once you share the exact/relevant information about what's blocking you while implementing https://docs.stripe.com/payments/finalize-payments-on-the-server?locale=en-GB in your code

@sharp scarab earlier they mentioned

  1. It askes for return_url which we don't have, 2) It does not say how can I set redirec=never, 3) In case of action_required, I again need to rely on a subsequent call to know if payment was successful
    which I think you can explain if that's their blocker
sharp scarab
#

👋

lilac adder
#

I am sorry @jolly frost you never comprehend the problem from the beginning. You demonstrated to be lacking the concept of transaction atomicity. And it might be normal in your culture, where I live the statements like " I just don't think I can undo that mindset where you think" are taken to be offensive. I have worked over 20 years and have good experience with payment channels/messging/frameworks including but not limited to SWIFT, SEPA and TARGET2 - all of them have enough to ensure the tansactional nature of operation. I am not sure why are you insisting on me to ignore the atomicity.

#

My system give over $60K revenue to Stripe, I thought I deserve the respectful treatment, but I am sorry, they way to came across appears to me to be disrespectful

#

(I menat over $60K a year.)

sharp scarab
#

Sorry none of this is helpful. I can attempt to resolve your issue if you can provide clear details about your integration

#

Can you provide the exact code that is showing the error you describe, along with th API request ID where this code is thrown?

lilac adder
#
  1. I want to ensure that I do not use a payment method that may require redirection. I am only using cards, google and apple pay. In the example in the link above, how do I ensure that my payer is never presented with a payment method that requrest redirection. This is because our system has constraint that it cannot provide return/redirect URL. and...
#
  1. In the case of action_required, how do I ensure that payment-confirmation and my custom logic (order finalisation) are carried out in atomic transaction.
#

Let's assuem I had not issue, not previous code - advise me from the point of view of absolutely new project

#

As a summary: I am looking for a solution where "Payment Confirmation" and "Order Finalisation" take place in a single http request.

#

(If there is any)

sharp scarab
#

Let's assuem I had not issue, not previous code - advise me from the point of view of absolutely new project

I would not. This server is for developers writing code to integrate with the Stripe APIs. We do not perform in-depth business logic reviews here. I can offer advice about specific parts of the Finalize on Server integration you linked.

For these concerns can you point to specific sections in the docs

lilac adder
#

My mistake to get involved with idoios