On this page, you explain that "most sites do not provide the time stamp for a transaction". Yet, on the example output of getUserTransactions you do show field named postDate and transactionDate. What is the meaning of those fields?
Thanks!
transactionDate- This will return the date on which the transaction happened.
postDate- This will return the date on which the transaction was posted/reflected on the banking website.
For e.g., generally credit card transactions get posted on online banking site after 2-3 days of actual transaction execution.
Note:- This depends on the availability of these details on the bank websites.
On the other hand when Yodlee says -"most sites do not provide the time stamp for a transaction" this means sites do not provide actual timestamp(date + time) when any transaction got executed, while they provide the date.
Related
Say, data needs to be kept for 2years. Then all data that were created 2years + 1day ago should not be displayed and be deleted from the server. How do you manually test that?
I’m new to testing and I can’t think of any other ways. Also, we cannot do automation due to time constraints.
You can create the data with backdating of more than two years in the database and can test, if it is being deleted or not automatically, In other ways ,you can change the current business date from the database and can test it
For the data retention functionality a manual tester needs to remember the search data so that the tester can perform the test cases for the search retention feature.
By Taking an example of a social networking app , being a manual tester you need to remember all the users that you searched for recently.
To check the time period of retention you can take the help from the backend developer so that they can change the time period (from like one year to 10 min) for testing purpose.
Even if you delete the search history and then you start typing the already entered search result the related result should pop on the first location of the search result. Data retention policies concern what data should be stored or archived, where that should happen, and for exactly how long. Once the retention time period for a particular data set expires, it can be deleted or moved as historical data to secondary or tertiary storage, depending on the requirement
Let’s us understand with an example, that we have below data in our database table based on past search made by users. Now with the help of this table, you can perform this testing with minimum effort and optimum result. We have Current Date as - ‘2022-03-10’ and Status column states that data is available / not available in database, where Visible means available, while Expired means deleted from table.
Search Keyword
Search On Date
Search Expiry Date
Status
sport
2022-03-05
2024-03-04
Visible
cricket news
2020-03-10
2022-03-09
Expired - Deleted
holy books
2020-03-11
2022-03-10
Visible
dance
2020-03-12
2022-03-11
Visible
Yodlee seems to be returning running balance for each transaction returned in the API response but here i am facing an issue where i am not able to determine the correct order of transactions and hence the running balance displayed in my app does'nt make any sense because the transactions are not in correct order i.e. the order in which they happened # bank.
Is there any solution to this?
I will really appreciate a proper solutions or any work around for this issue
Note
I have already tried to sort by the id returned for each transaction but it results in incorrect order of transactions
The order can be determined by the transactionDate if returned , Yodlee does not know what order the transactions are nor does it store chronologically.
Its dependent on the end Site from where its scraped and most of the banks are missing the transaction Date .
I am looking for a way to get only 'new' transactions from specific account item. I.e. only transactions that was posted to account after I made previous transactions fetch/search.
For example I have the following scenario:
I have add item to consumer. Lets say consumer have 1 account item named 'BankAccount1'.
I fetch/search ALL transactions for some BankAccount1 and store transactions locally.
Now I need a way to get only new transactions on periodic basis. I.e. only transactions that was posted to 'BankAccount1' after previous fetch/search call. Is it possible to do this or I need to get all transactions every time and just skip transactions with Id which already present locally? If transaction Id is unique and incremental (did they?) maybe its possible to save last fetched transaction Id, and on next time get only transactions with Id > prevFetchId (what API to use if its possible)?
p.s.
I am using container based approach REST API.
As per your question, I can infer that you are going to store transactions locally in your DB. In that case Yodlee recommend to use Procedural Data Extracts, using which you can keep your DB in sync with Yodlee Cloud. You can find more details about it here.
Yodlee recommends you to pass date range in the executeUserSearchRequest API to get the transactions for any specific duration,as getting only new transactions may cause some issues. This is why Yodlee recommends to have few days of overlap, this will help you in not missing any transaction.
Transaction ID would be unique but it may not be incremental.
I have a MySQL table LOGIN_LOG with fields ID, PLAYER, TIMESTAMP and ACTION. ACTION can be either 'login' or 'logout'. Only around 20% of the logins have an accompanying logout row. For those that do, I want to calculate the average duration.
I'm thinking of something like
select avg(LL2.TIMESTAMP - LL1.TIMESTAMP)
from LOGIN_LOG LL1
inner join LOGIN_LOG LL2 on LL1.PLAYER = LL2.PLAYER and LL2.TIMESTAMP > LL1.TIMESTAMP
left join LOGIN_LOG LL3 on LL3.PLAYER = LL1.PLAYER
and LL3.TIMESTAMP between LL1.TIMESTAMP + 1 and LL2.TIMESTAMP - 1
and LL3.ACTION = 'login'
where LL1.ACTION = 'login' and LL2.ACTION = 'logout' and isnull(LL3.ID)
is this the best way to do it, or is there one more efficient?
Given the data you have, there probably isn't anything much faster you can do because you have to look at a LOGIN and a LOGOUT record, and ensure there is no other LOGIN (or LOGOUT?) record for the same user between the two.
Alternatively, find a way to ensure that a disconnect records a logout, so that the data is complete (instead of 20% complete). However, the query probably still has to ensure that the criteria are all met, so it won't help the query all that much.
If you can get the data into a format where the LOGIN and corresponding LOGOUT times are both in the same record, then you can simplify the query immensely. I'm not clear if the SessionManager does that for you.
Do you have a SessionManager type object that can timeout sessions? Because a timeout could be logged there, and you could get the last activity time from that and the timeout period.
Or you log all activity on the website/service, and thus you can query website/service visit duration directly, and see what activities they performed. For a website, Apache log analysers can probably generate the required stats.
I agree with JeeBee, but another advantage to a SessionManager type object is that you can handle the sessionEnd event and write a logout row with the active time in it. This way you would likely go from 20% accompanying logout rows to 100% accompanying logout rows. Querying for the activity time would then be trivial and consistent for all sessions.
If only 20% of your users actually log out, this search will not give you a very accurate time of each session. A better way to gauge how long an average user session is would be to take the average time between actions, or avg. time per page. This, then, can multiplied by the average number of pages/actions per visit to give a more accurate time.
Additionally, you can determine avg. time for each page, and then get your session end time = session time to that point + avg time spent on their last page. This will give you a much more fine-grained(and accurate) measure of time spent per session.
Regarding the given SQL, it seems to be more complicated than you really need. This sort of statistical operation can often be better handled/more maintainable in code external to the database where you can have the full power of whichever language you choose, and not just the rather convoluted abilities of SQL for statistical calculations
Say you've got a credit card number with an expiration date of 05/08 - i.e. May 2008.
Does that mean the card expires on the morning of the 1st of May 2008, or the night of the 31st of May 2008?
It took me a couple of minutes to find a site that I could source for this.
The card is valid until the last day of the month indicated, after the last [sic]1
day of the next month; the card cannot be used to make a purchase if the
merchant attempts to obtain an authorization.
- Source
Also, while looking this up, I found an interesting article on Microsoft's website using an example like this, exec summary: Access 2000 for a month/year defaults to the first day of the month, here's how to override that to calculate the end of the month like you'd want for a credit card.
Additionally, this page has everything you ever wanted to know about credit cards.
This is assumed to be a typo and that it should read "..., after the first day of the next month; ..."
If you are writing a site which takes credit card numbers for payment:
You should probably be as permissive as possible, so that if it does expire, you allow the credit card company to catch it. So, allow it until the last second of the last day of the month.
Don't write your own credit card processing code. If^H^HWhen you write a bug, someone will lose real money. We all make mistakes, just don't make decisions that turn your mistakes into catastrophes.
Have a look on one of your own credit cards. It'll have some text like EXPIRES END or VALID THRU above the date. So the card expires at the end of the given month.
In my experience, it has expired at the end of that month. That is based on the fact that I can use it during that month, and that month is when my bank sends a new one.
According to Visa's "Card Acceptance and Chargeback Management Guidelines for Visa Merchants"; "Good Thru" (or "Valid Thru") Date is the expiration date of the card:
A card is valid through the last day of the month shown, (e .g ., if
the Good Thru date is 03/12,the card is valid through March 31, 2012
and expires on April 1, 2012 .)
It is located below the embossed account number. If the current transaction date is after the "Good Thru" date, the card has expired.
I process a lot of credit card transaction at work, and I can tell you that the expiry date is inclusive.
Also, I agree with Gorgapor. Don't write your own processing code. They are some good tools out there for credit card processing. Here we have been using Monetra for 3 years and it does a pretty decent job at it.
lots of big companies dont even use your expiration date anymore because it causes auto-renewal of payments to be lost when cards are issued with new expiration dates and the same account number. This has been a huge problem in the service industry, so these companies have cornered the card issuers into processing payments w/o expiration dates to avoid this pitfall. Not many people know about this yet, so not all companies use this practice.
How do time zones factor in this analysis. Does a card expire in New York before California? Does it depend on the billing or shipping addresses?
I had a Automated Billing setup online and the credit card said it say good Thru 10/09, but the card was rejected the first week in October and again the next week. Each time it was rejected it cost me a $10 fee. Don't assume it good thru the end of the month if you have automatic billing setup.
In your example a credit card is expired on 6/2008.
Without knowing what you are doing I cannot say definitively you should not be validating ahead of time but be aware that sometimes business rules defy all logic.
For example, where I used to work they often did not process a card at all or would continue on transaction failure simply so they could contact the customer and get a different card.