Things to note about webshops
Statement on customer and user data
The customers - often referred to as users in the eSolutions environment - are stored by Hypersoft programmes in Hypersoft databases and processed on Hypersoft servers. Nothing more, nothing less.
These are your customers and your users at all times.
Hypersoft does not pass on this data. You can export the data at any time and retain full control.
The legal relationship for the use of the data exists exclusively between you as the brand owner or provider and your customers or users who register or leave data.
You regulate this relationship yourself - for example via:
-
Your Imprint & legal information for eSolutions section
Hypersoft provides you with the technical basis for this, but does not interfere with your customer relationship.
We have deliberately chosen this concept in your interest:
Our services are designed to strengthen your brand, protect your investments and keep you independent and able to act.
Best practice: Use your own shop URL
By default, Hypersoft provides your shop or the shop in YourAPP via its own URL. This is ideal for getting started and can also be useful as a technical redundancy.
For sustainable brand development, however, we expressly recommend that all accesses be routed via your own domain or subdomain.
The reason is simple:
If accesses are made exclusively via the Hypersoft URL, your own domain will not benefit from these accesses in terms of search engine optimisation (SEO). The ranking then affects myhypersoftapp.de - not your brand.
With your own shop URL, your offer will appear in search engines under your brand owner domain.
In this way, you strengthen your visibility, remain independent of platforms and avoid precisely those dependencies that arise with many other channels.
Hypersoft has no interest in using the URLs provided for its own purposes or for the benefit of third parties.
Our goal is to strengthen your domain, not ours.
In the unlikely event that you wish to continue working without Hypersoft in the future, we assure you that the URLs provided by us will not be used elsewhere or assigned to third parties.
Your own shop URL - how it works
On request, we can add your own domain or subdomain to the Hypersoft URL for your shop - free of charge as part of our service.
Your shop is then accessible via two URLs.
The URL provided by Hypersoft is always:
https://ihr-wunschname.myhypersoftapp.de
Procedure
Let us know that you would also like to operate your shop via your own URL.
Hypersoft will send you the shop IP address.
Your IT department stores this IP in the DNS or domain administration.
You provide us with a valid SSL certificate in .pfx format including password.
We add the desired URL to your shop.
Important note
Please note that Hypersoft cannot accept any responsibility for the duration or renewal of your domain and SSL certificate.
Please contact us at least 14 days in advance in the event of changes - especially if the SSL certificate is about to expire. Otherwise, your shop may temporarily not be accessible via its own URL without errors.
In short
Your customers remain your customers
Your data remains under your control
Your domain should strengthen your brand
Hypersoft supplies technology - no dependencies
Conditionally offer items in eSolutions
There are many functions for offering or not offering item in certain cases. See the chapter on Targeted control of items- clever instead of always available and in particular the sections:
Limitations and methods for Webshop eSolutions
Allergens & nutritional values...
Allergens and nutritional values are calculated per 100g. A calculation per portion is currently not yet implemented. You have the possibility to store this information in the multifunctional item master and to have it partly applied automatically (in recipes). However, there is only one value per item and allergen/content, which does not change by queries.
Countries & Currencies...
- Technically speaking, Webshop 2.0 can be used across countries as long as these countries use the same currency (e.g. locations in Germany and Austria).
- If you operate locations with different currencies, you would have to set up a separate shop for each currency with the respective locations.
- Currently the Webshop 2.0 supports the following currencies: EUR, CHF, GBP
- For the legal use of the webshop we have only considered those countries in which the Hypersoft system is compatible. The same restrictions apply to the webshop as describedin the master information.
- The maximum number of an item in the shopping cart is limited to 99 pieces.
The webshop assumes that you have your own delivery service. External suppliers such as Lieferando can be linked as external links, but they are not directly connected to the webshop. Also a driver and route management is currently not yet implemented.
You have the possibility to use the connection to the deliverect delivery service channel manager also in connection with the web shop.
Negative prices and discounts on queries...
Discounting of extras, queries: At the POS, items are discounted at the end of the booking process, in the webshop (and SOT) the queries are already displayed discounted and thus charged individually. The different handling can lead to different results for the same items when booking at the POS and in the webshop. Example with an item price of 0.00 with 10 queries at 0.99 each and a discount of 10%:
If the item is sold with all extras, the price at the POS is 8.91 and 8.90 in the shop or SOT.
However, the items are not changed during the transport from the webshop to the POS, everything remains as booked.
Negative queries with discounting...
An item discount in combination with negative queries can lead to a negative total price. Example: An item for 10.00 is sold with an optional extra of -2.00. With an item discount of 90% and the selection of the negative extra, this results in a total price of -1.00 EUR.
Negative prices with extras or queries...
Negative queries can cause a negative total price. Example: If an item is offered for 10.00 EUR with 10 optional extras at -2.00 EUR each and all queries are booked, this can generate a total price of -10.00 EUR when fully utilised.
Locations...
Shop 2.0 requires either a system with one client (only one location), or a master client with several locations. Central clients with different data (such as different item masters) are currently not supported.
The webshop is therefore optimized for use with multiple locations. especially for brand owners with several locations, all strengths are played out.
Tickets & Vouchers...
The sale of tickets is currently not yet implemented.
VAT splitting...
Items with a VAT distribution are currently not supported by the shop and SOT.
Forced queries with only one selection...
Mandatory queries that contain only one selection will still be displayed by the Shop & SOT as mandatory selections. (And not skipped and booked automatically as at the POS).
Best practice: Guaranteed success with PayPal
PayPal is often viewed critically in the catering industry - mainly because of the higher fees compared to giropay. In fact, these fee models originate from the online mail order business, where they take extensive buyer guarantees into account. What is often overlooked is that it is precisely these mechanisms that have made PayPal one of the most trustworthy payment methods.
In Germany alone, over 30 million people use PayPal regularly. For many guests, PayPal is a familiar, secure and preferred payment method - especially in the digital environment. Doing without PayPal without risking a measurable loss of sales is only possible in exceptional cases with very specialised offers.
Practical observation
Practical tests in which PayPal was temporarily activated and deactivated showed a clear picture:
With PayPal activated, sales increased by well over 10 %. After deactivation, they immediately fell back to the previous level. Comparable effects were observed across all sectors.
The conclusion is clear:
Instead of excluding PayPal for cost reasons, businesses should play to their strengths in terms of product range, service and margin. Hypersoft provides a PayPal interface for this purpose, which you can activate yourself at any time using your own merchant data.
Errors in smartphone payment
Giropay is regarded as a particularly favourable payment method - and rightly so. However, giropay has not established itself in digital eSolutions scenarios and will only do so to a limited extent in the future.
The reason for this is the change in payment habits:
Many payment terminals and almost all smartphone payments do not support direct giropay
Apple Pay and Google Pay dominate the mobile payment market
For guests, payments look like giro card payments, but are often processed in the background via credit card or debit networks
In addition, the giro card itself changes:
Not all banks equip new cards with Maestro or VPay as standard. As a result, the debit card is declined more frequently - especially with modern terminals and mobile payments.
Invisible cards, visible consequences
With Apple Pay and Google Pay, cards are stored virtually as tokens in the smartphone. The retailer can no longer recognise which card is being used in the background. Strategies such as "We don't accept AMEX cards" no longer work reliably here.
The result is unpleasant situations:
-
Payments fail unexpectedly
-
Guests are irritated or annoyed
-
Employees in need of explanation
Modern payment terminals carry out risk analyses in milliseconds and automatically switch to another stored payment method if necessary. This intelligence should not be blocked by limited card acceptance.
An additional advantage:
Premium cards such as AMEX are often linked to restaurant credit and promotional programmes. Those who refuse these cards do not save any fees - but lose loyal guests who are willing to pay in the long term.
Conclusion
PayPal is not a cost factor - but a sales driver.
A modern payment strategy does not mean forcing the most favourable means of payment, but offering guests the expected choice.
Best practice means:
-
Accept PayPal
-
do not restrict modern payment ecosystems
-
Strengthen sales, guest satisfaction and brand perception
Further topics:
Best practice: Accept all payment methods - for better customer loyalty
Address logic in the ordering process
The following rules apply to delivery and billing addresses in the ordering process:
Delivery
At the beginning, the delivery address is entered, on the basis of which the available delivery locations are loaded.
The billing address automatically adopts the postcode and city of the delivery address; this information cannot be changed, other fields can be added.
To ensure correct delivery, the delivery and billing addresses must be identical.
If the delivery address and the billing address do not match, the delivery address will be used. A different address cannot be entered.
Retail orders
For orders with the order type Retail, the country selected in the shopping basket is automatically adopted as the country of the billing address and can no longer be changed.
A different delivery address can be entered. If this is available, it will be used; otherwise the billing address applies.
Voucher orders (by post)
For vouchers with the order type Postal dispatch, the billing address is used by default.
Optionally, a different delivery address can be specified.
General information
The display of the address fields and the mandatory fields continue to function as before.
Payments and transaction units
Please note that in connection with the webshop activities arise which also cause running costs, such as transactions, scheme fees, discounts, etc.).
In eSolutions we work with Hypersoft Pay powered by Adyen. You could integrate your PayPal account directly into the Adyen widget, then you will incur Adyen fees in addition to your PayPal fees according to the Adyen price list. Hypersoft has therefore integrated PayPal directly so that you can easily set up your PayPal merchant account there.
Deposit system with the webshop
The webshop incl. eSolutions Self-Order Kiosk (SOT) and Guest-Order-Terminal do not support MixMatch and therefore do not support the old method for deposits. The Deposit system must be used if required to enable the deposit to be accounted for.
Example for deposit can Cola 0,33l...
The deposit is set up by the deposit management on the Coke item.
The deposit is automatically recognised and shown by the shop, GOT and SOT.
Example of deposit in the menu (steak plate with can of Coke)...
The can of cola is listed as a query (or sole query) in the recipe. The deposit is set up on the can as in the first example.
Wrong set-up: No other "deposit item" may be deposited in a recipe.
Invoice dispatch
When your customers are supplied, you can use it to transmit the invoices. For the digital delivery of invoices, you can combine NoCOO with the webshop system. See Webshop invoice dispatch via NoCOO (Digital Invoice Directory)for this.
The bookings from the webshop are transferred to the POS system via the Online Order Connector. There you set up the handling of the tip. As a rule, you should (at least in Germany) set up the tip from the webshop to be taxed. For this purpose, you assign an appropriately set up item .
The POS system uses a static algorithm that makes this adjustment based on other criteria. Please see Book a tip. You can make settings to be able to enter tips in the webshop in the Tip in the webshop section.
They should attach great importance to the support of tips. Tips generally have a positive effect on all employees and their customer relationships, which in turn are relevant to their brand. Tax tips can be controversial. With an integrated system like the Hypersoft hybrid system of POS and portal functions, you have more possibilities to make the tip tax-free even in the web shop, otherwise this would usually have to be taxed (taxed tip is better than not being able to accept a tip). They must avoid to treat the tip untaxed, although it should be taxed. Please read the section Book a tip.
Procedure documentation for bookings between web shop and POS
Signing takes place at the checkout and therefore the sale of a voucher or item is not signed until it has been collected by the Online Order Connector via the control checkout and a basket of items is not signed until it has been released by the operator at the checkout (when he releases the transaction). Collection to the POS system is usually much faster than 5 minutes.
If an order has not been collected by the POS system after 5 minutes (also web voucher order), a notification is sent by eMail (see also emergency operation), which informs the recipient of the deposited mail address that an order has not been collected by the POS system within 5 minutes. This does not change the status of the order. This means that as soon as the checkout is (subsequently) switched on, the order is picked up and processed.
However, if you decide to use the emergency mode, then you have the option of viewing the orders in the portal in order to enter them again and manually at the POS. The manual capture is (of course) signed by the TSE. If you now also manually check the box Order transmitted to Pos for these orders in the portal, these bookings will no longer be transmitted to the POS when the connection is possible again. Otherwise, they would have to cancel the subsequent double transmission (not recommended). Decide on the desired procedure and file this in your procedure documentation.
Depending on the configuration, functions such as payment on collection can result in orphaned transactions if the user then does not collect these transactions. You can use the closing automation to handle such operations accordingly.
Use automatic transaction completion for eSolutions... Further topics:
Back to the overarching topic: eSolution Webshops