We’ve built a custom ordering integration for their website using the Orders API, Payments API and Web Payments SDK, and we’ve hit a problem we can’t resolve from our side.
THE PROBLEM
Orders we create through the Orders API — collection orders, with a PICKUP fulfillment — always print on the kitchen printer as a customer receipt, showing “Paid”, “Receipt: #…”, and a “REPRINT AT” banner. They never print as an online order ticket, which is the compact format the kitchen works from.
The same printer prints in-person order tickets perfectly. So the printer, its profile and its connection are all demonstrably capable of producing order tickets. It’s specifically the online order ticket that never appears.
WHAT WE’VE ALREADY ELIMINATED
We ran nine test orders through the live location today. The result was identical every time — a customer receipt, never an order ticket — regardless of:
- Payment method (an external tender, and a real captured card payment via
the Web Payments SDK) - Fulfillment state (accepted/RESERVED, and left pending/PROPOSED)
- Line items (ad-hoc name and price, and mapped catalog_object_id)
- How the print was triggered (automatically, and manually from Order Manager)
- How much data we send (we stripped the payload to the bare minimum — no
source name, no recipient, no note — and still got a receipt)
Printer profile settings are correct: “Use this printer for online and kiosk order tickets” is ON, and “Automatically print new orders” is ON.
WHAT WE THINK IS HAPPENING
Two orders, minutes apart, on the same printer, with the same ticket name and the same single line item:
17:04 — created via Orders API, PICKUP fulfillment → long customer receipt
17:13 — rung up on the till, IN_STORE fulfillment → compact order ticket
The only material difference is the fulfillment type. We then tried to create an order with an IN_STORE fulfillment through the API and were refused:
HTTP 400 INVALID_ENUM_VALUE: Fulfillment type IN_STORE is not supported.
A PICKUP fulfillment is the correct type for a collection order and it’s what carries the collection time, so we’re not trying to misrepresent these as in-store orders. But if the order ticket format is tied to fulfillment type, that would explain everything we’re seeing.
WHAT WE’D LIKE TO KNOW
- What determines whether an order created through the Orders API prints as
an online order ticket rather than a customer receipt? - Is there a requirement on the payload, on our application’s permissions, or
on the location/device configuration that we’re missing? - Are online order tickets only produced for orders originating from Square
Online or other first-party channels? If Orders API orders can’t produce
them, please say so plainly — the seller needs to plan around it.
Separately, the printer profile warns that it’s in use by 3 devices and that each online order ticket would therefore print 3 times. We’d appreciate guidance on the correct way to have exactly one device route online order tickets to this printer.