#bjsbx_webhooks

1 messages · Page 1 of 1 (latest)

leaden sundialBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1255245111542022164

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

native hearth
#

Hello
Is there a specific reason you're using manual confirmation? Just want to make sure I am on the same page

obsidian wasp
#

No. I think this was just our understanding on how confirmation works.

#

When using the Stripe SDK on react native, does the UX handle confirmation? If not, are there implemtation guides on how to handle payments that require it?

#

From the client side, via Stripe react native SDK, how do we know if a payment intent requires confirmation? Do we need to the client to call stripe to figure that out per payment intent?

native hearth
obsidian wasp
#

Sure, ill need a minute.

native hearth
#

No worries

#

take your time

obsidian wasp
#

I cleaned this up a bit to remove some unnecessary metadata. But this is how we generate our payment intent in node. We don't pass confirmation_method explicitly as I believe the default is automatic anyways.

paymentIntent = await this.client.paymentIntents.create({ amount, currency, customer, payment_method_types, setup_future_usage: "on_session", });

We in turn pass back an empheralKey and publishableKey back to the client. The client uses initPaymentSheet via the Stripe sdk on react native.

Am i correct to assume the server should be setting requires_confirmation?

#

The crux of the issue we're seeing is when some users pay via ACH. Then it gets stuck on requires_confirmation.

native hearth
#

Or even PaymentIntent IDs should work too i.e. pi_xxxx

obsidian wasp
#

I don't have a stuck one atm, but i can see if i can find the the few that got stuck in the last week

native hearth
#

Yup, if you don't find one then any random PaymentIntent ID would work too

obsidian wasp
#

Is it safe to pass a PI id in this chat?

native hearth
#

yup, it is safe

obsidian wasp
#

pi_3PNO9LJhkqgFUbV21jHF4ZDz

#

It's not currently stuck as we've confirmed it. But at one point it was stuck and user couldn't continue.

native hearth
#

It doesn't look like it was in requires_confirmation status. However, it was in requires_action status.

Is that what you're referring to?

obsidian wasp
#

It was in requires_confirmation at one point

#
  "status": "requires_confirmation",
#

This is another payment intent pi_3PLq5lJhkqgFUbV20F0m2Naz

native hearth
#

Oh interesting... taking a look

obsidian wasp
#

So my original plan was to try to implement a requires_confirmation status from a webhook on the server side. So we can relay that back to the client. But just found today that stripe doesn't support returning requires_confirmation. Well at least per the SDK. Not sure if the rest api does. Preferrably the Stripe React Native SDK would handle allow the user to press "confirm", but that's where we are unsure of on how the recommended flow.

craggy wharf
#

Looking in to this. I am fairly certain that requires_confirmation happened here because a payment method was attached to the intent but the intent wasn't confirmed. That can only happen through a server-side API call, so the response with the requires_confirmation status would be the signal for that status.

obsidian wasp
#

I see

#

I guess my next question is, how can my server know the status of the payment intent without retrieving each one. I don't think the webhook returns a requires_confirmation status. Correct me if i'm wrong here.

craggy wharf
#

As far as I can tell, outside of the manual confirmation flow, these intents should only go in to a requires_confirmation state as the result of an API call that your server makes. So it would get that status back as part of the response to that API call

obsidian wasp
#

Our server generates the payment intent but our client intiates the api call for the transaction. At the moment, our server is just waiting for webhooks.

#

Via the React native STripe sdk

#

I'd have to double check, but we only started using the CLI to get PIs out of requires_confirmation.

craggy wharf
#

I actually don't see any attempts to confirm that payment intent from the react SDK, only the CLi

#

Can you make another payment intent, confirm it through your react app, and send me the ID so I can take a look?

obsidian wasp
#

I'm not sure how to generate this type of status. But to clarify, I don't know how to get the client to confirm the payment intent.

#

Via the SDK

craggy wharf
#

So this status happened when someone on your account attempted to confirm that intent via the CLI but got an error because mandate_data was not supplied when it was needed. That is the request that I linked to

#

Ah so you haven't been testing on these payment intents with the react SDK at all yet?

obsidian wasp
#

These actions happened after we found a stuck confirmation

craggy wharf
#

That intent was not in a requires_confirmation status until that API call.

obsidian wasp
#

We have been testing we're not able to test this particular scenario as I'm not sure how to get into a requires_confirmation state

#

I see

#

Even this payment intent @craggy wharf ? pi_3PLq5lJhkqgFUbV20F0m2Naz

#

I'm can regroup and reach out if or when this happens again. So I can be sure I'm not affecting the PI with the CLI.

craggy wharf
#

That PI got to that state a different way. Checking in to this

obsidian wasp
#

Ok ty.

leaden sundialBOT
craggy wharf
#

I do actually see a React SDK action moving this intent in to that requires_confirmation status but it doesn't look like a confirmation. Can you send me your react code for confirming these intents?

obsidian wasp
#

Checking

#

Ok I cleaned up some more identifiable data if you don't mind. But this is the gist of it. We don't explicitly handle the confirmation to be clear. We have no code for it. If that's not right, then we can fix that.

