Tier 3 & 4 integration

This tier is by where your team starts to do most of the work related to integration given that you are natively building AIQ into your UI/ products. To help show you how simple implementation is, we mocked up our own point of sale with all of our features baked in so that we can reference them.

This is one of the most crucial pieces to the AIQ integration. This prevents attack vectors, takes a lot of work out of the hands of the consumer and keeps the staff member in a single platform (Your POS).

In the above mockup, you can see that we are currently creating a cart for a customer named Molly Gardner. At the very bottom left of the image you will see "Available rewards". To show this entire section we call a single endpoint from AIQ utilizing the API key + UID of the account.

In the above response, you will see "discountTemplates". This an array of discounts the user has access to at the current time. The most important variables that will matter to you are "posDiscountID", "name", "pageTitle", "redemptionURL", and "pointsDeduction". Some integrations simply look for dollar or percentage off discounts (mutually exclusive) and they simply apply that to the cart and then call our redemption url to let us know once the checkout has completed. However, in recent years its become more powerful for AIQ to segment rewards you already have in your point of sale. This allows you to run BOGO + product level specific discounts and we simply piggyback that power by segmenting which ones they can get access to at a specific point in time.

In the above image you will notice 2 discounts available and the total points available to the customer at the top. AIQ would assume these 2 discounts are already in your point of sale. The client would copy/ paste their discount ID into the AIQ discount creation system (duplicating whats in your POS or AIQ will sync discounts via a GET endpoint. Either way you do not need to do anything as a developer on the POS side. All you need to do is call our endpoint above when the clients cart is being created, filter out our discountTemplates for ones that contain a matching "posDiscountID" to one that you have in your system, then display that as available. If it's not returned in our endpoint it means it's not applicable to the user. We will not return ANY discount that is not redeemable at that time for that customer. Then when they apply the discount and the cart is COMPLETED 100%/ paid for, you simply call our PUT endpoint "redemptionURL" for each of the discounts they redeemed + pass the transaction ID as a parameter on the end of the redemptionURL so that our reporting knows what transaction the reward was applied to (extremely important to public entity CFO reporting!). The parameter looks like this: "transactionID=123" within the redemption URL of each discount.

Depending on your setup, you might want to show rewards before actually calling the redemptionURL on each discount object. Lets say you push a reward through and finish a transaction, then that customer returns their T-shirt a few hours later. You might want to return the points. This can also be the case for a failed transaction whereby you need to re-start the entire POS checkout process and apply rewards again. If you have already redeemed them, you can't utilize them again until you refund the previous redemption. To do that call the following endpoint:



Increasing loyalty/ messaging signups astronomically increases revenue for operators. In order to capture customer signups you need to have a flow to do so compliantly. In our above screenshot we put a "Signup" button next to the customers name if they aren't a member. If they are already a member, you can simply show a "AIQ member" tag in replacement of the signup button.

To signup users please use the following endpoint: Note: a member can want messaging but not be loyal (not accrue points). For 99% of use cases, set "loyalty" = true. Please be aware that you should trust AIQ as the source of truth related to optins to marketing for mutual clients. AIQ sees signup and optin confirmations across several synced integrations at a time (Website, 3rd party services, 1st party ecomm, native POS, mobile QR code, mobile tablet, text to join, etc.

Sample UI of signup button + modal that opens after engaging:

The signup form should have email + phone + you can pass us hidden inputs in the background for first/ last name and the store location they are checking out at. We will map these store locations in our dashboard whenever we see a new JSON value come in. You should also have consent text the clerk signs off on as pictured above. Feel free to copy/ paste that block of text.

Did the staff member miss the signup SOP? Did the customer call in asking how to get points for their last order? This is why you need to have QR codes generated at the bottom of your receipts. You can easily guide the consumer to lock in their points and access their deals on the move via their mobile device in an easily recognizable location. Here's how easy this part is:

If you have a waiting room queue api, please provide that API to our engineering team. It allows us to power in-store personalized experiences based on the machine learning derived recommendations. As an example, if 4 of the 5 people in the store are edibles buyers, we will change in-store screen menus to list edibles first or have promotional content prioritized for them. We also can showcase your live queue in our staff app that has amazingly detailed information for them to assist the customer, understand them, and upsell products for higher AOV's.