Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom user with inflow_model doesn't work #7

Open
cristian-moreno-ruiz opened this issue Apr 28, 2023 · 4 comments
Open

Custom user with inflow_model doesn't work #7

cristian-moreno-ruiz opened this issue Apr 28, 2023 · 4 comments

Comments

@cristian-moreno-ruiz
Copy link

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
Copy link
Collaborator

phoenixy1 commented Apr 28, 2023

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants