#adamb-connect-express
mental elbow
- That someone can show up to my site and sign up from scratch
- that they have limited privileges until they sign up for a stripe express account
- that they have full privileges once stripe verifies their express account
- that someone else can show up and pay for their product
- that stripe payments work and all the amounts are right
cedar pendant
And have you looked through this resource yet?
mental elbow
yes, i had initially implemented the tests using this doc + puppeteer
but now there's a captcha in the signup flow
so it seems like there's a different way i'm supposed to be implementing tests
cedar pendant
- That someone can show up to my site and sign up from scratch
The problem with this one is that Express has a Stripe-hosted onboarding workflow, so you can't really automate this test. You can only test if the customer is redirected to Stripe and back to your integration properly- that they have limited privileges until they sign up for a stripe express account
This can be tested by attempting to create charges and payouts on restricted and unrestricted accounts, so this might be time-consuming to code, but shouldn't be too hard to implement.- that they have full privileges once stripe verifies their express account
Same as #2- that someone else can show up and pay for their product
This will depend on what products are being used to charge the customers (e.g; are they using Checkout? Invoices? Payment Intents? Subscriptions? etc.)"- that stripe payments work and all the amounts are right
Depends on #4
mental elbow
re: 1) You can only test if the customer is redirected to Stripe and back to your integration properly
how does that work? is it possible to skip the need for UI interaction altogether and go from initial stripe URL to an immediate redirect back to my page?
2-5) above sound like good unit tests. but i'm implementing a single end to end test that does 1-5
cedar pendant
> re: 1) You can only test if the customer is redirected to Stripe and back to y...
No, it requires manual intervention unfortunately. If you wanted to fully automate the onboarding process using Custom Connect, then more testing would be possible, but since most of Express is done on the Stripe side with manual user intervention, automating the onboarding itself is not really necessary
mental elbow
i need to automate things to actually test all the possible verified/not verified/slow verification/etc states
bday * address * id number is already 18 different states
cedar pendant
That's a fairly complex space. You can view all the requirements on an account by country here: https://stripe.com/docs/connect/required-verification-information
Additionally, you need to be explicit about what you're testing for on each of the Connect requirements. Are you testing to see if the payouts are paused on the account? Charges paused? Address verified? Address unverified? etc. etc.
Once you have that, you might find the requirements hash to be helpful, as it will indicate what still needs to be verified on the account: https://stripe.com/docs/api/accounts/object#account_object-requirements
mental elbow
i'm testing the end to end experience for my users
thanks for pointing out it varies on a country-by-country basis
i don't specifically care about address verified or not, just whether or not credit cards and payouts work
manual testing isn't really an option here
https://stripe.com/docs/connect/testing-verification this document makes it seem like test automation should work for express accounts, but it's not very clear about that
sometimes it says "custom accounts" other times it says "express and custom accounts"
mental elbow
look in the "ACCOUNT TYPES" note on the side
cedar pendant
But I see that the box on the side says Express too, so that's confusing
Yeah, I just saw that. Odd place to put it
mental elbow
on the previous page it says the same when linking:
TESTING VERIFICATION GUIDE
Because verification is a crucial component for platforms with Express and Custom accounts, we’ve created a dedicated guide to testing verification.
seems like 2 votes for "Express and Custom accounts", 1 vote for only "Custom accounts"
sorry, "previous page" is https://stripe.com/docs/connect/testing
(thanks for helping me make sense of this)
cedar pendant
Most (if not all) of the verifications states that happen for Custom accounts, can also happen for Express, so (now that I think about it) it should be possible to at least set up your integration to test whether or not your integration is successfully "monitoring" the requirements.
mental elbow
ok, so it sounds like i might be able to use custom accounts to test some of the integration dynamics
but not the stripe link opening + redirection flow
what i'd really like is to be able to grab the express account id from the page that's opened and then (if i'm not supposed to be automating it via puppeteer)
... use the apis in this document to test the verification flows against that express account
cedar pendant
ok, so it sounds like i might be able to use custom accounts to test some of the...
Sort of. You would essentially be using the Custom Connect guide to test your Express account states
what i'd really like is to be able to grab the express account id from the page that's opened and then (if i'm not supposed to be automating it via puppeteer)
and then use the apis in this document to test the verification flows against that express account
That seems like a reasonable way to go
Are you blocked on any of that? Or is it just a matter of getting started now?
mental elbow
well all of this used to work
fully implemented via puppeteer driving the stripe express flow
and running these tests was a part of my release process
but then a recent update to stripe connect seems to have added a captcha to testmode
which means i need to reimplement this part of the tests
thus my question about what these docs mean and what's "supposed to" work
cedar pendant
Yeahhhh, that's unfortunate. Necessary, but still unfortunate. I don't think there's a way around the CAPTCHA, so I'm just trying to help conceive of a way to do this without puppeteer
mental elbow
lol i was really proud of those puppeteer tests
cedar pendant
And the route you're on seems correct. Testing the account states this way is probably more helpful, as anything that breaks in the Express onboarding flow would immediately get rolled back and fixed
mental elbow
a great little movie of what the first user experience for the critical business flow was
cedar pendant
I don't blame you. That's a really cool way to test stuff that I didn't even know about until today
mental elbow
i understand the logic of the captcha, i have the same tension for my own product
the easier it is to automate my tests, the easier it is for bots
so my big question here is how to get an express account id from that initial stripe express page without dealing w captcha
cedar pendant
so my big question here is how to get an express account id from that initial stripe express page without dealing w captcha
You would likely have to listen for theaccount.updatedwebhook and retrieve it from there, or simply create the Express account via the API and get it from the returned response: https://stripe.com/docs/api/events/types#event_types-account.updated
mental elbow
i would imagine that the webhook flow is gated by the captcha though, no?
and creating the express account directly doesn't let me check that the onboarding flow / redirect logic actually works
that feels like a pretty big gap to leave untested
cedar pendant
I mean, the event of creating the account is a simple API call and doesn't require engaging with the Express onboarding page, so you could get the ID from the account creation, then use it later for other tests
Testing the redirect to the onboarding page should be possible, but testing when the customer leaves the page and gets redirected back to your website would require some manual intervention
mental elbow
right but the redirect flow is pretty key to the whole thing from a user perspective
i keep feeling like i'm missing something
like there's no way that stripe just doesn't have a way to write tests for these integrations
and automated end to end tests feel like table stakes for handling $ on behalf of real people
inner lake
Hey two-shoes had to leave and I am catching up to this thread now. Will be back to help shortly...
Still thinking on this one, this is a tough. We typically recommend against end-to-end testing with pupeteer. When you are at the point of interacting with our real webpages with real CAPTHCAS, it is usually better to mock out the Stripe component of this, as in have some component swapped out in place of real stripe to give your code a fixed response instead of actually calling our API and going through the process.
That can be a tall order but we do at least have a pre-built tool for mock API responses if that helps https://github.com/stripe/stripe-mock
I'm trying to see if we have anything else on this, I am less familiar with this testing path but I do keep hearing of it as saving a lot of headaches.
mental elbow
stripe-mock doesn't actually implement all of the stripe-connect api though
it seems like the recommendation against end-to-end testing is well-meaning but bad for the end user
integration testing / end-to-end testing is the best way to guarantee a given end user experience works
i'm kind of shocked that stripe connect has made it to GA without support for automated integration tests
inner lake
That feedback is noted, though from what I understand this is a typical pattern when testing external APIs/webpages. Like here our Express page kind of should be a black box that from your backend's perspective where you link the user to and see the results. So to test this all you need are the responses that it gets after the user completes the form. We extensively end-to-end test our page and make sure it consistently returns the same thing to you when details are filled out, but we can always change UI things and whatnot that might break your test.
Are there specific things that you think mocking out can't test here other than the actual flow of the onboarding page?
mental elbow
The issue here is how stateful the integration is. There are lots of ways for things to break from an API contract standpoint and from an implementation standpoint.
It's absolutely critical that all of these work perfectly with each other:
- initial url parameters
- final redirect url
- webhook endpoint configuration
- webhook backend implementation
- handling of various sequences of express account verification states
- credit card processing via stripe elements
- payouts work
I think part of the problem here is that from stripe's perspective "end to end" testing seems unnecessary, since stripe has made a business commitment to providing a quality experience for that entire flow
but what's "end to end" on stripe's side
is actually just part of the middle of my tests
so as a simple example, i need to know that the query parameters i give to stripe express onboarding will eventually result in the ability for a credit card charge to work in a stripe elements input control
this is an excerpt from the stripe-mock readme:
Limitations:
It's currently stateless. Data created with POST calls won't be stored so that the same information is available later.
For polymorphic endpoints (say one that returns either a card or a bank account), only a single resource type is ever returned. There's no way to specify which one that is.
It's locked to the latest version of Stripe's API and doesn't support old versions.
Testing for specific responses and errors is currently not supported. It will return a success response instead of the desired error response.
it doesn't look like stripe-mock has any support for stripe connect
I would be happy to use stripe express as a black box in my tests. How do I do that? I'd be fine if I could start with a URL and end up with the browser being redirected as if everything has already been filled in
covert hare
👋 Pompey had to step away
Catching up on the thread, (its a complex one for sure)
would you mind giving me a short summary of what you need help with?
mental elbow
sure, thanks
i have integration tests that cover stripe connect onboarding/webhook updates/credit card processing
they used to work, but now they don't because the stripe connect team added a captcha to testmode
so i'm trying to figure out the "right" way to unblock my deploy tests and maintain test coverage of this complex integration
mental elbow
I would be happy to use stripe express as a black box in my tests. How do I do t...
seems like this might be a way
mental elbow
so my big question here is how to get an express account id from that initial st...
... or this might also be a way
covert hare
hm okay, thinking...
so all you need is an express connected account ID to get started with the testing right?
mental elbow
i need a fresh express connected account id that starts out completely unverified and ends up in some terminal state (denied, partially verified, verified)
and i need it to have the same capabilities as set by the express onboarding url
covert hare
i need a fresh express connected account id that starts out completely unverified
Can't you just use the API to spin up a new express account in test mode?
mental elbow
and creating the express account directly doesn't let me check that the onboardi...
i could, but this wouldn't actually test the stripe connect integration itself
doesn't test capabilities, the stripe url they're being sent to, or the resulting redirect target
before the addition of this captcha, my tests just clicked the "configure stripe express account" button in our dashboard and then filled out info until they were back at our dashboard and then waited for the account status to be updated on the dashboard
covert hare
As far as I know, currently there isn't an API endpoint that would do all of it in one call.
when you say
doesn't test capabilities
capabilities as in how? by creating charge?
the stripe url they're being sent to
do you mean the onboarding URL (AccountLink)?
or the resulting redirect target
I'm assuming this is after the onboarding is complete?
before the addition of this captcha, my tests just clicked the "configure stripe express account" button in our dashboard and then filled out info until they were back at our dashboard and then waited for the account status to be updated on the dashboard
I see
mental elbow
As far as I know, currently there isn't an API endpoint that would do all of it ...
right now i add a bunch of query parameters to https://dashboard.stripe.com/oauth/authorize?
some of these parameters are: suggested_capabilities, redirect_uri, email
it seems that creating an express account programmatically would not test that these values are correctly passed?
covert hare
Oh, okay so you're using Oauth flow
https://stripe.com/docs/connect/oauth-express-accounts
covert hare
Yeah recommended approach is
https://stripe.com/docs/connect/express-accounts
mental elbow
well this puts me in a tough spot
because this code was passing integration tests
now those tests don't work because of the captcha
covert hare
it seems that this flow has been deprecated?
its not deprecated but is considered legacy