The most important thing to understand: when Shift4 rejects an order, the payment has still processed. The order reaches the POS and the customer's card is charged before Shift4 evaluates whether it can accept the order. If it's then rejected, that rejection is not communicated back to AppFront — so the order may not show up in your normal AppFront order view, even though the customer was charged and believes their order went through.
This means the customer has no idea anything went wrong. They placed the order, saw a confirmation, and will show up expecting their food. If this isn't caught and reconciled proactively, the first sign of a problem is usually a customer standing at the counter with a receipt you can't find.
Why orders get rejected
Shift4 rejects online orders when something in the order doesn't match what's currently active on the POS/Workstation. The most common cause is a modifier mismatch — a modifier set is inactive or configured differently on the Workstation than what's published in the online menu. Other reasons Shift4 lists include:
Items marked inactive or out of stock on the POS but still live in the online menu
Missing or mismatched required order information (order type, tax, or surcharge settings not fully configured in Marketplace settings)
Gift card tender enabled in Online Ordering but inactive in POS
Open discounts or surcharges disabled on the POS side
A system exception while creating the order (rare — usually requires escalating to Shift4 with logs)
The common thread: almost every rejection traces back to a gap between what's configured in AppFront Menu Manager and what's actually active on the Shift4 Workstation. Keeping those two in sync — especially modifiers and item availability — is the single best way to prevent this.
Real example: Location X
In August 2026, a pickup order at Location X was rejected on the POS due to a modifier mismatch between the AppFront menu and Shift4. The customer arrived to pick up the order and showed staff that it had gone through successfully on their end — but the location couldn't find any record of it, because the rejection was never communicated back to AppFront. The payment had processed; it just wasn't visible in the normal order view. The transaction had to be traced directly in Shift4's backend to confirm the charge and resolve the situation with the customer.
How to handle it
If a customer says they placed an order you can't find:
Don't assume the payment didn't go through — check Shift4 directly for the transaction before telling the customer anything was declined.
Cross-reference the order time and amount with Shift4's transaction log.
Once confirmed, either fulfill the order manually or issue a refund per How to Process a Refund in Shift4.
Audit your Menu Manager against the Shift4 Workstation for inactive or mismatched modifiers and items to prevent this from happening again.
For the full list of Shift4 rejection error codes and how to resolve each on the POS side, see Shift4's own article: Resolve Rejected SkyTab OLO Orders.