question

Neil avatar image
Neil asked Neil commented

oauth requirement for customer ordering apps

We would like to roll out support for Clover in our restaurant ordering app platform, and I have questions about how/if we can implement the oauth workflow as outlined in your docs as this seems geared specifically toward apps that would be used by the merchants themselves rather than by the end customers of a restaurant as is the case with our apps.

We work with different restaurants, and our customer ordering apps fetch merchants/locations, menu items (including categories and modifiers); we would also like to insert customers and itemized orders if possible. We integrate with Spreedly to allow customers to store credit cards for future use, as many POS APIs do not support such functionality. I have all of this working very well for Clover merchants with the exception of the itemized order creation (really just haven't gotten to that yet). We are getting successful responses back from your endpoints using both the sandbox and production us api urls. However, currently in our server-side requests to your APIs we are using the auth tokens generated through the dashboard ( https://www.clover.com/setupapp/m/<merchant_id>/api-tokens). We create an unpublished app for each merchant, and we are able to store this merchant-specific access token securely on our servers. Leaving things as such would work very well for our purposes.

My concern is the strongly worded requirement that we must use oauth to generate the tokens programatically -- this would be totally fine if it could indeed be done programmatically because this would definitely need to happen server-side in our case. However the oauth workflow requires direct interaction from the merchant since the initial authorize request redirects to the clover login page. Is there a way around this? Can we continue using the access tokens generated through the dashboard? The authorization tokens are never sent to the client apps and are only dealt with on our server. We haven't rolled this integration to production as of yet, and I certainly do not want our developer account to be terminated per the warning but I do not see practical way of meeting the specific oauth workflow in our case.

Our apps do not require any write access for inventory and employee management as we are simply reading in menus to allow customers to place orders (we also give restaurants an in store dashboard with an order fulfillment screen, but this does not need to interact with Clover's APIs); the inserting customers and itemized orders is desired to allow merchants to benefit from whatever dashboard reporting features clover may offer for orders placed through our apps.

Thank you in advance for your help.
OAuth
2 comments
10 |2000

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Miguel avatar image Miguel commented ·

How do you payments processed in the customer facing app? Does it use the Clover Developer Pay API?

0 Likes 0 ·
Neil avatar image Neil Miguel commented ·

No, we are not using the Developer Pay API. We are using Spreedly for our integration with Clover, because customers need to be able to pay for their orders with saved credit cards.

0 Likes 0 ·

1 Answer

Miguel avatar image
Miguel Deactivated answered Neil commented
Tokens generated through the Setup app are not intended for production use. They have more restricted rate limits, and they may change any time without notice. I would not recommend using these tokens outside of testing and development.

I do not understand why the OAuth flow is a problem in your use case. When the merchant installs your app from the App Market, they will be redirected through the OAuth flow to generate an API token. Your app should then securely store this token for later use. Using the already stored token, your customer ordering app should use it to interact with Clover's REST API. There's no need to go through the OAuth flow again at this point.

You should make sure to handle the error case of the API token expiring. The merchant will need to launch your app again to authorize your app to generate a new token.

Also, it's important to note that private apps are not supported. All apps must go through the App Market and meet our developer guidelines and regulations.
2 comments
10 |2000

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Neil avatar image Neil commented ·
Thanks for your reply. This seems like kind of a generic answer and I understand that you guys want to encourage developers to publish apps on your App Market. But just to clarify again, these are individual restaurant ordering apps that are downloaded from the Apple App Store and Google Play by the customers of the restaurants and not by the merchants themselves. We also have an API which interacts directly with clover and other pos apis. There is no standalone app which would be installed by the merchants themselves, other than an order fulfillment webapp where orders are received at the restaurant. Am I understanding correctly that we would need to build a native Android app for merchants to install for the sole purpose of dealing with the oauth workflow? Sorry for being confused about this, but I'm just trying to understand exactly what app we would need to submit for approval through your app market.
0 Likes 0 ·
Neil avatar image Neil commented ·

Thank you again, Miguel. As a follow up question, is there a way for us to submit our restaurant admin dashboard webapp (the order fulfillment screen I described in the original question) for approval in the App Market? It seems to me the initial authorize request could be triggered when the merchant logs into that app, and it would be fine if the merchant is redirected to the clover login screen from that point.

This is not an APK but is a hosted webapp. Hoping the above is a possibility and thank you again for your time and assistance.

0 Likes 0 ·

Welcome to the
Clover Developer Community