Verify if order id exists - paypal

I redirect the user to a page with the Smart Payment Buttons passing the order id in the URL
example.site?orderid=D23F34492211
But if the user changes the URL, the JavaScript will fetch an id that doesn't exist. Eventually, the transaction will not be completed, however, it will just close the PayPal's lightbox as well as the credit card option, without giving any error message.
The error it throws is something as following:
Fatal error: Uncaught PayPalHttp\HttpException: {"name":"RESOURCE_NOT_FOUND","details":[{"issue":"INVALID_RESOURCE_ID","description":"Specified resource ID does not exist. Please check the resource ID and try again."}],"message":"The specified resource does not exist.","debug_id":"9d62d83a871b8","links":
Is there any way to get this response as JSON or get the error code from the API and show an error message to the user? If not, what's the best way to verify whether the order id exists or not?

You shouldn't be passing the order ID via a URL, you should be fetching it from your server. Then you will know it is valid.
Anyway, your question is bout verifying the status of an order ID via an API call. It is not necessary to do this. You should not have to do this. But if you insist on doing it, there is an API call you can use. https://developer.paypal.com/docs/api/orders/v2/#orders_get
This API call should be run from your server, so if you want to call it from the client, you will need to build a middleware endpoint route on your server. (Again, there is no point to doing this and it would be wasted effort)
The actual proper way to do things is to fetch the order ID from your server, as mentioned: https://developer.paypal.com/demo/checkout/#/pattern/server

Related

Error message "{responseCode8,responseMessageERROR_INVALID_PAYMENTTOKEN}" is displayed when I call the API for verifying the purchase token

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.

What is the best way to implement checking whether a username is already registered on the client side, if I want to keep my API RESTful?

As the title suggests, I am looking to have the client be able to check whether a username or email is already registered before the user submits the registration form. I had considered using an API endpoint that would return true or false for a given username, but this seems more RPC than RESTful. Is it bad practice to have such an endpoint if the rest of my API is RESTful? If so, what would a RESTful approach to this situation look like?
A key concept in REST is that anything that can be named can be a resource; this includes procedures. If you want to have an endpoint that accepts a username in the request body and returns true/false that's perfectly fine.
Alternatively, you can (or may already) treat a user as a resource. Take the GitHub API as an example: you can fetch a user by sending a GET request to https://api.github.com/users/{username}. If the user exists, and therefore the username is taken, you'll get back 200 OK. If the user does not exist you'll get 404 Not Found.
If you want to check if a username has been taken you can just issue a request for that username and then check the response. If you choose this approach HEAD is the more appropriate method. HEAD is essentially the same as GET except that the response body is empty. Since you don't need the body to determine if the user exists you can save a tiny bit of bandwidth with HEAD over GET.
You could do a POST /registrations and return a 400 with validation errors array and just have client side logic filter that array for invalid username. In other words, no reason you can't hit the endpoint multiple times. This should help decouple your UX from your API.

REST method calling D2l For an enrollment but returns status 303

I'm trying to enroll a user with a REST method. The user exists, and I'm using as endpoint /d2l/api/lp/1.0/enrollments/
The params and sign params are right, because I was able to create the user, and perform other calls.
But the only response I'm getting for that call is
[Status=See other, StatusCode=303]
And nothing else, like the URL to redirect.
Has somebody been through this already? Or any hints of what I could be doing wrong?
Thanks.
Notice that the rights to enroll are granted based on a matrix of permissions (RoleType,OrgUnitType). That is, your calling user may be able to create a user record and enroll that user as a Student Role in the Organization org unit type, and not have the permissions to enroll that user in a Department, Semester, Course Offering, or other org unit type.
The 303 you're getting is most likely a redirect to an error page as a result of your POST failing for some reason. If you're able to make other calls fine, then the most likely errors are that your calling user context is not permitted to make the enrollment action you're trying, you're not identifying the user, user role, or org unit properly in the CreateEnrollmentData block you're passing, or the block is malformed in some way.
It may help to further diagnose the issue if you use Fiddler, WireShark, or some other packet sniffer utility to closely examine the exact HTTP request you're making, and the exact response traffic you're getting back as a result. For more assistance there, you can look at this blog article on D2L's Developer Blog.

getInsitutions failing on new user

In the .NetAggCatSample app, I've found that calling getInstitutions with an existing user context seems to work fine, but for new users, I'm getting an exceptions (message = "forbidden").
Could this be due to running into the max user limit in Dev mode (which I am in)?
Also, which API call actually creates the user at Intuit?
To add the answer,
Any API call after retrieving OAuth tokens from the SAML assertion will create the user in the system. As you mentioned, you are most likely getting the 403 error because you are at your max customer limit. Please enable logging and post the response XML from the call that returns a 403:
http://docs.developer.intuit.com/0020_Aggregation_Categorization_Apps/DevKits/0250.NET_AggCat_DevKit_1.0/0006_Logging#Request_and_Response_Log
thanks
Jarred

Error code 100 (Can only call this method on valid test users for your app)

getting the error {"error":{"message":"(#100) Can only call this method on valid test users for your app","type":"OAuthException"}} whenever trying to write to any facebook end point. Reading (GET) works fine, writing (POST) fails. Does anybody know how to resolve this?
I have also opened a ticket on FB dev site:
http://developers.facebook.com/bugs/184198634991192?browse=search_4e93328871c8a3231774584
The problem does not occur is I would shoot the POST request from my browser as if I am the user.
The problem does occurs only when sending from our servers on behalf of the user from one of our dev machines which have other subdomain names instead of www (such as dev1.blablabla.com & dev2.blablabla.com, while the app is registered to www.blablabla.com).
So the question is, does facebook attempt to do a reverse DNS lookup on all write requests to verify the source?
I believe your requirement is to get the user details of the owner of Facebook access token (normally the currently logged in user)
For that you have to issue a GET request and not a POST request.
The reason why it works when fired from the browser is that when you submit a query through the address bar it is send as a GET request, and when sent from your server it is send as POST and fails producing the error message mentioned in your post.
Facebook doesn't do a reverse DNS lookup on your write request and not need to configure anything in your server related to it.
Hope the answer is clear enough for you.