A marketplace promotion is useful only if you can understand what happened to the order after it reaches your POS. The guest total should make sense, eligible items should remain identifiable, and you should know where to find the restaurant’s and marketplace’s shares of the discount.
The POS does not necessarily have to display every funding detail for an integration to be workable. But if a detail is missing, you need another reliable record and a person responsible for matching it. Test the exact marketplace, restaurant location and POS connection you plan to use before deciding whether the process is acceptable.
Record the offer and who pays for it
Start with one real promotion you expect to run, then describe it in plain language. Record the channel, location, offer dates, eligible items, discount amount or percentage, and any minimum order or other conditions. Note whether the offer can be combined with another promotion.
Next, record the intended funding split. A restaurant-funded discount reduces the restaurant’s contribution from the order. A marketplace-funded share may be accounted for separately. A shared offer needs both amounts identified. Do not assume that the guest-facing discount line explains how the offer is funded or how it will appear in a settlement.
Use the promotion’s written terms and the channel’s order and settlement records to establish what you expect. If the funding split or the handling of delivery charges is unclear, mark it as an open question rather than guessing. Ask the marketplace and integration provider which record will show each amount.
Map the connections for each location. A restaurant may use the same marketplace at two stores but have different POS setups, menus or promotion terms. The restaurant integrations directory is a starting point for checking connections; confirm availability and the particular setup with the provider. A listed connection alone does not establish how a promotion transfers.
Build a safe sample and compare the totals
Use a simulation, sandbox or vendor demonstration that cannot create a real card charge, guest message or courier dispatch. Give the sample a unique identifier, such as TEST-PROMO-A, so you can match the source order to the POS and kitchen result. Do not put a real guest’s personal information in the test record.
Hypothetical example: A sample order contains a $24 entrée and a $6 side, for $30 in items. A $6 promotion applies to the eligible items: the restaurant funds $4 and the marketplace funds $2. Add a hypothetical $3 delivery charge and a $2 tax amount. The expected guest total is $30 − $6 + $3 + $2 = $29.
Those figures are for checking the transfer, not predicting a settlement. The $29 is a guest total, not restaurant revenue or a payout. The example excludes fixed software costs, variable processing or marketplace charges, and exception costs such as refunds or manual corrections. The $2 tax amount is an input for this test, not a tax calculation or advice about how a promotion should be treated.
The table below turns that example into expected results. Before a demonstration, leave the observed result as “not yet checked.” Afterward, replace it with the actual value and the record where you found it. A match on the final total matters, but it is not enough if the discount or funding cannot be explained.
| Field | Expected sample result | Observed result | Follow-up |
|---|---|---|---|
| Items before discount | Entrée $24; side $6; subtotal $30 | Not yet checked | Confirm items and modifiers reach the POS. |
| Promotion | $6 off eligible items | Not yet checked | Identify the discount line and eligible items. |
| Funding | Restaurant $4; marketplace $2 | Not yet checked | Find each share in a POS, channel or settlement record. |
| Charges and total | Delivery $3; tax $2; guest total $29 | Not yet checked | Compare source and POS amounts; explain any difference. |
Ask the provider to show the source order, the POS result and the kitchen result for the same identifier. Check that the entrée, side and any selected modifiers are recognizable. Kitchen staff need the correct food instructions even when they do not need to see the funding split.
Then try a second safe scenario with a condition relevant to your offer, such as an ineligible item alongside an eligible one. Ask what should happen if the promotion is rejected or cannot be mapped. An unsupported case is a limitation to document; it is not automatically a failure if your restaurant can avoid that case or handle it reliably.
Check the fields that reach the POS
Walk through the order from the marketplace screen to the restaurant POS system, field by field. For the promotion, look for a name or code, amount, eligible item association and any distinction between restaurant and marketplace funding. Ask whether each value is transferred automatically, entered manually or available only in another report.
Some systems may show a single order-level discount rather than an item-level allocation. That can still be usable if the guest total is correct and the restaurant can identify the offer and funding elsewhere. It becomes harder to investigate when several offers run at once or when only part of an order is changed. Ask to see how those situations would be identified in the records you actually receive.
Compare the tax amount on the source order with the amount shown in the POS. Also check the delivery charge and other displayed fees separately from the discount. Do not force a match by relabeling one amount as another. If a field differs, ask which system supplies it, whether the difference is expected and how it is corrected. For questions about the tax treatment of an offer, consult a qualified tax adviser.
Check the workflow around exceptions as well as the original order. Ask what information is available when an order is canceled, partially refunded or adjusted after acceptance. Can staff connect the adjustment to the original promotion and funding record? If a provider cannot demonstrate an exception in a safe environment, record the remaining question and agree how it will be checked before relying on that workflow.
For a channel-specific discussion, bring the same worksheet to an Uber Eats integration conversation or to the provider for your actual channel. Ask for the exact marketplace, POS and location combination rather than relying on a generic promotion example.
Agree on reconciliation and make the decision
A useful funding record may live outside the POS. Ask which order identifier appears in both the marketplace record and the POS, and which report or settlement record shows the funding shares. Confirm when those records become available and whether staff can retrieve them for the same promotion period.
Turn each gap into an assignment. For example, the integration provider can explain which fields transfer; the marketplace can clarify where its funding appears; and the restaurant manager can decide who will match orders to settlement records. Give each question an owner and a decision date. Keep a short record of the answer, the report name and the steps staff must follow.
Decide in advance what counts as acceptable. One restaurant may accept a separate funding report if the order identifier matches and a manager can review it routinely. Another may need the split visible in a particular report because of its existing closeout process. In either case, an unexplained guest total, missing item instructions or no reliable way to identify funding should remain open until resolved.
For the hypothetical $6 offer above, suppose a demonstration shows the correct $29 total and item details, but the POS shows only one $6 discount. If the marketplace also provides a matchable record showing the $4 and $2 shares, a restaurant willing to reconcile that separate record could consider the setup workable. If no matchable funding record is available, defer the decision or choose a different workflow; the correct total alone does not answer who funded the offer.
Keep simulated checks separate from a live service pilot. Once the safe checks meet your criteria, agree with the providers on any limited live pilot, including staff responsibilities and how to handle actual orders and exceptions. A live order can have real operational and financial consequences, so do not use one as a practice scenario.
Next step: Bring your channel list, locations, POS details and completed test cases to a Fleksa demo. Ask to see the promotion transfer and funding records for your setup, and confirm availability for each location.
Frequently asked questions
Does the discount funding have to appear in the POS?
Not necessarily. A separate marketplace or settlement record may be workable if it identifies the order and funding shares and your staff can reconcile it. Decide whether that manual step fits your closeout process.
Is a matching guest total enough to approve the integration?
No. Also check items, modifiers, the discount, charges, tax amount and the location of the funding record. A correct total can conceal a mapping problem that makes reporting or corrections difficult.
How can I test a promotion without affecting guests?
Request a simulation, sandbox or demonstration that cannot trigger a real card charge, guest message or courier dispatch. Use a unique test identifier and compare the source, POS and kitchen results without real guest information.
