plaid / sandbox-custom-users

JSON files specifying custom users suitable for testing Plaid integrations on Sandbox
MIT License
21 stars 26 forks source link

Custom user with `inflow_model` doesn't work #7

Open cristian-moreno-ruiz opened 1 year ago

cristian-moreno-ruiz commented 1 year ago

I'm trying to create a realistic user with a checking account where they would be payed by their employer. I've put together a reasonable configuration with a checking account and some transactions, but as soon as I add the inflow_model object, it stops working, and the fetched accounts stop being the ones I've specified (I get the typical Plaid Savings and Plaid Checking default from user_good).

This is the object I'm using as inflow model:

"inflow_model": {
        "type": "monthly-income",
        "income_amount": 2323.45,
        "payment_day_of_month": 25,
        "transaction_name": "Some company Ltd. Payroll"
      }

I've tried the example on this repo an it is not working either.

Thanks in advance for your help!

phoenixy1 commented 1 year ago

Hi, I wasn't able to reproduce this issue, -- the inflow_model example from this repo worked fine for me when I tried it.

However, just as a guess, one thing you might want to try is making sure that you're updating the dates on the transactions, especially if you're using the custom user object files in the repo. For example, the dates on the transactions in this repo are from 2020, so adding an inflow model that generates monthly transactions is going to push them out to a much, much, later page of results (if they even get returned at all...they might not be if Sandbox is faithfully following Plaid's 2 year limit on transaction history) when calling /transactions/sync or /transactions/get, unless you update them to be more recent.

If that's not the issue, maybe you could share your entire custom user config file?

cristian-moreno-ruiz commented 1 year ago

Hi Alex, thanks for your quick response. I've tried again with the config provided in this repo, just removing the past transactions to simplify, since I'm not interested on them, just the inflow model. Also, I tweaked the original balance, to help me confirm the proper account was chosen within Link. This is the final config I've used:

{
   "override_accounts":[
      {
         "type":"depository",
         "subtype":"checking",
         "starting_balance": 5000,
         "identity":{
            "names":[
               "John Smith"
            ],
            "addresses":[
               {
                  "data":{
                     "city":"New York",
                     "country":"US",
                     "postal_code":"10003",
                     "region":"NY",
                     "street":"10003 Broadway Road"
                  },
                  "primary":true
               }
            ]
         },
         "inflow_model":{
            "type":"monthly-income",
            "income_amount":5125.25,
            "payment_day_of_month":1,
            "transaction_name":"DIRECT DEPOSIT PLAID INC"
         },
         "transactions":[]
      }
   ]
}

Just in case I've done something wrong when creating the user, here is a screenshot of my plaid dashboard sandbox user edited:

image

Then I use it to login using Link, maybe worth mentioning I'm using European connections for now, as we haven't enabled US: image

I've tried several countries, this specific one is Germany. At this point it looks like it's gonna work see the name of the account, is not the usual Plaid Checking from user_good:

image

However, final Plaid link shows this account, which already suggests, that the custom config wasn't applied: image

Let me know if I can provide any other relevant detail, and thanks again for your help!

phoenixy1 commented 1 year ago

Thank you for the detailed report! That is really interesting. It looks like this behavior is only happening for institutions that use an OAuth flow, which is why I couldn't reproduce it earlier.

I've reported this to the engineering team, but in the meantime if you guys are planning on enabling US at some point, the easiest workaround might be to test using US institutions, since non-OAuth-using US institutions don't seem to be affected by this.

cristian-moreno-ruiz commented 1 year ago

Makes sense, we'll do that in the meantime, thanks.