#pete-ios-ideal

1 messages · Page 1 of 1 (latest)

vast lodgeBOT
#

pete0587

jolly wave
#

Hi, we're taking a look at this.

#

Yes it should work. The flow would look like this: iOS app -> Stripe hosted URL -> Bank app -> Stripe hosted URL -> iOS app I'm still discussing this with my teammates

#

I'll share an update as soon as I can

polar igloo
#

@next condor sorry there are dozens of ways to integrate Stripe. Can you give a lot more specific details about your overall integration and what you're using?

next condor
#

Sure thing. Here are the basic steps we take to initiate an iDEAL payment:

  1. Create an iDEAL payment method payment_methods
  2. Call to our backend to create an iDEAL payment_intent
  3. Call payment_intents/<payment_intent_id>/confirm to confirm the payment intent
    • we specify a return_url at this point with a scheme our app recognizes
  4. The confirmed intent returns a redirect URL
  5. We open this redirect URL in a webview. For iDEAL this is a webview for the users bank
  6. In this webview, the user is allowed to link out to their banking app.
  7. At this point I'm a little unclear what happens, and so my question. I assume once the user authorizes payment, they are linked back to our app via the return_url specified in step (3), but wasn't sure and this is hard to test in our staging environment
polar igloo
#

Curious why you are doing something so much more complex than just using PaymentSheet and letting us do all this?

#

pete-ios-ideal

next condor
#

I think this is primarily because we don't integrate the StripeSDK and use only the APIs

polar igloo
#

then universal link should work

next condor
polar igloo
#

yes it should be. It's just only possible to verify in production sadly

next condor
#

I've notices in test environments that data is appended to the return_url , specifically payment_intent and payment_intent_client_secret Are these values sensitive in nature and should they be treated as such? Is there a risk if this data is leaked?