What is Omnivore pos?
Omnivore pos empowers restaurant brands to digitize their guest and operational experience in a meaningful and sustainable way. Omnivore software developed by custom mobile app development company provides an end-to-end suite of solutions built on data and insights that help optimize the essential elements of the digital restaurant experience, online ordering, pay at the table, third-party delivery, labor, and analytics.
Understanding locations
A location is a terminology for an individual restaurant connected to Omnivore pos integration , and it contains data about a restaurant location. Omnivore company is responsible for all activity or data updating tasks of location. Pos integration analyses your needs and requirements and creates useful data such as a menu, modifier, discount, employee details, and order type for your restaurant against a unique location id that belongs to your restaurant. Top mobile app development companies have introduced really helpful restaurant pos integration.
- Employee - Employee is a person present in a restaurant who takes care of his customer's order directly or by table depending on the restaurant. Orders are placed on behalf of employees. As a developer, you can find a list of all employees by calling Omnivore's universal API, which is needed when opening or closing the ticket.
- Order Types - Orders have a type, whether it's in-house dining, carry out, phone orders, or something else. As an ios app development company, app developer, you can find a list of order types defined by the restaurant owner at the time of analysis by calling Omnivore's universal API, omnivore pos
- Tables -Tables are virtual tables in pos that belong to the real one present in the restaurant from which its customer's order. It is virtual mapping with an actual one, and its virtual id is needed while ordering or at the time of payment. It depends on the restaurant owner, which tables to use for virtualization. You can get a list of all virtual tables by calling Omnivore's universal API, pos system integration
- Revenue Centers - This is nothing but a payment counter where revenue is collected. Restaurants can have more than one revenue center depending on the size of the restaurant. Revenue center id is needed at the time of payment.
What POS systems does Omnivore integrate with?
Omnivore pos integration integrates with Aloha, Azbar, Brink, Dinerware, Doshii (Impos, Starrtec, H&L, TriniTEQ, ArzPOS), Lavu, Lightspeed, Maitre'D, Oracle Hospitality (3700, Simphony1, Simphony2), POSitouch, Squirrel, Toast, XPIENT plus more in development. Some POS systems support multiple restaurants with a single deployment, like in hotels, airports, casinos, and resorts. In these cases, each individual restaurant is a separate location in Omnivore.
How can the app be integrated with restaurant POS through Omnivore pos?
You can use any backend programming language having suitable web-framework as Omnivore provides API containing resources that have both data for the requested object and links to traverse further into the API. Resources can also include other resources, known as sub-resources. For example, a list of Employees is a sub-resource of a Location. Sub-resources belong to their parent resource.
Integration and API key
As we know that Omnivore provides API for almost all types of data regarding restaurant transactions, but to call this API, we need an API key that authenticates each request that came to the pos integration api. As a developer, you need to get this key from your client(restaurant owner) or by logging into the omnivore website by selecting the appropriate location.
Note - Your account comes with an Application with a Production API Key that you can use to execute calls against the Virtual POS.
Menu and modifiers
Omnivore API contains a menu API that includes raw data that is not presentable to the customer directly. In the real world scenario, restaurant owners often categorize their menu so that it can be easy for customers to choose, but in the case of Omnivore pos, there is no such categorization of menu items.
Modifiers applied to a menu item, and it can be mandatory for some menu items. The full cost of the modifier in cents, including quantity and all modifiers and discounts. Some pos integration cannot provide a specific cost for ordered modifiers in some scenarios, so this may be null.
Problems with ugly menu data in POS
We know that Omnivore software provides a universal API, so each object contains lots of unnecessary property with nil or some value that we don't use for our app. This raw data includes lots of objects and their properties, which slows downs and is difficult to parse and process for our app. Also, it is time-consuming as we receive requests from customers having Mobile apps, and then we make API requests to Omnivore, then grab menu data and send back to the customer (mobile app).
Solution
Instead of creating API calls for every request made by the customer, It's better to store response data in the backend with only those properties which are needed for our Mobile app. It saves the time required to get a response from omnivore pos integration and makes it easy to parse and process the mapping at the front end.
No categorization of menu items
We know the categorization of menu items is essential to make it easy for customers to find details(price, quantity) of the menu or dish he is searching for. But unfortunately, Omnivore pos doesn't take care of it and provides raw data objects which are difficult for developers to present at the front-end and even difficult for customers to find their favorite item if the menu list is extensive.
Solution
Backend developers need to understand that data must be reliable so that at the front-end, we can avoid business logic for the view of the menu and improve app response to the customer. So it's better to store menu items in the backend database with the appropriate mapping of category so that we can save front-end programming efforts by passing category viz sorted menu in response to API, which then improves response time and also customer gets categorized view of the menu helping point of sale integration.
Working with Tickets
Tickets keep track of the things ordered by customers of a restaurant and are needed to generate virtual receipts for customers at the time of payment.
- Opening ticket When a customer tries to purchase some menu items and order it, we need to call the open ticket API by passing an object of some mandatory details as the body of API.
I.e. {"employee":"100","order_type":"1","revenue_center":"1"}'Here employee id, order type, and revenue center are mandatory properties and are required to open the new ticket. We have to set a static emp id for the online home delivery orders, and for the restaurant tab(QR code), we can use some logic to change employee id.
i.e., Which table is handled by which employee accordingly, we can grab which employee to assign to open which ticket depending on the tab(QR) of that table.
Omnivore company provides customization in various API, such as opening tickets if we want to set different values for service charges rather than default. This can be achieved by passing an array of service charges with comments.
- Service charges - Service Charges are untaxed additions to tickets, like a delivery charge or required gratuity. Service Charges can be open or closed. Open service charges have their value assigned when applied to a ticket, while closed service charges are pre-configured with fixed dollar values. You can find a list of all service charges using API, these charges were decided at the time of analysis of restaurant requirement. The best thing about Omnivore pos is it is scalable, and we can have the option to choose the service charges that are applied to tickets. We can pass an array of service charge id and amount with a comment at the time of ticket creation.
- Ordering items - We can get a list of menu items API, which returns objects having a property such as {item _id, in_stock, name,pos_id, price_per_unit} for each menu item. Send this response to the user app so that he/she can choose their favorite menu item, add it to the ticket, and send it back to the back end. Once you receive a response from a customer, you can call the omnivore API by passing below object as the body of API
- Using price level - Sometimes, we may have to provide options for different price levels.
{
"menu_item": "MENUITEM ID",
"quantity": 1,
"price_level": "PRICELEVELID",
"modifiers": []
}I.e., Suppose customers choose a pizza from the menu, and there are three variants of pizza such as large, small, medium, or that restaurant might offer special pricing during certain times of day then should provide options to enable and disable this price level.
- Making payments - After opening a ticket and placing some orders, all we need to do now is pay for it. Providing an option for users to close tickets by paying the amount. To achieve this before opening a ticket, we must ask the customer for credit or debit info and provide this info to spreadly which payment gateway in digital transactions. Once done with this spreadly, return a unique token for that card of the user, which we then use for payment.
Spreedly API https://core.spreedly.com/v1/receivers/spreedly_omnivore_receiver_token//deliver.json
These are some mandatory things that we need to pass to spreadly as body of API
"delivery" => {
"payment_method_token" => token,
"url" => "https://api.omnivore.io/1.0/locations/location-id/tickets/ticket-id/payments/”,
"headers" => "{{user}}: {{pass}}\nContent-Type: application/json",
"body" => "{
"type": "card_type",
"amount": total-amount,
"tip": tip for waiter (if any),
"card_info": {
"exp_month": month,
"exp_year": year,
"cvc2": cvv,
"number": "card number"
}
}
}In response to this API, we received success or errors, if any, to make sure. Whether payment for that ticket is successful or not and we can show appropriate response to the user.
What's a Webhook?
A webhook or web callback or HTTP push API, is a way for an app to provide other applications with real-time information. A webhook delivers data to other applications real-time. Unlike typical APIs, pos integration where you would need to poll for data very frequently to get it real-time. This makes webhooks much more efficient for both providers and consumers.
Use of webhook in Omnivore pos
There are several events, and transactions executed simultaneously in Omnivore pos integration, and webhook play an important role in this transaction to produce updated data and serve it to restaurants and customers with immediate effect.
Example -
Assume that we are storing omnivore transactions data on our production server
- Scenario 1
Let's suppose customer is on the table, and he open's omnivore ticket by scanning QR code available on table and order something from the mobile app and later he asks the waiter to add few more dishes or modifier to his ordered item which then added by restaurants employee from restaurants side then webhook of Omnivore software immediately sent updated order info to the production server to update the data regarding that ticket and is immediately available on customers application.
- Scenario 2
Let's suppose the customer creates a ticket using the app and forget to close the ticket created by him. After that restaurant employee cancels that ticket due to some reason then webhook of Omnivore automatically gets trigger and sent ticket details to a production server so that server-side business logic will process on ticket data and cancel that ticket from the server as well which helps to maintain the consistency of data between omnivore and production server also helps to send live updates to customer app & to maintain ordered history.
Conclusion
Omnivore pos enables agility in the restaurant industry, and ensures restaurant pos integration be adaptive to the fast changing consumer usage of technology. Our web and mobile app development company have been continuously working towards creating user friendly and dynamic platforms for startups. We would be more than glad to hear about your business plan, and how we can mutually work towards the same.
.png)