await initPaymentSheet({
        appearance: customAppearance,
        merchantDisplayName: "INC",
        customerId: customer,
        customerEphemeralKeySecret: ephemeralKey,
        paymentIntentClientSecret: paymentIntent,
        allowsDelayedPaymentMethods: payWith === PayWith.Ach,
        returnURL: "www",
        defaultBillingDetails: {
          name: "name",
          email: emailAddress,
          address: {
            country: shipToCountry,
          },
        },
        defaultShippingDetails: {
          name: "name",
          email: emailAddress,
          address: {
            country: shipToCountry,
          },
        }

      });
craggy wharf
#

Ah interesting. I got to the same place with a PaymentIntent by selecting an ACH bank account in the payment sheet but not confirming the intent

obsidian wasp
#

Reading this documentation i see this bit. https://docs.stripe.com/payments/accept-a-payment?platform=react-native&ui=payment-sheet

Setting allowsDelayedPaymentMethods to true allows delayed notification payment methods like US bank accounts. For these payment methods, the final payment status isn’t known when the PaymentSheet completes, and instead succeeds or fails later. If you support these types of payment methods, inform the customer their order is confirmed and only fulfill their order (for example, ship their product) when the payment is successful.

Securely accept payments online.

#

But not sure what to do afterwards if this is a delayed method.

craggy wharf
#

This is, but this behavior is slightly different than that. That exerpt is talking about the pending status for intents. So here is the current lifetime of one of your intents that takes an ACH payment:

obsidian wasp
#

Gotcha. Yea when it goes from pending to succeeded we can get the events back from webhooks. So we can act accordingly.

craggy wharf
#
  1. The intent is created on your server, it starts in a requires_payment_method state
  2. The customer chooses a bank account to pay with on their phone, that account is associated with the intent, moving it to a requires_confirmation status.
  3. The customer clicks the "Pay" button on the payment sheet, the intent goes in to a processing state while we wait for the bank's response, which can take days in live mode.
  4. Once stripe hears back from the bank, the intent moves in to either a succeeded or requires_payment_method state depending on whether the charge succeeded or failed
#

So with the intents that you are seeing in requires_confirmation, as best I can tell the payment process was started on your app but not finished. I think that that may be invisible and am honestly not sure why we change the status and surface it to you like that.

obsidian wasp
#

I believe there's an optional step between 2-3 where after it is confirmed, it may require_action such as verifying micro deposits. What I've had to do recently is confirm the payment,from the cli, then the buyer still has to do a micro deposit usually.

craggy wharf
#

Good catch! That is exactly where it would happen

obsidian wasp
#

The hard part is how do we surface this to the user so it's obvious it needs to be confirmed. The SDK is a black box for this scenario to me since I can't actually test it. At least as far as I know.

#

Also, it feels icky "confirming" a payment for a buyer. It seems they should be confirming it.

#

Even if hypotehtically I can get the server to reliably catch confirmations and confirm them automatically

craggy wharf
#

I think in this case you don't have to do that. Our sheet shows that they still need to submit the payment, this is more of the customer wandering of for some reason

#

Agreed, you shouldn't confirm these intents for them.

obsidian wasp
#

I see

craggy wharf
#

Requires action it might make sense to watch for because the user did submit the payment at that point, but that depends on your preference.

obsidian wasp
#

I see, Though the PI won't get to requires_action before the requires_confirmation. From my observation, only after the PI is confirmed does it move to requires_action.

craggy wharf
#

Exactly, sorry sounds like my wording was off there. requires_confirmation is a before the confirm status and requires_action is an after the confirm status.

obsidian wasp
#

Ok so in theory, the Stripe React Native SDK should show the user the "pay" button to confirm. But in our scenario, this step may be not completed by the buyer.

craggy wharf
#

Exactly. It looks like these statuses were reached by getting to this screen after they have connected their account

obsidian wasp
#

Also the PI lifecycle goes from processing to requires_confirmation. I'm not sure how to get the buyer to confirm after they potentially backed out the first time. If it ends up in requires_action, we reviceive a webhook and it even has a hosted url for micro deposits. So we can surface that on the UI. I feel ike if a payment intent goes to requires_confirmation and doesn't complete, we cancel it?

craggy wharf
#

As far as I know, PIs can't go from processing to requires_confirmation , do you have an example of that happening? processing should only happen after the intent is confirmed

#

That is a sensible way to work with requires_action, and I would say treat requires_confirmation the same way as intents staying in requires_payment_method for two long. It is an abandoned card after some point so you can cancel them if you clean those up.

obsidian wasp
#

Your advice makes sense. I think the last thing though is that webhooks dont seem to return requries_confirmation? Am i wrong in that?

craggy wharf
#

You are correct there. So I don't think you can get notifications about them. How have you been finding these, listing by status?

obsidian wasp
#

searching via CLI

#

Seems clunky

#

We'll I think I can manage. Appreciate the help. I have a better understanding of the flow.

craggy wharf
#

Yeah, if you want to clear out abandoned carts it may make sense to either keep a record of all of your PIs and then cancel them if you don't get a succeeded event for them, or you can preiodically list payment intents by the requires_payment_method and requires_confirmation statuses that were created before a certain date.

obsidian wasp
#

Sounds good

#

thank you!