Hi all,
in our integration scenario with Stuart, we handle orders on behalf of registered Stuart users. This means that, on our software back-end, our customers input their API keys and we then handle job creation/order tracking/etc. on their behalf.
When one of our customers sets up their account, we take the API keys and perform a set of operations (among which, registering the needed webhooks) so we know that the keys are valid and work.
However, we currently have no way to know whether the user has setup their billing information correctly, i.e., whether creating a job would generate the CREDIT_CARD_NOT_FOUND error or not.
It would be nice to have an additional API that allows us to query whether the account is OK to go and ready to create jobs or not.
At the moment, we use a workaround, creating a fake job as soon as the user registers their information and canceling it right away. If the job goes through correctly, we assume that the account is OK.
Do you see any issues with this?
Thank you very much!
Hello @LorenzCK,
Thank you for your message, we will share your feedback with our Product teams who are actively working on improving our account setup processes via API.
In the meantime, the approach you mention seems reasonable.
For your visibility, the billing configuration is currently set up in the Client’s dashboard where they also access the API credentials. Hence I believe it could be part of the process that they confirm they have set up those details when they provide you with the API credentials.
1 Like
Thank you very much @Lauren.
The information is in fact readily available through the dashboard, but in our scenario, when handling any number of accounts on behalf of others, it can be helpful to provide more information about the setup process before an order fails to go through. Especially because many users may not be aware of issues with the Stuart billing setup, credit cards might not be valid anymore, and so on… and credit card errors in this case show up when the business is open and deliveries must be performed. Bad timing usually. 
Hi @LorenzCK,
I see the dilemma indeed, thank you for your clear depiction of the issue which will help our teams ensure this case is accounted for in related features coming in the future.