A customer calls and says the website won’t take their payment. Before you assume the platform is broken, work through this. Most of the time the cause is either a gateway setting on your side or the customer’s own bank, and those two need opposite fixes.

First, the mechanics. Online payments (Microsite, Branded App, QR ordering) don’t touch a card reader at all: your gateway, Shift4 or NMI, tokenizes the customer’s card or Apple Pay / Google Pay directly in their browser. The gateway then needs an upfront authorization before the order is confirmed and routed to your kitchen. If that authorization doesn’t come back approved, there is no order. Nothing prints, nothing appears in your queue.

Quick checks (try these first)

  1. Ask the customer what they actually saw. Three different symptoms, three different causes. “My card was declined” points at their bank. “The button spins forever” points at a connection problem. “The page showed an error” usually points at a setting on your side. Get the exact wording before you troubleshoot.
  2. Place a test order yourself. Open your own Microsite (<slug>.eatsyorders.com) from your phone, on cellular data, not your store Wi-Fi. Add an item, pay with your own card, and take it all the way through. If your test order goes through cleanly, the problem is specific to that one customer. If it fails too, the problem is on your side and affects everyone.
  3. Confirm your gateway is connected and live. In admin.eatsyorders.com, go to Account → Settings → Payment providers and confirm Shift4 or NMI shows as connected, and live, not in test mode.

If you just launched, check test mode first. A gateway left in test mode is the classic day-one cause. It's also the fastest one to rule out: two clicks in Account → Settings → Payment providers, then one real test charge to prove it.

Diagnose the root cause

Hypothesis 1: the gateway isn’t connected, or is still in test mode

Your payment gateway (Shift4 or NMI) has to be connected and live before it can authorize a real card. In test mode it accepts nothing from real customers. Note that this is separate from your Shift4 POS integration: the payment gateway and the POS connection are configured independently, so one can be healthy while the other isn’t.

How to verify. admin.eatsyorders.com → Account → Settings → Payment providers. Your gateway should show as connected and live. Then run one real test charge on your own card, exactly as described in the Pre-Launch Checklist.

How to fix. If it shows disconnected or in test mode, reconnect it and switch it live. If you can’t tell which state it’s in, don’t guess: contact your onboarding manager or support before you take more orders. Once it’s live, run the test charge again to confirm.

Hypothesis 2: your restaurant is offline

Online ordering needs your location to be reachable. During an internet outage, customers don’t get a payment error: they get a “site temporarily unavailable” message, which appears automatically about 30 seconds after the outage is detected. Customers often report this to you as “I couldn’t pay.”

How to verify. Load your own Microsite from a phone on cellular data. If it shows the unavailable message, you’re offline. Card payments in the restaurant will also be failing at the same time, since card readers route through Shift4 or NMI and need internet to authorize.

How to fix. Work through Internet outage during service. Until you’re back online, in-person sales can continue in cash through the iPad Menu app, which completes cash transactions locally.

Hypothesis 3: checkout is blocked by something that isn’t payment

Customers describe any blocked checkout as “I can’t pay,” even when the card was never the issue. Common non-payment blockers: an item in their cart was 86’d (they see “currently unavailable” and the item is pulled from the menu), they’re ordering outside your hours of operation, they’re outside your delivery zone, or their cart is under your delivery minimum.

How to verify. Ask what was in the cart, what time they tried, and whether they chose pickup or delivery. Then reproduce it: build the same cart, pick the same fulfillment option, and use their address. Check the item’s status in admin.eatsyorders.com → Menu management.

How to fix. Depends on the blocker. If an item shouldn’t be 86’d, reactivate it. If your hours, delivery zones, fees or minimums are set differently from how you actually operate, confirm the correct settings with your onboarding manager and have them updated. If the customer is simply outside your footprint, offer pickup.

Hypothesis 4: the customer’s bank declined the authorization

If your own test order goes through, your gateway is live, and you’re online, the decline came from the customer’s issuing bank. Eatsy and your gateway can’t override a bank’s decision, and the reason for a decline sits with the bank, not with you.

How to verify. Check your gateway dashboard (Shift4 or NMI) for the attempt. If the attempt reached the gateway and came back refused, the card itself was refused. If nothing reached the gateway at all, treat it as Hypothesis 5.

How to fix. Ask the customer to try a different card, or to pay with Apple Pay / Google Pay, which the gateway tokenizes the same way through the browser. If it still fails, they’ll need to call their bank. In the meantime you can save the sale: take the order for pickup and let them pay at the counter, where the iPad Menu supports cash and card readers. Cash on delivery is off by default and only your onboarding manager can enable it per zone, so don’t promise it unless it’s already on for that zone.

Hypothesis 5: the customer’s browser or device is stuck

If it’s one customer, your test order works, and nothing shows up in your gateway dashboard, the payment attempt never left their device.

How to verify. Ask whether the spinner ever resolved, and whether anything at all appeared on their bank statement. No gateway record plus no charge means the attempt didn’t complete.

How to fix. Ask them to try a different browser or a different device, and to reload the page before rebuilding the cart. Apple Pay / Google Pay is also worth trying, since it skips manual card entry. If several unrelated customers report the same stuck checkout on the same day, stop treating it as customer-side and contact us.

Charged but no order. If a customer says money left their account and no order reached you, check your gateway dashboard (Shift4 or NMI) for authorizations with no matching order, and refund anything that doesn't correspond to a real order. This is most common right around a connection drop.

When to contact us. If your own test order fails, or if more than one customer reports the same failure in the same day, open a support ticket right away. Email support@eatsyorders.com or call +1-929-413-3080 and include the time of the attempt, the channel (Microsite, Branded App or QR), what the customer saw on screen, and whether anything shows in your gateway dashboard.