Paypal CreateRecurringPaymentsProfile 10002 error - paypal

I'm trying to create recurring payment profile using CreateRecurringPaymentsProfile method of Paypal API version 54.0 56.0 in Sandbox mode.
Unfortunately I'm getting 10002 error "You do not have permissions to make this API call".
I've rechecked API credentials for few times and it looks correct. Also other methods of API (ex. DoDirectPayment) works perfectly.
Does anybody faced such a problem? What a solution?
Thank you very much I need your help.
UPD:
The request is performed by Zend_Http_Client. Sending get array like:
array (
'USER' => 'user_1324103739_biz_api1.domain.com',
'PWD' => 'DCM6SLXFXLW99RRR',
'SIGNATURE' => 'signature',
'VERSION' => '56.0',
'METHOD' => 'CreateRecurringPaymentsProfile',
'TOKEN' => 'EC-12C13621A5208361W',
'IPADDRESS' => '127.0.0.1',
'USER_AGENT' => 'Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7',
'AMT' => 100,
'SUBJECT' => 'Silver plan monthly payment',
'CURRENCYCODE' => 'USD',
'COUNTRYCODE' => 'US',
'EMAIL' => 'user#email.com',
'PROFILESTARTDATE' => '2012-19-01CST3:48:2418',
'BILLINGPERIOD' => 'Month',
'BILLINGFREQUENCY' => 1)
The request example:
GET /nvp?USER=user_1324103739_biz_api1.domain.com&PWD=DCM6SLXFXLW99RRR&SIGNATURE=signature&VERSION=56.0&METHOD=CreateRecurringPaymentsProfile&TOKEN=EC-12C13621A5208361W&IPADDRESS=127.0.0.1&USER_AGENT=Mozilla%2F5.0+%28X11%3B+Linux+i686%29+AppleWebKit%2F535.7+%28KHTML%2C+like+Gecko%29+Chrome%2F16.0.912.63+Safari%2F535.7&AMT=100&SUBJECT=Silver+plan+monthly+payment&CURRENCYCODE=USD&COUNTRYCODE=US&EMAIL=user%40email.com&PROFILESTARTDATE=2012-19-01CST3%3A48%3A2418&BILLINGPERIOD=Month&BILLINGFREQUENCY=1 HTTP/1.1
Host: api-3t.sandbox.paypal.com
Connection: close
Accept-encoding: gzip, deflate
User-Agent: Zend_Http_Client
Response example:
TIMESTAMP=2011%2d12%2d19T09%3a55%3a14Z&CORRELATIONID=3fcaa599c0ad0&ACK=Failure&VERSION=56%2e0&BUILD=2230381&L_ERRORCODE0=10002&L_SHORTMESSAGE0=Authentication%2fAuthorization%20Failed&L_LONGMESSAGE0=You%20do%20not%20have%20permissions%20to%20make%20this%20API%20call&L_SEVERITYCODE0=Error

SUBJECT is causing this. SUBJECT is meant for third-party API authorization where the value of SUBJECT is the email address / secure merchant ID of a third party which authorized you to call the API on their behalf, not as a descriptive text. For that you'll want to use 'DESC'.
I would also suggest removing:
IPADDRESS (not part of CreateRecurringPaymentsProfile API)
COUNTRYCODE (not part of CreateRecurringPaymentsProfile API)

Related

Google Actions: Account linking sends GET request to token URL

