I'm trying to get MassPay working on my website. Here's my code:
http://pastebin.com/rNGzXrq0
But it's uncomprehensible, as it gives me the error response "the number of input records is less than or equal to zero" even If there is 2 input records in the request.
How can I solve this ?
Thank you for your help :)
I noticed you have
'L_ATM0' => '5.00',
It should be
'L_AMT0' => '5.00',
The full list of PayPal API error messages can be found here.
The "long message" that you're receiving from the API is very poorly worded to the point of being almost useless.
Thankfully, the "short message" is a lot more helpful:
Transaction refused because of an invalid argument. See additional error messages for details.
So the error in question is related to a bad argument being passed.
Related
I get a 403 Forbidden response along with the "serviceErrorCode":100,"message":"Unpermitted fields present in PARAMETER: Data Processing Exception while processing f (truncated...) error when running this get request:
https://api.linkedin.com/v2/adAnalyticsV2?q=analytics&pivot=ACCOUNT&timeGranularity=DAILY&dateRange.start.day=22&dateRange.start.month=09&dateRange.start.year=2020&dateRange.end.day=22&dateRange.end.month=10&dateRange.end.year=2020&accounts%5B0%5D=urn%3Ali%3AsponsoredAccount%3A248XXXXXXXXX&fields=costInUsd,externalWebsiteConversions,impressions,clicks,conversionValueInLocalCurrency&start=0&count=500
I verified that i have the rw_ads and r_ads_reporting permissions.
Anybody know what this could be?
I figured it out. The dateRange is wrong. It needs to be:
dateRange=(start:(day:1,month:9,year:2020))
As Linkedin's API documentation is shit in regards to this it took me a lot of trial and error. I found a partial answer on this stackoverlow post. The final structure is correct but the example isn't. Linkedin's docs say the key is dateRange.start which is wrong.
We have an issue with our PayPal Express Checkout integration. We see an error coming back from DoExpressCheckout with code 10004 saying "Transaction refused because of an invalid argument. See additional error messages for details." But the response contains no additional error messages.
This occurs randomly with our integration. It started approximately one month ago and has happened 70 times vs 1430 successful transactions.
It appears to be random. Not tied to any specific amounts, browser type, time of transaction etc. One user could have several failures then try again with the same token and have it go through. Some users have come back 10 minutes later or change browser and it works. Most give up.
I'd appreciate any suggestions, is there a way to retrieve any more debug for this error?
SetExpressCheckout
USER=XXX
PWD=XXX
SIGNATURE=XXX
VERSION=112
METHOD=SetExpressCheckout
ALLOWNOTE=0
ADDROVERRIDE=1
PAYMENTREQUEST_0_SHIPTONAME=Mr X
PAYMENTREQUEST_0_SHIPTOSTREET=Test St
PAYMENTREQUEST_0_SHIPTOSTREET2=
PAYMENTREQUEST_0_SHIPTOCITY=City
PAYMENTREQUEST_0_SHIPTOSTATE=State
PAYMENTREQUEST_0_SHIPTOZIP=5000
PAYMENTREQUEST_0_SHIPTOCOUNTRYCODE=AU
PAYMENTREQUEST_0_SHIPTOPHONENUM=8888888888
RETURNURL=URLA
CANCELURL=URLB
PAYMENTREQUEST_0_PAYMENTACTION=Authorization
PAYMENTREQUEST_0_CURRENCYCODE=AUD
PAYMENTREQUEST_0_AMT=20.9
L_PAYMENTREQUEST_0_NAME0=DOOM PATROL VOL 6 #3
L_PAYMENTREQUEST_0_AMT0=7.95
L_PAYMENTREQUEST_0_NUMBER0=SEP160206
L_PAYMENTREQUEST_0_QTY0=1
L_PAYMENTREQUEST_0_CURRENCYCODE0=AUD
L_PAYMENTREQUEST_0_NAME1=MOTHER PANIC #1
L_PAYMENTREQUEST_0_AMT1=7.95
L_PAYMENTREQUEST_0_NUMBER1=SEP160201
L_PAYMENTREQUEST_0_QTY1=1
L_PAYMENTREQUEST_0_CURRENCYCODE1=AUD
L_PAYMENTREQUEST_0_NAME2=Regular Post (cannot be tracked)
L_PAYMENTREQUEST_0_AMT2=5
L_PAYMENTREQUEST_0_NUMBER2=Freight
L_PAYMENTREQUEST_0_QTY2=1
L_PAYMENTREQUEST_0_CURRENCYCODE2=AUD
GetExpressCheckout
USER=XXX
PWD=XXX
SIGNATURE=XXX
VERSION=2.3
TOKEN=EC-5DX46556HG972093T
METHOD=GetExpressCheckoutDetails
DoExpressCheckout
USER=XXX
PWD=XXX
SIGNATURE=XXX
VERSION=2.3
PAYMENTACTION=Authorization
PAYERID=XXX
TOKEN=EC-5DX46556HG972093T
AMT=20.9
CURRENCYCODE=AUD
METHOD=DoExpressCheckoutPayment
PayPal returns:
TOKEN=EC-5DX46556HG972093T
TIMESTAMP=2016-11-23T10:53:35Z
CORRELATIONID=XXX
ACK=Failure
VERSION=2.3
BUILD=000000
L_ERRORCODE0=10004
L_SHORTMESSAGE0=Internal Error
L_LONGMESSAGE0=Transaction refused because of an invalid argument. See additional error messages for details.
L_SEVERITYCODE0=Error
Error was on PayPals side. If you have the same issue just log a support ticket and magic will happen.
Until today I could do requests such as the following successfully
https://graph.facebook.com/v2.2/[PAGE_ID]/posts?access_token=[TOKEN]&since=2014-03-17T00:00:00Z&until=2014-03-17T23:59:59Z&limit=250&fields=id,message
Today when I tried to make this request I get the following response:
{
"error":{
"message":"(#100) The 'limit' parameter should not exceed 200",
"type":"OAuthException","code":100
}
}
Which is funny because the graph api mentions that the upper bound of the limit parameter is 250. Am I missing something or is there something wrong with the API?
This bug as been corrected as of January 30th.
Post limit change from documented max of 250 to 200 bug report
#Potaoes I suspect this is an error related to them solving some back-end and latency issues. Discussed here. https://developers.facebook.com/status/issues/320942614776706/
They are currently in the middle of push ( I assume to correct this error). https://developers.facebook.com/status/dashboard/
Finally the error has been reported. https://developers.facebook.com/bugs/1518130385135066/
#Vineesh The OP is correct. It's against all the API documentation that the limit has been 250 since v2.0. There has been no documented change to this.
The Error message exactly shows the Error.
The 'limit' parameter should not exceed 200",
You have given limit=250,
reduce the limit then try again.
I have a REST resource that returns tabular data:
http://example.org/api/tables/foo
This returns the first page of results from the foo table.
There is a query parameter to add a selection criteria to the resource:
http://example.org/api/tables/foo?id=bar
id=bar is not a free text query. Internally the server attempts to resolve bar to a known entity and creates a regular expression limiting the rows returned from foo. For this query to succeed bar must be an ID that the system is aware of - otherwise the regular expression cannot be generated appropriately.
What's the correct behavior for this resource if bar is not known to the system? I understand that 5xx responses are not appropriate since the client cannot call again and expect a different result. Is it appropriate to return a 404 response with a message detailing that bar was not recognized? Or is it better to return a 200 response (since this is a search result) with some envelope wrapping the empty search result detailing that bar could not be found? Something else entirely?
It all depends on your business domain.
If a call to an unknown entity is a failure in your domain - you should provide an error status code of 4xx (if I understand you correctly, the resource was not found - so a status code of 404 Not Found will be appropriate in here).
If a call to an unknown entity is ok, it just yield no results (lets say a google search that yields 0 results) you should provide a status code of 2xx.
Status codes 5xx are server error, and they tell the client that there is something wrong with the server side. In your situation there is nothing wrong with your server, so a status code of 4xx will be appropriate in here.
By the way, you don't have to use all the error codes for every error - basically if you go over you business domain, you will see that you can use only a small subset of these codes to describe your errors.
Be sure to provide a detailed message back in the response so that the person using your service will get as much details and information as possible.
If you can, provide links to online resources explaining the problem. For example, if you have a developers forum thread discussing this exact problem - provide a link to that thread.
If you have to use error codes, use string codes rather then random numbers, for example: use "UNKNOWN_ENTITY" instead of error number #9842.
Example for an error message:
{
"message" : "Unknown entity provided".
"description" : "Parameter bar is not known to the system.",
"errorCode" : "UNKNOWN_ENTITY",
"links":
[
{ "rel" : "help",
"href" : "http://myforum.com/errors/unkownEntityError",
"title" : "My Forum"
},
]
}
This is a question often up for debate, but most people will use 401 Unauthorized or 400 Bad Request to indicate errors. I typically use 401 for login failures / authentication failures and 400 for bad parameters. In the message body of a 400 response, I often return a message indicating the bad parameters.
I'm wondering whether it's safe to mark bounce messages containing "This is a permanent error." string from the first time?
When I get "This is a permanent error." doesn't mean "permanent error" for this message or for the user?
Depends on what the error code is. Check the message for a code, and compare it to one of these tables, which should tell you more.
http://www.unixhub.com/docs/email/SMTPcodes.html
http://www.emailaddressmanager.com/tips/codes.html
Without the actual error output, I can't give you a more specific answer.