#kamon_best-practices

1 messages ยท Page 1 of 1 (latest)

edgy torrentBOT
#

๐Ÿ‘‹ 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/1417268837912543394

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

urban night
#

Adding a bit more context here:

The flow I'm essentially looking for:

  1. Present Payment Sheet to the user
  2. User enters their payment details
  3. Confirm the Payment Sheet with confirmPaymentSheetPayment to create the PM and have the confirmHandler called.
  4. In the confirmHandler, create the PI with the PM and do junk to the PI
  5. Display the updated PI junk to the user
  6. Confirm the PI

Due to the nature of payment sheets, in order for the confirmPaymentSheetPayment to resolve, the intentCreationCallback needs to be called with something, so I'm passing a dummy error ๐Ÿ™‚

#

If there are alternatives that allow me to view the created PM on a payment sheet, that'd also work.

I realize that moving the embedded elements likely is the best course of action here, but am trying to exhaust the Payment Sheet route before suggesting a refactor to the team ๐Ÿ™‚

#

(even if it's a tad hacky)

indigo seal
#

๐Ÿ‘‹ I think there are better ways to go about this then sending a dummy error.

urban night
#

That's what I was hoping, but I haven't had much luck.

I tried not calling the intentCreationCallback at all, but unless that method is called the confirmPaymentSheetPayment hangs and never resolves.

indigo seal
edgy torrentBOT
urban night
#

Correct, Payment Sheets aren't exactly designed for this, but you can specify customFlow as true which allows the flow to be two-step, but the problem there is my flow needs the PM to be attached to the PI

loud silo
#

hello! fyi i am taking over the thread, catching up on things now

urban night
#

Hello, thank you, appreciate the help cat_nod

loud silo
#

yep of course! juggling a couple of threads so it might take me a bit to get back to you

urban night
#

No worries, this is an oddball one too ๐Ÿ˜“

loud silo
#

ok, so i am a little confused as to why you would want to pass dummy errors into intentCreationCallback. what i would do is

  1. create the PaymentIntent and don't include confirm: true in the creation request. this will result in a PaymentIntent that you can modify later
  2. actually handle the error if you encounter it
  3. modify the PaymentIntent as much as you need to
  4. later separately call Confirm a PaymentIntent
urban night
#

The PI that I'm creating already is not being confirmed server-side, however, the intentCreationCallback confirms the PI (this is why you need to pass the client secret). If I pass an error here, confirmation doesn't happen, allowing me to confirm in another step.

customFlow Payment Sheets typically operate like this:

  1. Present Sheet
  2. Customer Enters PM details
  3. Customer clicks a buy/pay now/etc button that calls the confirmPaymentSheetPayment method
  4. That method creates the PM and then invokes the confirmHandler passed when init'ing the sheet
  5. The confirmHandler creates the PI and then needs to call the intentCreationCallback flow, which will confirm the PI

However, for step 5 I don't want it to confirm the PI, instead I need to display some info to the user and then call the normal confirmPayment method

loud silo
#

hmmm.

urban night
#

Actually, looking into it, Embedded Mobile Elements seems to have a similar issue hhupsidedown_cry

loud silo
urban night
#

Yeah, there's a chance that may work, but it'd be a bit weird in a flow intended to make direct payment.

On the web with Elements I'm able to create a PM (or confirmation token) and then create the PI before confirming.

On mobile it seems like I can't separate out that flow, I can only create a PI and confirm in the same step.

loud silo
#

i feel like there has to be a better way to do this but i am struggling to find it in the docs. give me a bit to test things out

urban night
#

Thank you, you are a saint ๐Ÿ™

#

I've been banging my head against the wall for a couple days on this lol

loud silo
#

intentionally throwing an error feels like a very strange way to handle this even if it works and i would not want to recommend it haha

#

although i respect your creativity

loud silo
#

ok, i am running into the limits of my react native knowledge here so give me a bit to consult with some colleagues

urban night
#

No worries, very much appreciated!!

loud silo
#

can you also elaborate on what you mean when you say "do junk to the PI"? what specifically are you doing between creating the payment intent and confirming it?

urban night
#

Surcharging ๐Ÿ™‚

loud silo
#

gotcha, so updating the amount specifically? based on details from the Payment Method?

urban night
#

The amount_surcharge field specifically ๐Ÿ™‚

#

But other than that, yes!

loud silo
#

ok cool. gimme a bit longer to dig

#

thank you for your patience ๐Ÿ™‚

urban night
#

Take your time, appreciate you digging in here YAY

loud silo
#

do you need to close the payment sheet in between when you collect payment details and when you confirm the payment intent?

urban night
#

In an ideal world, yes, and they'd be able to change the payment method as well.

Are you talking about displaying the updated details in another sheet?

#

๐Ÿค”

loud silo
#

i guess i'm mostly wondering what all you need to do in between when you create the PaymentMethod and you finalize all of the details you need for the final PaymentIntent. like, if you have enough information while the user is still in the Payment Sheet would it not be possible to create and update the PaymentIntent before returning the client secret and letting the callback handle confirmation?

urban night
#

Oh, gotcha.

Yeah, if it was possible after the details were filled out in the payment sheet to create the PI and update it, that'd be great.

#

I actually listen to the form being complete for the web version of this implementation and create a PM and then do the PI stuff

#

So, if that were possible here, that'd be perfect I think

#

I really just need to know the payment method information before confirming the intent and capturing payment--that's really it

loud silo
#

hmmmmmmm.

urban night
#

Also, at the point, it working with the Embedded Elements would also be great. That was my initial fallback and that isn't working either ๐Ÿ˜ญ

loud silo
#

i think part of my confusion here is that my team isn't really familiar with surcharging as it's still in preview. any chance you have a contact for this feature?

#

i am reading up on some of the specific requirements here and i am worried that it just isn't very well supported on mobile currently

#

but i think we might need to check more with the team who owns the feature to see if they have a recommended path here

urban night
#

Gotcha, yeah, I was hoping as it's more implementation specific and potentially agnostic to surcharging that we wouldn't need to do that ๐Ÿ˜ญ

loud silo
#

yeah, i think a part of the issue is that mobile's confirmation flows are a little different than web (as you have seen here)

#

so i think checking with them would probably be the best path forward

#

i think any of the recommendations i can make right now are going to be a little hacky at best and i don't really want to do that :/

edgy torrentBOT
urban night
#

That's fair, this is definitely a curveball! I appreciate the help.

loud silo
#

yep of course! best of luck, and thank you for your patience ๐Ÿ™‚

jaunty quail
#

Hi @urban night I'm taking over this thread. Let me know if you have any follow-up questions.

urban night
#

I think I'm good on my end unless you have any magic solutions to the above, haha

jaunty quail
urban night
#

Yeah, that's what I've been doing, the crux is that I need not confirm the PI in the second step and confirm later.

jaunty quail
#

If you use customflow, the payment confirmation happens on your UI and you can display info about the surcharge in your own UI before your customer clicks the confirm button

urban night
#

Correct, but I need to display information after the PI has been created and the PM has been attached to it, but before confirmation.

jaunty quail
#

I believe this is what the customFlow can help you to achieve. Can you share with me some screenshots to help me better understand your integration?

urban night
#

Kind of, custom flow is more so:

  1. Present Sheet
  2. Customer Enters PM details
  3. Customer clicks a buy/pay now/etc button that calls the confirmPaymentSheetPayment method
  4. That method creates the PM and then invokes the confirmHandler passed when init'ing the sheet
  5. The confirmHandler creates the PI and then needs to call the intentCreationCallback flow, which will confirm the PI

However, for step 5 I don't want it to confirm the PI, instead I need to display some info to the user and then call the normal confirmPayment method

#

I found out that I can not confirm the PI if I pass in a dummy error into the intentCreationCallback

#

But that feels wrong ๐Ÿ˜ญ