External Account should support an object

[sinakarimi]

When creating an account, the external_account property currently has the following spec:

"external_account": {
 "description": "A card or bank account to attach to the account. You can provide either a token, like the ones returned by [Stripe.js](https://stripe.com/docs/stripe.js), or a dictionary, as documented in the `external_account` parameter for [bank account](https://stripe.com/docs/api#account_create_bank_account) creation. <br><br>By default, providing an external account sets it as the new default external account for its currency, and deletes the old default if one exists. To add additional external accounts without replacing the existing default for the currency, use the bank account or card creation API.",
 "maxLength": 5000,
 "type": "string",
 "x-stripeBypassValidation": true
},

The description says, You can provide either a token, like the ones returned by [Stripe.js](https://stripe.com/docs/stripe.js), or a dictionary however the type does not reflect this. I encountered this issue when using the stripe-mock server and attempting to post an object as the external_account parameter.

[brandur-stripe]

Thanks for the report.

@tmaxwell-stripe I notice that this parameter is marked with x-stripeBypassValidation — in your opinion, do you think that I should modify stripe-mock to also pass through on validation when it sees one of these parameters? Obviously not the most ideal solution, but I assume that some of these old/complex parameters would be better detailed by now if it were more tractable.

[richardm-stripe]

The omission here is by design. Essentially, we strongly discourage passing raw details here. For most use cases, the user should create a token client-side and pass that instead.

If you really do need to handle raw details on your server, you can use // @ts-ignore or as any to suppress the Typescript error.

Sorry if this is extra friction for you. Because raw payment details are so sensitive, we want to do as much as we can to prevent users who don't absolutely need to from unwittingly handling them directly.