zlacker

[parent] [thread] 1 comments
1. mtlync+(OP)[view] [source] 2020-04-22 00:34:33
That was another solution I considered. I think that would work, but it seemed expensive to implement. I believe it would still require me to host a separate copy of my app or a standalone app that handles just payments. Stripe also creates its own child iframe for displaying payment UI, so at that point, my app would look like:

  Main app
    My sandboxed iframe
      Stripe's iframe
So managing all the bubbling up and down of messages felt like it was going to be complicated. Limiting Stripe to a single page and forcing the new HTTP requests to unload it is a bit hackier, but is really simple to implement. You can see it in the blog post - I only had to add ~5 lines of extra code to my app to make it work.
replies(1): >>somish+Sx
2. somish+Sx[view] [source] 2020-04-22 06:48:39
>>mtlync+(OP)
My problem is primarily that I'm working with SPAs where a refresh really lowers the game.

I put together a proof-of-concept using a 'same-domain frame', no secondary domains or apps. The idea is separation over security, so you can unload without any side hustle. Tho without a second domain you're relying on Stripe being as trustworthy as they are, and not looking to actively undermine your sandboxing attempts [which I think is ok - we embedded their library in the first place].

https://codepen.io/theprojectsomething/full/ExVNEoZ

[go to top]