#nickhatter

1 messages ยท Page 1 of 1 (latest)

next roseBOT
primal ginkgo
#

Hi ๐Ÿ‘‹

onyx trench
#

Hello! ๐Ÿ™‚

primal ginkgo
#

Can you describe what API you are using?

onyx trench
#

using Stripe Connect - Express

#

with NodeJS

primal ginkgo
#

Okay but none of those are APIs specifically. What API are you using?

onyx trench
#

oh which endpoint

#

as far as I can see there's only return and refresh url

#

would be great if stripe could give some kind of flag or callback to indicate successful onboarding, or user cancelled, etc.

primal ginkgo
onyx trench
#

yeah I just saw that now

primal ginkgo
onyx trench
#

I guess I'll have to use that

#

developer request:

add optional:
cancel_url
success_url

#

๐Ÿ™Œ

#

would make express integration faster ๐Ÿ˜„

#

thanks for the tip @primal ginkgo !

primal ginkgo
#

But what is to stop a user from just dimissing the window/closing the browser?

#

IF they click a Cancel button they are returned to the return_url

onyx trench
#

yes

#

would be good if there was similar for cancel and success state

#

just giving feedback as a developer ๐Ÿ™‚

#

(and trying to minimise future work for your other dev clients - the less code we have to write to get it up and running, the better ๐Ÿ˜‰ )

#

thanks again

#

you could have cancel_url, pending_url, success_url, etc. ๐Ÿ™‚

#

return_url is a bit too broad, just my two cents

primal ginkgo
#

I can put in a feature request but, to me, I don't see a clear functionality this unlocks. It seems to rely on the user clicking a specific button and that just isn't reliable

onyx trench
#

it would be good to handle the states in an easy way... to me it makes sense. but that's just me!

#

eg. if user clicks cancel
a cancel page which says, "hey you need to complete Stripe onboarding before we can activate you account - try agan here"

#

a finishh/success page => "Thanks, your details have been submitted to Stripe. We'll let you know if anything else is required"

primal ginkgo
#

But what if they just close their browser

#

For reference this is a "cancel" behavior we see all the time

onyx trench
#

sure if they cancel that way, you obviously might have to handle that

#

but to me I dont see the problem or difficulty in adding additional urls to define 'return' better

#

anyway, I guess I'll have to add something which checks the stripe status on the return_url... and then aappropriately redirects either back to stripe, or to next step in onboarding

primal ginkgo
#

I've logged your feedback as a feature request

#

But, since malicious actors can manipulate the URLs provided on the client-side, I would always recommend retrieving the Account object and verifying the state of onboarding that way