Searches can be filtered by several properties, including:
Specify the app_id parameter when searching, providing an App that's configured within Paytronix Online Ordering to list the desired restaurant results.
Restaurants, categories, and menu items all contain time-related properties to allow your application to determine when something is available.
Paytronix Online Ordering uses a 30-hour day format, so times can range from 12:00 AM - 6:00 AM the following day. Times are represented in minutes, so 8:00 AM would be represented as 480, and 1:00 AM the NEXT day would be represented as 1500.
We provide three price-range-related properties:
If you want to show dollar-sign representations within your application (e.g. $, $$, $$$), you may wish to translate price_range to a dollar-range, using buckets like 0-10, 10.01-15, etc.
Each menu item can have one or more prices. Our usual logic: If only one price is present, just show it. If multiple prices are present, take the smallest and largest prices, and show a range, like $10-14.
Merchant ID is the Paytronix assigned identifier for a Merchant, with Store Code being an identifier for an individual restaurant/location for that merchant. App ID is an Online Ordering assigned unique identifier for a merchant. Restaurant ID is an Online Ordering assigned unique identifier for a restaurant/location.
Merchant API that include {merchant_id} and {store_code} parameters in the URL path have
a fully equivalent Restaurant API that uses {restaurant_id} in the URL path instead.
Within an Order API request body, either {merchant_id} and {store_code} or
{restaurant_id} can be supplied. The schema documentation
for the POST /orders request body illustrates one example of this.
The "accepts" property on the restaurant contains a list of accepted payment types. In some cases, it may be simpler to hard-code your application to support a certain payment scenario, if you don't need the extra configurability.
We provide a short_id property (integer) that gives customers a friendly order identifier. This number is only unique to each restaurant, not the entire system, to help keep the numbers manageable.
Restaurant results will contain support_phone, support_email, and support_url properties to indicate where customers can get support. If these values are not present or are falsy (empty strings), then the application should usually fall back to the restaurant's phone number.
The submit_time property on the order will contain a timestamp once the order has been submitted.
When calling the order submit API, pass in the tip field with the desired tip amount. It will be added to the order and charged to the customer's card, if the order is prepaid.
In most cases, no. The order will contain properties for these values: subtotal, tax, and total_amount, respectively.
When calling the order submit API, pass in the order_date and eta values.
Yes, we will ensure that the date/time are not in the past, and that the restaurant is open for the appropriate order type (takeout/delivery).
No, due to several customers' requirements, if an order does not contain a date/time, we will allow it to be submitted. This allows customers to begin ordering shortly before closing, and submit their order without a problem if they miss the "open" window. Your application may check the current time against the restaurant's hours, however, and implement validation according to your desired rules.
Most data values are covered in the default API parameters. Restaurants may also configure custom data fields that can be submitted along with standard elements.
We do not currently maintain lists of time slots. Our order submission screens typically show 15-minute increments based on the available hours for the restaurant.
When creating a new order, you can specify the "coupon" property, or you can call the "Add Coupon" API after the order has been created/
The "card" property on the order will show payment method details, if the order was prepaid with a card.
The card details must first be tokenized via our PCI compliance provider, Spreedly. See the card data section for more details.
Send the "order_id" property in your request when creating a new order, and we will copy any available items over to the new order, along with their modifiers. See the API documentation for more details.
Yes, we run a zero-dollar authorization against new cards to verify that they work. This does not ensure that any funds are available, however.
First, tokenize the card with Spreedly, then call the Account API. See the card data section for full details.
Not at this time.
Yes, we provide an API for validating addresses against our address data providers. See the API documentation for more details.
No, we err on the side of allowing addresses, in the event that our database is incorrect. Worst-case scenario, the restaurant or delivery provider can contact the customer to sort out the proper address.