We're using PayPal Express Checkout (implemented in Ruby, Active Merchant gem)
A few transactions failed recently, while majority work fine.
I have looked at our log file and identified the user who had failed transactions.
I have the transaction token, PayerID, user's email address, correlation ID.
I have contacted PayPal technical support about this and provided them with the above details.
But I wonder if it's possible to get more information about these failed transactions myself.
Does the Ruby gem Active Merchant provide an easy way to get it from PayPal?
Thanks
The only information you really get back, is just basically what comes back in the API response. Sometimes this is enough to determine what the cause of the issue is, other times it requires a little bit more looking into and PayPal MTS would need to look into it.
There are a few things you can do here to harden the Express Checkout implementation:
Monitoring Error Code Responses
Express Checkout will send back a series of error codes on failed transactions. What you can do is monitor these specific error responses and that will give you an idea of what the problem with the transaction is, and in doing so you'll be able to respond accordingly (such as trying to transaction again). Here are the error code responses for Express Checkout: http://www.paypalobjects.com/en_US/ebook/PP_APIReference/Appx-ErrorCodes_and_Messages.html#2270815
Looking up Transaction Data
Besides the error codes, you can also use a GetTransactionDetails API operation to grab information about some transaction that might have had a problem. This will return some useful information that would help you to handle these cases as well. This information is available here: https://www.x.com/developers/paypal/documentation-tools/api/gettransactiondetails-api-operation-nvp
Hope that helps,
Jon
Related
This question goes directly to the Flowground developers: Error notifications can currently only be sent by e-mail. This is very difficult to integrate into a monitoring system.
I know that I can use the API to query whether a flow is currently running or not. But I can not receive any error messages.
In the original API of elastic.io it is also possible to access logs: https://api.elastic.io/docs/v2/#retrieve-all-workspace-logs This does not work with Flowground. Are there plans or other possibilities?
The feature is currently "experimental" on the elastic.io instance. As soon as it will be productive, it will also be available on flowground.net.
Nonetheless I will talk with elastic.io, if it will be possible, to get access to this "experimental" feature a little bit earlier and give you feedback #Stephan Häußler.
Hey I'm developing an iOS application which communicates with an external web service in order to make various kinds of requests.
I'm aware of Murphy's Law "Anything that can go wrong, will go wrong" and that made me think about timeouts. Currently my application does not handle the situation when a request get completed and times out simultaneously. How should I handle such situations?
Without cooperation from the service provider there's not a lot you can do. If your app sees a timeout it cannot from that deduce whether the request actually completed or not. Could be it worked and something in the infrastructure failed to deliver the response, could be that it failed and hence you saw no timely response.
You have some actions you can take that will help the user. I assume that you have available to you the details of the request you attempted to send, your app should keep that locally. You are now in a position to do some useful things:
Some service authors allow you to safely submit the same request twice. So just resubmit, if it previously worked the service will just say "yep, already done that, here's the details|, if not it will just do the work as normal.
Some service authors allow you to query the status of previous request, so you can determine what has been done and what has not.
In some cases there is no IT system way to deal with the problem, the user will need to contact a help desk or call centre. Here having the details of what was previously attempted can be very useful.
When I make API calls to the server, I'm getting 404 errors for various data -- grades, role IDs, terms -- that I won't get on the next time I call it. The data's there on the server, viewable by the same user, and is often returned successfully, but not every time. The same user context will return data successfully for other calls.
Any ideas what could be causing this?
I'm using the Valence API with the Python client library and our 9.4.1 SP18 instance of Desire2Learn in a non-interactive script.
more detail: the text it returns on the bad 404s is " ErrorThe system cannot find the path specified."
It would help enormously to gather data about your case: packet traces that can show successful calls from your client alongside unsuccessful calls, in particular, would be very useful to see. If you are quite certain (and I see no reason you shouldn't be from your description) that you're forming the calls in the right way each time you make them, then the kind of behaviour you're noticing would seem to speak to some wider network or configuration issue: sometimes your calls are properly getting through the web service layer, and sometimes they are not -- this would seem therefore not to be down to the way you're using the API but in the way the service is able to receive that request.
I would encourage you, especially if you can gather data to provide showing this behaviour, to open a support incident with Desire2Learn's help desk in conjunction with your Approved Support Contact, or your Partner Manager (depending on whether you're a D2L client or a D2L partner).
First, thanks everyone.
Prerequisite：I am providing consumable items in my application.
product:
List item
User purchase the item by iap.
before my application received the updatedTrancactions(Transaction),Network is disconnected.
So my server don't have data to verify the receipt. the user also can not get the "Virtual currency".
Would anyone tell me how to solve this problem，or give me some tip. Thanks very much.
its the standard client-server problem. In case the connection between client and server is severed (due to timeout or other reasons), common way to do it is to retry the request. But if your API calls are not Idempotent and calling an API multiple times can affect the state of your system that many times then we have to resort to do something more clever. Some options you have -
Have a local database. When a purchase happens, then first update the state in you local DB. Late lazily sync the DB from client to server, I hear coredata or sqlite is excellent. User is not aware of this and since DB is local the UI will be extra snappy for the user.
Second approach is - in case of a failed HTTP call. You keep retrying till the call succeeds.
Incase the API is non-idempotent, then you need to have a concept of a token. i.e. a API call with the same token called multiple times is first checked on the server-side if the initial call was a success only if it was a failure execute again. ex. this is very important in banking solutions. Imagine multiple debits from your bank account due to timeouts and someone programmed to keep retrying!
This is all I am able to think of right now. Give it a spin and tell us what worked for you...
I'm trying to use the FedEx API to track packages. I can authenticate to their test server successfully (using my user credentials, account number, and meter number). However, I receive the same unhelpful response for most tracking numbers that I use in my requests; both test tracking numbers (like 999999999999) and real tracking numbers (that work well on the FedEx website) return the following:
Error Code 9040.
No information for the following shipments has been received by our system yet. Please try again or contact Customer Service at 1.800.Go.FedEx(R) 800.463.3339.
The only requests that fetch a different response are the clearly invalid ones, like "test", which returns:
Error Code 5508.
Invalid tracking number.
I tried SOAP requests using their wsdl (TrackService_v5) as well as manual non-SOAP HTTP POST requests, but their responses are exactly the same in both cases. Is something wrong on their side, or am I doing something wrong?
It seems that FedEx has disabled any test tracking numbers, in the past 999999999999 would work just fine, but now that doesn't even work. To the best of my knowledge, the only way to resolve this is to move to production. Which IMHO is bad because you have to test the tracking part of your application until you move to production.
999999999999 worked for me, but I think I am already in production environment.