I'm working on a startup and we plan to use Plaid API or Yodlee for banking data aggregation ie credit history and previous transactions. I wanted to know about the data policy of these services from a fellow programmer who has worked on it. The sales guys give a pretty garbled view.
My questions are mainly
If one of my users had previously given their data to these
aggregators (ie maybe used Yodlee for mint) do they have to put in
each of their bank login details again if they use my service or do
they have a sort of user profile with which they can authorize my
app to view the data stored in their service.
Does Plaid API/Yodlee use the data I generate for its own uses and
do my users owe these data to these services and not me?
If I want to move out do they still hold my users data (the bank
accounts they have signed up with)as a profile on their desk?
PS: I think this question follows SO's policy but feel free to correct me if not.
Related
We are working on a system which retrieves data from customers' Shopify shops and provides some services based on this data. In order to make it as convenient as possible for an end-user we would like to update this data on a daily\weekly\monthly basis.
For now we only came up with a solution of implementing unlisted app, prompt a user to provide all necessary permissions for the app to access their shops and fetch the data. But the token we get doesn't seem to be valid for a long time and we probably won't be able to reuse it a day later.
We appreciate it if you can share any success cases of implementing this kind of approach.
You provide an App to the merchant they can install using oAuth. When the merchant is prompted to approve the App, Shopify will then provide your App with a long-lived access token you can use as much as you want, for as long as you want. I use a custom App from my Partner App dashboard to create these kinds of one-off Apps. It is superior to the one where the merchant has to tick off scopes and permissions IMO.
There are two kinds of token you can ask for and receive. One is considered for offline access, or long-lived. It works for everything. It is for webhooks as an example, or other access where no person is involved. But, there is also, online access tokens! Say a person clicks into the App from Shopify to do some work. You can request an online token for them to do their thing, and that token is only good for say 24 hours.
So you have options!
What is the right procedure for pulling data about a customer (using OAuth to "Connect with Paypal" similar to the functionality that Stripe and Square provide) from Paypal?
The paypal documentation is confusing in two ways -
The OAuth scopes shown only have basic profile information like email, address, name, etc. and the link to the attributes page in the Account Information line item seems broken.
Other places mention that you have to sign onto the Paypal partner program to pull data on behalf of third parties.
So, for anyone that has gone through this - what is the right way to proceed/do I have to sign up to Paypal partner program? Is Permissions the right API to use?
I know broadly that connecting and fetching paypal account data is possible since, for example, Kabbage allows you to link your Paypal account and pulls data from it directly.
Connect with PayPal is so a user can click the CwPP button, sign into PayPal agreeing to give you access to certain profile information (based on the selected scopes) -- and then once they grant that permission and return, you're able to use the provided authorization code to access their profile information with its API.
In order to use CwPP in the live environment, your CwPP app has to be approved. You don't need to be in the PayPal partner program for this.
I am required to create an application which collects transaction details of bank accounts, there are APIs like
Plaid
Yodlee
Geezeo
But these APIs make use of the clients username and password for retrieving the transaction data, but in my case I need to do so using only the credit card number.
Can it even be done?
Is there any other APIs that provide this functionality?
I have researched about this issue a lot but still can't seem to find any APIs that suits the requirement. Any help is appreciated, Thank you.
I just answered essentially this question for another user (Serizawa Sanjay), here is my response below:
"
I have worked for Credit Unions that have experience with all these types of APIs. The Geezeo and the Yodlee API will not allow you to do what you want since that would violate the privacy on the card and the card issuers will not allow someone outside of the flow of approvals to get to that data. There are a few APIs that you can get by working with partners like FirstData to look for a certain type of transaction or vendor that comes across their system if it matches a certain card number, but you have to be a key partner with FirstData, not an easy task.
As far as aggregating transaction data from accounts like credit cards, bank accounts, auto loans, mortgages, investment accounts and the like, you really want to be using an API like MoneyDesktop. Yodlee is good as well, it just does not have the coverage, uptime, or quality of data that MoneyDesktop has. Geezeo's API just does not have the critical features that a MoneyDesktop or Yodlee API has. First Geezeo does not do its own aggregation and it only has one partner to do their agg for them. Yodlee is only one source, but if there is a broken connection, at least they can control fixing it. If a connection goes down with Geezeo, there is nothing that Geezeo can do to fix it but wait for their aggregation provider to fix it. If your business, bank or credit union can't afford for aggregation to go down (reputation risk), you need someone like Yodlee that controls their own aggregation, or someone like MoneyDesktop that has many aggregation providers and can route between them the second that one of their connections has problems. Also, Yodlee and MoneyDesktop both do their own data cleansing and aggregation, where Geezeo does not and has to rely on their aggregation provider. This is extremely problematic because as users editing and input to the system as to the transaction being data cleansed incorrectly or categorized incorrectly is not taken into account properly or optimally.
I have also heard that Intuit Data Services has a good API as well, but I have never had any experience with it.
Good luck!
"
A client I work with wants to know if it's possible to use the Yodlee API to look up recent transactions on any credit card.
They'd like it to work without the user needing to be signed up with Yodlee, either directly at the site, or indirectly through a branded partner.
I assume this would be possible if the credit card company itself shared it's transaction data with Yodlee directly, and made it available to their API customers, but I haven't been able to figure this out from the docs available on their website, and haven't been able to reach anyone at Yodlee themselves to ask.
I work for Yodlee. Sorry to hear you're having a hard time getting a hold of us. To answer your question, yes the user has to explicitly authorize any application that leverages the Yodlee API and explicitly add access to their financial accounts for that application.
Best,
Grace
Yodlee screenscrapes websites to retrieve it's information.
Which means that they physically (but in an automated fashion) visit the website in a browser (IE8). Thus to pull any information down they have to visit the website, log in successfully, (optionally but more so on more banks; authenticate the computer) and then they can see all of the information that the user sees. Their API acts as a real time bridge between you (the end user using your website or app) and this browser.
So you have to either implement their very much so convoluted Yodlee API or use one of their generic hosted pages and direct the user to it where upon he/she enters the necessary information. You also have to have an agreement with them too. You also have to convince the user to do it :)
I like to build a system that will allow users to "commit buy" a deal, but will only be charged after a minimum # of committers are reached. The time span in which the "deal" will continue can be either weekly or monthly.
I like to stay away from building one from the ground up as much as possible.
I know there's another thread on StackOverflow that asked paypal, amazon, or google checkout API to serve this purpose, but this seems too much like a hack?
I did some reading on using a gateway like Authorize.net to process credit card information and they can store the user information and has a service like pay-as-you-go. Would using their API be a better choice? Can their pay-as-you-go method provide the system that I'm looking for?
I did some reading on using a gateway like Authorize.net to process
credit card information and they can store the user information and
has a service like pay-as-you-go. Would using their API be a better
choice?
I have used Authorize.net for recurring payments and it is easy to implement if you are fluent in working with a web service (regardless of language). You can integrate with them without the user needing to leave your website and without storing the user's credit card information.
However, you will be receiving the user's credit card number to implement such a model, and there are still precautions to be taken (versus redirecting to a secure third party site to receive the number).
Refine your question to be more specific to receive more specific answers.