I am testing Uber API User Activity endpoints in sandbox.
I have created a request, then successively changed its status from "processing" to "completed" - request details returns me status: "completed".
However when I try to fetch history (both v1.1 & v1.2), I receive an empty "history" array: {"count":0,"offset":0,"limit":5,"history":[]}
Is it currently impossible to test history in the sandbox, or am I doing something wrong?
The sandbox is meant to test the /request endpoint so that you can test your code without requesting a live ride. This means a fake ride is created when you make a POST to /request which you can change the status for, get a receipt or map, and cancel, as you have been able to do.
When using other endpoints like /products or /history, real data is returned, even if you are in the sandbox. The rides or set variables in sandbox do not affect this data -- i.e. your sandbox ride does not get added to /history, and making a product surge in sandbox does not change real estimates in /estimates/price.
You are receiving empty history because the user associated with the access token has not taken any real rides with Uber. The response reflects the actual history and this is the correct way to test the history endpoint.
Related
Here is the scenario:
User logins to the bank successfully (via Fastlink)
Right after user logs in, I get user's provider_accounts (via /providerAccounts API)
Then when I call to get the accounts, (via /accounts) I sometimes get empty response (zero accounts found?)
When I try later (seconds or minutes after) I get some accounts information back.
Is this because Yodlee is still trying to gather account information when I'm making /accounts api call?
This is because the accounts are still being added/linked.
Using the requestId and providerAccountId provided by FastLink callback, you need to poll continuously to know the refresh status of the account linking process and once it's done, you can call the get accounts.
Read more about the refresh status in the "Add/Update Account Process Status" section.
Yodlee makes things easier now with webhooks. Read more here:
Using Webhooks with the Yodlee Core API
TL/DR: You need to wait for the add/link completion before retrieving the accounts.
According to the documentation the paypal payment method should be able to do Authorization & Capture just fine. The following excerpt under the PayPal authorizations excerpt specifically states how to go about it:
First get payment approval and execute the payment as you normally would do for a PayPal payment. Once you successfully execute on the payment authorization, PayPal responds with a new set of HATEOAS links, including a capture link that you use to capture the payment.
So if im following correctly the flow for doing Authorize & Capture is as follows:
Create a Payment
Redirect User to HATEOAS link approval_url to get them to sign into paypal.
Be returned to success (or cancel, but not in this example) link.
Get the Payment to see what's changed, get the shipping address / etc....
Let the customer review the details
Execute The Payment to commit to the hold on funds.
At this point an AuthorizationID / HATEOAS Link should hold information about the authorization.
Some time later use the authorization ID to Capture, and voila, we're done.
Now this is all fine and dandy, but in my tests on the sandbox environment I'm having trouble retrieving the authorization ID anywhere.
Here's my HATEOAS Links I receive from my Execute Step:
As you can see, only the self reference is returned, according to the documentation there should be one capture link at the least that should have the authorizationID in it.
Also, nowhere in the response body is any authorization ID. However, If I look at the payment in my sandbox paypal dashboard:
And once I drill down into it:
Sure enough if I call the Authorization.Capture API call against 8B633793L37511009 it captures as you would expect. However I can't find a programmatic way to determine this number.
How am I supposed to store the authorization number so my tooling can capture later when our business conditions have been met?
In the beggining, when you create the payment with intent authorize you should be getting an authorization object within the response. This object has the id you need for the capture later.
Check this blog post to see if you're missing something fundamental in the picture.
I followed the tutorial and executed the sample requests via curl. As you can see, I got the authorization id under transactions->related resources->authorization->id
Then I used the id in the URL and successfully captured the payment.
Hope this helps, if it doesn't, please elaborate and maybe I will be able to help you further. Good luck!
I am running an application using Instagram's RealTime API and when I subscribe to a tag initially all is working fine, I can see for sure my response times are all within 100ms back to instagram but after about an hour, hour and a half they randomly delete my tag subscription. I check and I am not rate limited so I setup something to check my subscriptions every 10 minutes and if the tag I was subscribed to isn't returned from instagram to re-subscribe it. When running that I get back a response that it is subscribed -
{ object: 'tag',
object_id: '...',
aspect: 'media',
callback_url: 'http://...',
type: 'subscription',
id: '4479168' }
but then when I check my subscriptions again using the API Console it shows there are no subscriptions.
Does anyone have any idea why Instagram is deleting my subscription automatically.
Did you validate/confirm the subscription? You didn't mention doing it in your question so that leads me to think that maybe it's timing out after not being confirmed?
According to the API docs a POST to make any subscription will trigger a GET to your callback_url that will include:
hub.mode - This will be set to "subscribe"
hub.challenge - This will be set to a random string that your callback URL will need to echo back in order to verify you'd like to subscribe.
hub.verify_token - This will be set to whatever verify_token passed in with the subscription request.
The example URL given is:
http://your-callback.com/url/?hub.mode=subscribe&hub.challenge=15f7d1a91c1f40f8a748fd134752feb3&hub.verify_token=myVerifyToken
After parsing that callback you have to send a response including the hub.challenge value and you should have a lasting subscription.
As far as I can tell, this happens when Instagram decides you are not responding fast enough. I noticed 8 separate IPs posting the exact same subscription info (identical HTTP requests) and my app apparently has some transient lag issues. It appears that if responses are not sent immediately (100s of ms) then Instagram silently deletes the subscription and there's no way to find out.
Solution was to dump the subscription model and just poll them instead.
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.
I am attempting to integrate Authorize.net into my site. I have set up and activated a test account in their test.authorize.net domain and have obtained and inserted their API key/login for my account into my configurations. I run my script through their API and I get the proper success message that they've received the information. However, every time I log into the test.authorize.net domain and search for the transactions via their Search tab, it always returns with nothing regardless of what parameters I search with. What can cause this?
Look in the unsettled transactions. That's where they'll be.
FYI, Authorize.Net developer accounts do not actually process transactions. They only validate that the data you sent over via their API was valid and complete. If it is you will receive an approved response with a fake transaction number, approval, and AVS response code (which is always a match). If your made an invalid API call an error message will be returned alerting you to your error so you can correct it.
If you don't want o call Authorize.Net for support or they give you the run around, you can also get help in their developer forums.
Authorize.net does not actually log transactions in test mode.
You should call their support; they are fantastic. However, from my experience you typically get a shared account where lots of tests are running and it can be hard to search for your transaction.