Location for app (console claims not authorized, but it definitely is)?

Questions
, , ,
21

Yes, I added some server code to list the locations for my test seller account, and that gave me the location ID. You actually can’t use the API Explorer, because it only lets you use the personal tokens from the default seller account. I tried that first.

The entire sandbox environment seems half baked.

On to the next problem: making a test payment in the sandbox creates a redirect back to my application, but it doesn’t add the “orderId” query parameter (theoretically available in production), which is needed to test my code that validates the order. The test payment preview also doesn’t let you actually use the test credit cards to test things like charge failures or alternate customer locations.

I hope things go more smoothly once I get to production.

22

The sandbox is definitely not ready for use. Not only is the dev console broken (as I’ve described), but doing things like searching for orders in a sandbox test account dashboard is completely broken. It gives me very little confidence in using Square as a solution.

A small bit of advice, if I may be so bold, for your orderId issue on re-direct: you probably shouldn’t rely on this working. And the reason actually is not because square is unreliable. The reason is that the user could complete payment and close the browser before the redirect ever happens. In this event, the user will have paid, Square will think they’ve paid, but your app will never know it. Any number of other issues could also cause the redirect to fail.

So, in the most general case, you can’t rely on the redirect ever happening at all. This means you’ll need to track order state in your app, that the user has an order payment pending, along with the order ID. And you’ll need a mechanism in your app to synchronize your app order state with square’s order state for order IDs that you’re tracking. And since this is the case, you might as well have the redirect from square payment just point to a URL in your app that triggers this synchronization.

23

Good points. Something to consider.

24

Can we possibly get an update on this:

I am experiencing the same issue for my application. Though I am sure I am generating the auth tokens correctly, I too only see identical rows whose permissions are solely: APPOINTMENTS_ALL_WRITE and APPOINTMENTS_WRITE.

This weirdness leads me to suspect that the reason I am receiving “Merchant not onboarded to Appointments” when I try to search for the availability of an appointment is because of this. Note that I do generate the token with the proper read conditions.

Some help relating to this issue seems fundamental, because it seems as though there are major issues with the developer sandbox.

25

Just an update – I was able to fix this by deleting the app completely and restarting everything. It seems as though you must do this in order to obtain a non-identical row. Nonetheless, I am still experiencing problems. My auth token says it has the following permissions:

MERCHANT_PROFILE_READ

APPOINTMENTS_ALL_READ

APPOINTMENTS_ALL_WRITE

APPOINTMENTS_BUSINESS_SETTINGS_READ

APPOINTMENTS_READ

APPOINTMENTS_WRITE

But when I ping “Retrieve business booking profile”, I still get the generic:

{
  "errors": [
    {
      "category": "AUTHENTICATION_ERROR",
      "code": "UNAUTHORIZED",
      "detail": "Merchant not onboarded to Appointments"
    }
  ]
}
26

What’s the merchant_id for the access token? :slight_smile: