In our application, there are occasionally cases where a bank account is disconnected using removeItem and subsequently reconnected using addItemForContentService1 from the Yodlee SOAP aggregation API. There is anecdotal evidence to suggest that, until relatively recently (1-2 months ago?), the transaction IDs for bank transactions that had already been retrieved from a prior connection would be identical when the same bank account was reconnected. However, now it appears that, when a bank account is disconnected and then reconnected in this way, all of the bank transactions are now assigned new transaction IDs, thus breaking any client logic that attempts to match transactions from previous connections to the same bank account. This can be a serious problem since, for example, it can produce many duplicate transactions for accounts that have already had bank reconciliations performed.
My questions are whether there now exists a reliable mechanism to identify the same bank transactions when disconnecting and reconnecting to the same bank account using removeItem and addItemForContentService1 and, if so, what is it?
When you call removeItem the account is deleted and also all the data related to that account is deleted. Now when you call addItemForContentService1 a new itemId is created for that account and data is freshly added to the data base considering the account as new. Since there is no mapping to the old data , so you will not get the same transaction IDs for those transactions.
Hence removeItem should only be called if you wish to delete the account and it's data from Yodlee platform.
Related
How do people deal with the situation of bounced checks when getting Yodlee transactions through the Aggregation API?
Our app only retrieves posted transactions and it has led to an issue.
Most banks seem to balance the bounced check situation by providing posted transactions for both the initial check disbursement (negative amount) and for the bounced check (positive amount). Bank of America, however only posts the positive amount transaction - (the one the increases the balance of the consumer's bank account) - the original transaction never gets past the pending stage. and since the original transaction (the check) is never posted it results in an incorrect increase in balance on the consumer side.
Any thoughts?
If you are customer of Yodlee, then you can reach out to Yodlee's support team and raise your issue with details like BankName, SiteId,memSiteAccId and cobrandId. Yodlee's data team will look into it and would be able to help you out.
I'm attempting to get transactions on an account previously added (more than a few days ago).
The account was added to a test account on our sandbox but the account is real.
I use executeUserSearchRequest to initiate the search, with the parameters shown in the image below (screenshot from PhpStorm, while debugging).
The result can also be seen on the screenshot.
Please note that I've also attempted fetching transactions for another account on a different financial institution (that was added to the customer account on Yodlee again several weeks ago). It also returns no results.
When both accounts were added, they were added using addItemForContentService1 with a parameter to refresh right after adding (startRefreshItemOnAddition=true).
What can be the reason for this 'no transactions' reply? (although we know that there were transactions on those accounts).
Thanks
As per the screenshot it seems like you are filtering the transactions based on the containerType= 'stocks', this will return transactions for all the investment accounts for that user.
Also, you are passing the itemAccountId.identifier which is for a specific account.
It would be great if you check followings:
The actual account aggregated is an investment account?
The itemAccountId is correct for that account?
Else, you can just remove the itemAccountId.identifier param as it is non-mandatory field and try. You should get some transactions in response.
Is there a way to get transactions for all container accounts that belong to a specific site aggregated using Yodle APIs?
For example, the American Express Cards (siteId: 12) have bank, credits, loans and etc enabled containers.
So, can we get the transactions for all enabled container accounts for a single site?
If you mean to ask this- "Is there a way to get transactions for all the accounts(all containers) belongs to a particular site?" Then.
Yodlee provides two ways to get the transactions.
Getting transactions for a specific account i.e., you need to provide itemAccountId for each account to get the transactions for the specific account using executeUserSearchRequest API.
Getting transactions for all the accounts i.e., you need not to provide itemAccountId for any of the particular account while provide rest of the input parameters to get transactions using executeUserSearchRequest but this will return you transactions for all the accounts. Using your example, it will give you transactions for all the container present under SiteID-12 as well as other sites added by the consumer. Though you can use the second approach to get the transactions for all accounts and then filter it out for all containers belongs to a specific site. You can use the sumInfoId(ContentServiceID) present in the response for each transaction.
Customers have started to find that the transaction description field provided by Yodlee is changing, without the original / older transaction being removed and a new one being created in it's place.
Our expectation up to now is that if any changes take place, the old transaction is deleted and a new one is created, with a new internal transaction_id used by Yodlee. This is the system that is used for moving pending transactions to posted.
Is it now standard practice that merchant descriptions change frequently within the same transaction ID, or is this being done in error? Should we open a service request for the problem to be resolved?
Yodlee scrapes transactions from the Bank websites in each refresh for a specific duration- 30days, so if there are few transactions which got scraped and filed into Yodlee DB in previous refresh and now Bank has updated the description of those transaction while keeping rest of the information same. And say those are coming in current refresh also, then Yodlee will apply its logic and will update the description without changing anything else. But the chances when Bank Website does this is very rare.
If you are facing this kind of issue repeatedly/frequently then we suggest you to open a service request, with all the relevant information.
Note: The above scenario is in the case of Posted Transactions only.
I have a subscription based website that interacts with a 3rd party system to handle the payments. The steps to process a new subscriber registration are as follow:
The subscriber enters his/her details in the subscription form and click on the submit button.
Assuming the details specified are valid, a new record is created in the database to store these details.
The subscriber is then redirected to the website of the 3rd party system (similar to paypal) to process the payment.
Once the payment is succesful, the 3rd party website then redirect the subscriber back to our website.
At this time, I know that the payment was succesful, so the record in the database is updated to indicate that payment has been made successfully.
A problem that I have found occurring quite often is that if a subscriber pays but does not complete the process correctly (e.g. uses the back browser, closes the window), his/her record in the database doesn't get updated about this. Accordingly, I don't know if s/he has paid by just looking the record and need to wait for the report from the 3rd party system to find this out.
How do you solve this problem?
PS. One of the main reasons to store their details into the database before the payment process is done is so they can come back to complete the payment without re-entering their details again. For example, when their credit cards were rejected by the 3rd party system and they need to sort this out with their financial institution which may take a while.
The third-party payment system should inform you of the successful transaction regardless of what the user does.
For example, in PayPal, an IPN (instant payment notification) is sent to your server as POST data to a URL that you specify. Your server then verifies with Paypal that the transaction is genuine, and if so, updates the database record to indicate the subscription is valid. At a point in the future, PayPal may or may not then redirect the user back to your website. (The "may not" can occur in cases such as the user closing their browser, hitting Back, or jumping to a new URL)
Note that this "conversation" between Paypal and your server is independent of the user's session - it is a "private conversation" between you and PayPal about that user's transaction.
Obviously there can be communications outages and server failures, so if Paypal does not get the validation request from your server immediately it will periodically send retries to your server to ensure that the transaction is eventually completed.
If your payment system doesn't have at least some basic mechanism for ensuring transaction reliability, then choose a different provider. Chances are that they do, but you will have to implement things correctly on your server to be sure that the system works properly.
P.S. It is quite normal to require a user to log in (and thus be registered in the database) before they initiate any financial transaction. You need to gather all the relevant information before they go to purchase, as after the purchase you have no way of guaranteeing that they will return to you to provide any further information.