I have some problems with the Account Linking for Google Actions:
I have implemented the OAuth2 steps described in the documentation by Google. I have implemented my OAuth2 server and tested it via Postman and am able to get an access token as expected.
If I try to authenticate from the Google Home app by adding the service to my account, I get taken to my authorization form, the authorization works fine and responds with an authorization code to Google's redirect URI as it is supposed to do. However Googles return URI says 'Account linking failed' and then I get a message in the Google Home app : 'Can't update the settings. Check your connection'.
Another strange thing that I've see from my logging of my Token URL script: I can see an incoming GET request from Google to my Token URL instead of a POST request with the required data as mentioned in the Google documentation. So even though the message 'Account linking failed' appears, it seems that Google is calling my token URL, but with a GET instead of a POST.
These are the logs of the requests to the token URL:
REQUEST FROM POSTMAN (testing software) > OK
__SERVER
Array
(
[USER] => www-data
[HOME] => /var/www
[HTTP_ACCEPT_ENCODING] => gzip, deflate
[HTTP_ACCEPT] => */*
[HTTP_USER_AGENT] => PostmanRuntime/7.6.1
[HTTP_POSTMAN_TOKEN] => f85664e2-7d38-4511-9519-cddda3feec06
[HTTP_CACHE_CONTROL] => no-cache
[HTTP_CONTENT_TYPE] => application/x-www-form-urlencoded
[HTTP_CONTENT_LENGTH] => 145
[HTTP_CONNECTION] => close
[HTTP_HOST] => 127.0.0.1
[REDIRECT_STATUS] => 200
[SERVER_NAME] => _
[SERVER_PORT] => 80
[SERVER_ADDR] => 127.0.0.1
[REMOTE_PORT] => 38622
[REMOTE_ADDR] => 127.0.0.1
[SERVER_SOFTWARE] => nginx/1.12.2
[GATEWAY_INTERFACE] => CGI/1.1
[REQUEST_SCHEME] => http
[SERVER_PROTOCOL] => HTTP/1.0
[DOCUMENT_ROOT] => [******]
[DOCUMENT_URI] => /google/token/index.php
[REQUEST_URI] => /google/token/
[SCRIPT_NAME] => /google/token/index.php
[CONTENT_LENGTH] => 145
[CONTENT_TYPE] => application/x-www-form-urlencoded
[REQUEST_METHOD] => POST
[QUERY_STRING] =>
[SCRIPT_FILENAME] => [******]
[FCGI_ROLE] => RESPONDER
[PHP_SELF] => /google/token/index.php
[REQUEST_TIME_FLOAT] => 1553765980.9273
[REQUEST_TIME] => 1553765980
)
__POST
Array
(
[client_id] => [******]
[client_secret] => [******]
[grant_type] => authorization_code
[code] => [******]
)
REQUEST RECEIVED WHEN TESTING WITH GOOGLE HOME APP on smartphone > NOT OK
__SERVER
Array
(
[USER] => www-data
[HOME] => /var/www
[HTTP_ACCEPT_ENCODING] => gzip,deflate,br
[HTTP_USER_AGENT] => OpenAuth
[HTTP_CONTENT_TYPE] => application/x-www-form-urlencoded
[HTTP_CONNECTION] => close
[HTTP_HOST] => 127.0.0.1
[REDIRECT_STATUS] => 200
[SERVER_NAME] => _
[SERVER_PORT] => 80
[SERVER_ADDR] => 127.0.0.1
[REMOTE_PORT] => 46184
[REMOTE_ADDR] => 127.0.0.1
[SERVER_SOFTWARE] => nginx/1.12.2
[GATEWAY_INTERFACE] => CGI/1.1
[REQUEST_SCHEME] => http
[SERVER_PROTOCOL] => HTTP/1.0
[DOCUMENT_ROOT] => [******]
[DOCUMENT_URI] => /google/token/index.php
[REQUEST_URI] => /google/token/
[SCRIPT_NAME] => /google/token/index.php
[CONTENT_LENGTH] =>
[CONTENT_TYPE] => application/x-www-form-urlencoded
[REQUEST_METHOD] => GET
[QUERY_STRING] =>
[SCRIPT_FILENAME] => [******]
[FCGI_ROLE] => RESPONDER
[PHP_SELF] => /google/token/index.php
[REQUEST_TIME_FLOAT] => 1553767309.7797
[REQUEST_TIME] => 1553767309
)
__REQUEST
Array
(
)
__POST
Array
(
)
__GET
Array
(
)
-------------------------
__ANSWER
400: invalid grant
Configuration in Actions Console
Problem seemed to be caused by the redirect of / to /index.php without the POST values.
Fixed it by changing my URLs in the Actions Console to /index.php and now the linking works fine.

Paypal Refund NVP API : You do not have permission to refund this transaction

i Am using Paypal NVP Refund Api For Refund Paypal Transaction.
All Things are ok but when i try to rung api, it gives me below Response.
Array
(
[TIMESTAMP] => 2017-07-17T13:58:24Z
[CORRELATIONID] => xxxxxxxxxx
[ACK] => Failure
[VERSION] => 51.0
[BUILD] => 36458220
[L_ERRORCODE0] => 10007
[L_SHORTMESSAGE0] => Permission denied
[L_LONGMESSAGE0] => You do not have permission to refund this transaction
[L_SEVERITYCODE0] => Error
)
is that some process i miss to call.?
After giving permission same issue exists.
Then I found I missed an argument..
I'm sending this request.
$nvpreq = array(
'USER' => '',
'PWD' => '',
'SIGNATURE' => '',
'METHOD'=> 'RefundTransaction',
'VERSION' => urlencode('94'),
'TRANSACTIONID' => 'xxxxxxxx',
'REFUNDTYPE' => 'Partial',
'AMT' => '0.01',
'CURRENCYCODE' => 'USD');
I forgot to add 'SUBJECT' => 'reiceversemail#gmail.com',.
Now it is working.
Here is the some causes of this error.
You used the wrong transaction ID.
You're trying to make the call for a third party and have the wrong
email address in the subject.
The subject account hasn't given you permission to make the
third-party call.
Here is link you can check this. Why did I get API error code 10007?

PayPal address_override integration to PayPal Express Checkout

I'm trying to set up PayPal address_override at my shop checkout as my customers have already filled in their delivery details.
I'm using express checkout, and following on from reading the documentation here: https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/formbasics/
I've got the following basic set up added into my working express checkout code (perl file):
# -- build the request for Paypal
my $response = $useragent->post($api_endpoint,
[
'METHOD' => 'SetExpressCheckout',
'VERSION' => '3.0',
'PWD' => $API_PASSWORD,
'USER' => $API_USERNAME,
'SIGNATURE' => $API_SIGNATURE,
'Amt' => $amount,
'PAYMENTACTION' => 'Sale',
'ReturnUrl' => $returnurl,
'CANCELURL' => $cancelurl,
'CURRENCYCODE' => $API_CURRENCYCODE,
'address_override' => '1',
'address1' => $d_address1,
'address2' => $d_address2,
'city' => $d_city,
'country' => $country,
'zip' => $d_post_code
]
);
However this isn't overriding the address when I get through to my PayPal account, it's still just showing my stored addresses.
I've read this post:
Paypal | Website Payment Standard | Adddress Override
And this one:
Paypal Address Override not working
Hopefully someone can show me where I'm going wrong, or if I've missed a step! Any help appreciated.
I may be wrong here but that API link you've pasted doesn't look like it's the same API that the rest of your code sample is using?
Searching for SetExpressCheckout leads to this page: https://developer.paypal.com/docs/classic/api/merchant/SetExpressCheckout_API_Operation_NVP/
I think you need to use the ADDROVERRIDE parameter instead of address_override and whatever else you need from that page.

refresh_token Invalid Credentials errors

I'm stumped. I'm trying to manually get a refresh token to load an access token for me on Mirror API using Perl and it keeps giving me credentials errors. When I load the exact HTTP request in the PHP example code (I've printed out the HTTP to compare) the same refresh_token works fine.
Here's my Perl HTTP request:
*POST https://accounts.google.com/o/oauth2/token
Host: accounts.google.com
User-Agent: libwww-perl/6.02
Content-Length: 175
Content-Type: application/x-www-form-urlencoded
client_id=client_id_goes_here&client_secret=client_secret_goes_here&refresh_token=refresh_token_goes_here&grant_type=refresh_token*
Here's the PHP on the same refresh_token:
*POST /o/oauth2/token HTTP/1.1
content-type: application/x-www-form-urlencoded
content-length: 175
client_id=client_id_goes_here&client_secret=client_secret_goes_here&refresh_token=refresh_token_goes_here&grant_type=refresh_token*
My Perl looks like this:
my $auth_response = $ua->request(POST 'https://accounts.google.com/o/oauth2/token',
'Host' => 'accounts.google.com',
'Content_Type' => 'application/x-www-form-urlencoded',
'Content' => [
'client_id' => $client_id,
'client_secret' => $client_secret,
'refresh_token' => $credentials->{'refresh_token'},
'grant_type' => 'refresh_token',
],
);
HELP! :-)
It looks like you're using LWP. I hacked up this quick example which uses LWP to dance the OAuth 2.0 dance with Google from start to token refresh.
Based on my experimentation, the code you've shown so far looks correct. Here's the exact code I used to refresh my access token:
my $auth_response = $ua->request(POST 'https://accounts.google.com/o/oauth2/token',
'Host' => 'accounts.google.com',
'Content_Type' => 'application/x-www-form-urlencoded',
'Content' => [
'client_id' => $client_id,
'client_secret' => $client_secret,
'refresh_token' => $refresh_token,
'grant_type' => 'refresh_token',
],
);
If you're still observing an error, try cloning that repo, populating your client_id and client_secret, and seeing if the problem persists. If it does, please share the result of print Dumper($auth_response); which will provide a lot of useful info.
Also, Perl isn't a language officially supported by Google, but it looks like the community has come through: there's an open source Perl client library. I've never used it before, but you may want to check it out.

mixed up POST values in Perl script

I need to send POST values to server url, and I'm using this code:
$ogone_ua = new LWP::UserAgent;
$ogone_response = $ogone_ua->post("http://server.url/", {
'ACCEPTURL' => 'http://server.url2',
'AMOUNT' => '1000',
'CURRENCY' => 'USD',
'LANGUAGE' => 'en_US',
'ORDERID' => '20130105220939',
'PSPID' => 'vukasin',
'SHASIGN' => '6AEE128943C7C896A6449FF7C2CE702222995B7F'
} );
but server receives:
POST / HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: athlon.herrpan.com:2389
User-Agent: SSL-AirKiosk/1.0
Content-Length: 206
Content-Type: application/x-www-form-urlencoded
LANGUAGE=en_US&ACCEPTURL=http%3A%2F%2Fserver.url2&SHASIGN=6AEE128943C7C896A6449FF7C2CE702222995B7F&CURRENCY=USD&AMOUNT=1000&PSPID=vukasin&ORDERID=20130105220939
Why it is not in order? The bank API needs POST values to be sorted, just like in code.
Hashes don't have an inherent order, so the order is lost before ->post is even called. However, POST (to which ->post passes its args) also accepts an array reference.
->post("http://server.url/", [
ACCEPTURL => 'http://server.url2',
AMOUNT => '1000',
CURRENCY => 'USD',
LANGUAGE => 'en_US',
ORDERID => '20130105220939',
PSPID => 'vukasin',
SHASIGN => '6AEE128943C7C896A6449FF7C2CE702222995B7F',
]);