Seed Test Data - Connect

Sandboxes
1

This may fit better into, this , or maybe a different topic all together, but haven’t seen a Connect specific topic yet, so starting a new topic.

Our use case calls for around 150-200 connect accounts at any given time. The creation of connected accounts in sandbox (eg. creating an account number) is no issue, but since we use separate charges and transfers, its quite cumbersome to complete the onboarding process, in order to enable the transfers and payouts capabilities for 200 connect accounts, even with all the great connect test fixtures you have.

Just wondering how connect accounts fit into the sandbox picture, and if there are any plans to include them in some capacity in future seeding functionality?

Thanks!

2

Hi Mike! Thanks for your question about seeding connected accounts. I saw that you also posted in the Templates topic.

We definitely understand that getting multiple connected accounts into specific states can be a bit of cumbersome process, and we’re exploring some ways we can make this better either with Templates or a separate way to help you seed those accounts.

What kinds of controls would you be interested in when setting up those connected accounts? Sounds like easy ways to complete KYC and enable specific capabilities would be a good start. Anything else that would be helpful?

3

Hey Nilo -

I spoke with the team, the consensus was the following:

curl https://api.stripe.com/v1/accounts \
  -d country=US \
  -d "controller[losses][payments]"=application \
  -d "controller[fees][payer]"=application \
  -d "controller[stripe_dashboard][type]"=none \
  -d "controller[requirement_collection]"=application \
  -d business_type=company \
  -d external_account=btok_us \
  -d "tos_acceptance[date]"=1547923073 \
  -d "tos_acceptance[ip]"="172.18.80.19"
  -d "business_profile[mcc]"=5045 \
  -d "company[address][city]"=Schenectady \
  -d "company[address][line1]"="123 State St" \
  -d "company[address][postal_code]"=12345 \
  -d "company[address][state]"=NY \
  -d "company[tax_id]"=000000000 \
  -d "company[phone]"=8888675309 \

  <!-- Controllable properties --> 
  -> "controller[id]"=<controllable> \
  -d "company[name]"=<controllable> \
  -d "capabilities[card_payments][requested]"=<controllable> \
  -d "capabilities[transfers][requested]"=<controllable> \

The connected account id being the same was the overwhelming choice for what they wanted to be able to control (in the curl, its a made up property called controller[id], which represents some account id that exists in the production account). And the other four properties were the runner ups.

Thanks!

2 Likes
4

Thanks for this example Mike! Super helpful as we think through potential solutions.