I have read this article
Please explain the refresh process that yodlee employs..
We understand this happens within a 19 hour window, is there anyway to stop the automatic refresh (the initial refresh on a Site based AddAccount1 is fine) - so that the subsequent refreshes can be manually controlled.
Thanks
The automatic refresh can be turned off for any client by Yodlee. You can contact the customer care team by logging a service request through YCC(Yodlee customer care ) tool and they will help you with that.
Related
We are using the API to submit a form after a user signs a document, we add the integrator key and have performed 20+ transactions without errors. However, we continually fail.
We have submitted over 20 forms.
Awaiting approval.
In general, it's best to reach out to go-live#docusign.com to request assistance with the API Review process. When you reach out, please include your integration key, your Demo account ID and your Production account ID.
The Go Live Troubleshooting Guide may help you investigate your cause of failure.
I requested one tap signup/signin for website API as documented in https://developers.google.com/identity/one-tap/web/
However, there has been no update or hear an update from them for more than a week. Does anybody know how long it usually takes to get the request reviewed?
Thanks
I got mail back from them after around 3 weeks of submitting the form.
They said currently you won't be granted access to API. However, they are in the process of including some additional security from their side and it may take a few months. We can hope to get API access then.
I have implemented one application to automatically get transactions back for all my customers' accounts from Yodlee at 3 AM EST every day. It kept working for more than 7 months. But it failed on this Monday and Tuesday. When I restarted the application manually in the morning after 9 am, it worked without issues.
Is there any maintenance going at night at Yodlee side recently?
Thanks.
If you are already a customer then please use Yodlee Customer Care tool for raising a Service Request else you can please fill out the form mentioned here to provide the details like siteAccountId & REST URL you are using for us to debug further.
Yodlee do notify its clients beforehand, if there will be a maintenance activity scheduled.
Our site uses Facebook connect. When a new user signs up we ask for permission to pull their interest data, their list of friends, and their friends' interests. Fetching this data used to be a very quick process (couple seconds). Over the last week or so, the time to fetch this data has increase to 10+ seconds. According to Facebook insights, our site is not being throttled. We didn't make any changes to our site.
Anyone else experiencing this issue with Facebook? Have any ideas for how to address it?
Thanks!
As of 1/26 at 7:55 PM EST, the live status page doesn't indicate any irregular activity.
Sometimes this occurs because a user simply has a lot of likes and interests. I would recommend making this operation asynchronous following a flow something like this:
User connects with your app
Get the access token and store it in a queue that a background process can access.
Get all the information you need immediately to make the app work.
Some time later
In a background process, grab an access token from the queue, parse it and handle it however you'd like.
A simpler, although less stable option, is redirecting the user to a page upon installation which makes an AJAX request to that page telling it to download the information from the graph. This keeps the response time low, but does require your user to have Javascript enabled and for them to stay on the destination page long enough for the request to be created.
I'm working on a project that require my application to pay the user to his paypal account when he asks it.
Here's how I did it so far:
The (logged) user goes to the Pay page that will list all his Payments (received or not)
He enters his Paypal email and his application (mine) password (for security)
The POST page get a list of all the Payments that have status="UNPAID" for that user and update the status to "WORKING" (to avoid the user to refresh the page before the whole process is done and resend the same amount of money)
We count the total amount to pay in that list (a simple for)
The amount is sent to Paypal via Paypal Adaptive Payment API (request: PAY)
The response is checked, if completed, the list status is set to "COMPLETED", if not, the list is reverted to "UNPAID" (the SQL update is made via a WHERE id IN(x, y, z) in case a second Payment request has been made during that time.
A message is then displayed to the user
But I need your help, I'm in front of one risky problem I'd like to avoid, and I would know how you would do:
If the user hit refresh on the process page, I don't want to send him twice (or more) the amount (The "WORKING" lock is here for that, but what happens if the user hit refresh before I set the lock ?)
Rare possible: what happens if the user hit f5 after the lock "WORKING" is made, but before the request to paypal, and a new payment is received. By following what I did, just one item (the new) would be get and set to WORKING, but all others previous payment would be losts
How would you do? What is the best way to make it to be 100% reliable?
Thanks for your help
Note:
The steps between 4 to 6 is made via a PlayFramework jobs, called with now() and awaiting() the result
you can:
prevent double post via JQuery
use the checkAuthenticity() method to validate the request
do a GET redirect after processing the POST (so they can't submit the same 2 times even by mistake)
do the payment processing asynchronous (see below)
For the payment, instead of calling the job, set the id's of payments in a queue (or table in the database) and a job that runs once per minute that processes that table if it has some data. When the user does the POST you redirect to a page that says that you are processing the payments and will notify if there is some issue. You can notify the user later via a UI warning using comet or via mail.
That way you don't link the request to the processing, and you won't have threading/racing issues, as well as being able to detect stale requests (payments already done) if you do a sequential processing.