As the title says, I would like to check if the user has deleted his consent on Future Payments in his PayPal profile. I am currently only testing in the Sandbox environment with the iOS mSDK and the Java REST API SDK.
I expected that creating new accessTokens using the refreshToken would throw an error, but it is still possible. Then I tried to query Userinformation, but this is also possible.
If I create a new Payment, then I get an error (REQUIRED_SCOPE_MISSING). But isn't there a way to check that without creating a transaction each time?
you can always call updateBillingAgreement API to check whether it is active or not.
Paypal also has IPN setup to adhere this kind of notifications.https://www.paypal.com/cgi-bin/webscr?cmd=p/acc/ipn-info-outside
I found no good solution for this problem without using IPN (not tested yet). I am now using a workaround as described here: https://github.com/paypal/PayPal-iOS-SDK/issues/189.
Conclusion: An accessToken generated with the refreshToken has the value "900" in the field "expires_in" if the user consent still exists. Otherwise, it is "28800".
Does anyone have a better solution?
Related
I made a request to verify the purchase token by referring to the official materials, but error message "{responseCode 8 , responseMessage ERROR_INVALID_PAYMENTTOKEN}" was returned. The URL of the request API was {rootUrl}/applications/purchases/tokens/verify. Is there anyone who can help me with this problem?
First, you need to make sure that consuming or confirming a product is performed for a user only when the user has successfully purchased it, that is already owned the product.
Then you also need to ensure that the input parameters in the API call request are correct.
For example,use the wrong site to check that purchaseToken.or The productID is not added to the PMS or is incorrect. and so on.
For more details,you can refer to error codes.
I'm still trying to wrap my head around all this, so my apologies if I've made a mistake, but it seems like the old NVP apps that are now unable to be registered as of December 1st had some features available that can't be replicated in the new REST world order...
Here's what I want/need: I need to be able to translate buyer-side transaction IDs into my seller-side transaction IDs, and I want to be able to do this on a webserver that is secure but I don't want it to have full access to my account, so I'd like fine-grained authz for this server.
It seems like I am a couple days too late to actually get what I want/need. Basically, GetTransactionDetails does exactly what I want (convert buyer to seller transaction IDs, and returns the rest of the transaction information for good measure). And, although I haven't gotten it working, it looks like the Permissions SDK plus an NVP AppID would allow me to have just the TRANSACTION_DETAILS permission on this service which is exactly what I want.
However, as of Friday apparently I can't get an AppID for the classic NVP API? If so, my timing is impeccable.
Trying to figure out how to do this in the REST API has proven difficult. This thread talks about the sale record, which does indeed take a buyer-side transaction ID, but it does not actually translate it into a seller-side one. It does have the custom field, which helps me a little, but I really need the seller-side transaction ID. It looks like maybe the parent_payment URL in the return from the sale might help, but the API started returning PERMISSION_DENIED on me even on previously successful queries so I can't exactly test this right now. And, even if that did work, it seems like the permissions on the REST API are incredibly coarse compared to the Permissions SDK, for example the sale endpoint is under /v1/payments which seems to also include refunds and all kinds of other stuff I don't want exposed. It looks like there's a Transaction Search permission but it's marked beta and it didn't work for querying a sale for me. But maybe it means they're working on it?
What are my options here?
Thanks,
Chris
Okay, so I played around with this for a while, and it seems like the PayPal REST API is just not very good. So, I worked around the limitations here using AWS Lambda and its fine-grained IAM permissions. I created a Lambda function that took my PayPal NVP credentials as encrypted env vars, and an IAM account that could only call my Lambda function, and so now I've got a microservice that will translate transaction IDs and return some extra info (custom and email) from the transaction to boot.
I wish I didn't have to use AWS to work around PayPal's limitations (which seem to be getting worse with the REST API, the NVP api would have been fine if I could have gotten and AppID and used the Permissions SDK), but oh well.
Chris
We implemented PayPal express checkout through the Braintree SDK (js v3) because this allows us to use our own HTML button whereas we would have to use the provided PayPal buttons if we were using the REST API.
Everything was working fine within our live setup until yesterday. Code was changed neither on the client nor on the server.
However, I did delete two REST API apps within the PayPal developer dashboard which were no longer needed since we had decided to go down the Braintree JS SDK path.
After that, express checkouts started throwing AuthenticationErrors.
Generating client tokens on our server still works. Performing the actual checkout fails on tokenization.
I receive the following exception:
{
"paymentResource": {
"errorName": "invalid_client",
"errorMessage": "Client Authentication failed",
"errorDetails": null,
"debugId": "84b227241374e",
"paypalHttpStatus": 401
}
}
The whole setup works using the test access_token btw :/
My current assumption is that the Braintree SDK access_token is somehow coupled to the default REST API App (email-facilitator#domain.tld). I deleted this default REST API App.
I found the following FAQ article which I believe proves the assumption might be correct: https://www.paypal-knowledge.com/infocenter/index?page=content&id=FAQ1938&expand=true&locale=en_US
We now switched to a different PayPal account as we could not figure out what was going wrong. Without changing any code except for the new access_token, everything started working again.
Has anyone experienced this or something similar before?
Does anyone know how I can either
Delete the Braintree Account or regenerate it (which will hopefully restore the link to my new REST API App)? or
Restore the link between my Braintree SDK access_token and my REST API app?
If something was unclear or if I can provide more context somewhere please let me know!
As Brian K correctly noted, the solution was to contact the PayPal technical support at paypal-techsupport.com/app/ask and ask for the deleted REST API app to be reinstated.
Everything is back to normal now.
Today I have been trying to implement the rest API into my application to look up transaction information from a transaction ID (GET /v1/payments/sale/)
I have implemented everything correctly on my end and set the mode to "live" and I can't seem to get details from a transaction.
Here is the full error code:
{"name":"REQUIRED_SCOPE_MISSING","message":"Access token does not have required scope","information_link":"https://developer.paypal.com/webapps/developer/docs/api/#REQUIRED_SCOPE_MISSING"}
And here is documentation on what I am trying to do: https://developer.paypal.com/docs/api/#look-up-a-sale
Any help would be appreciated.
Thanks.
There are few things you could do to make sure your configurations are set right.
If the mode is set to live, are you using the live credentials instead of sandbox. You can select the sandbox app and copy the live credentials from there. See bottom part of this image.
Make sure Payments are enabled on live. PayPal has a dashboard page, where you could see all the services that you have enabled to work with Live environment. This prevents accidents on unknowingly using an API on live. You can check the status here
Is the sale that you are looking for created by the same clientId that you are using for making a GET call ? Only the app who creates the sale, can view the sale.
In the mean time, PayPal has created SDKs for many languages to support REST APIs. They are actively developed, and maintained, and could help you mitigate issues in handling tokens, credentials, etc, and allows you to quickly use APIs faster and in a way that could be upgraded easily. Also, few SDKs come packaged with Sample codes, and wiki documentations. Few are still under development, but you can feel free to contribute back to these open source SDKs.
When I had this issue, the problem was that I was making REST requests using the Identity API token. Basically, I was logging users into my website with Paypal then using that token for REST requests when another token from the REST API service should have been used. "
Here is the support ticket from Paypal SDK deveoper Randy who helped answer my question even though I do not use the SDK. Thanks Randy:
https://github.com/paypal/PayPal-PHP-SDK/issues/785#issuecomment-282749095
Would implementing openssl prevent users from changing the button values?
I've researched into encrypting buttons, from hosted to using openssl.
Using hosted buttons would provide security at the cost of flexibility although there are variables that you can override, but still you cant override the important ones.
would using and implementing openssl on my webserver prevent users from changing a non-hosted paypal button ?
or would it just be better to fall back to a hosted button and use/validate using IPN?
My answer is non–PayPal specific (applies to any kind of HTTP form input), but the short answer is no. Even SSL cannot prevent the browser from modifying the form values that it receives.
A user could use a bookmarklet to execute a JavaScript program of her choice on your page after it has loaded, which has the ability to change form values. Because SSL only protects the transport between the browser and the server, not after the page has been processed by the browser, it makes no difference at all whether you use it.
This could be automated with Greasemonkey, which is the same idea, except makes it even easier for users to install other people’s JavaScript programs to run on your web page. As above, using SSL does not affect this at all, because it is all execute client side, which you, as the server, have no control over.
As you alluded to, using encrypted PayPal buttons would solve the problem, as any modification of the button parameters would invalidate the checksum, and PayPal would not accept the item.
The best solution would be using Express Checkout. This allows you a great deal more flexibility than standard buttons can ever offer you.
If you're thinking if doing IPN, you're probably capable enough to integrate Express Checkout. All it really is, is 1 API call, followed by a redirect to PayPal, and a minimum of 1 more API call to finalize the payment.
A typical flow would look as follows:
Call the SetExpressCheckout API. If you're new to this, it's made dead-easy with PayPal's NVP API interface. You can just send the data as a GET NVP string to https://api-3t.paypal.com/nvp and get a response back in the same format.
Take the token from the response, and redirect to https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=XXXXXXX (https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=XXXXXXX for Sandbox testing)
As soon as the buyer is returned, PayPal will append a PAYERID to your RETURNURL. If you can't find it, call the GetExpressCheckoutDetails API and supply your token to retrieve it.
With the PAYERID and TOKEN, call DoExpressCheckoutPayment to finalize the payment.
To get started with this, I'd suggest taking a looking at the PHP NVP SDK they offer at https://www.x.com/community/ppx/sdks#NVP