We’re building an integration for restaurants that receive orders from delivery platforms (DoorDash, Grubhub and similar). The customer has already paid the delivery platform — no money moves through us or through the merchant’s Square account. Our integration creates an order on the merchant’s Square so a kitchen ticket prints at their station, sorted into the kitchen’s preparation sequence.
Because the order is already paid for elsewhere, we would record the line items at zero price and attach an EXTERNAL payment of $0 purely to close the order so it doesn’t sit on the merchant’s open orders list.
I’ve read the existing thread confirming the 1% fee is billed to the developer account and assessed on the amount passed as the EXTERNAL payment rather than the order total.
My question: if the EXTERNAL payment amount is $0, is the fee assessed as 1% of $0 — nothing — or against the order total or some other basis?
And a related one: if we instead recorded the real menu prices on the line items while still attaching a $0 EXTERNAL payment, which figure would the fee follow?
We want to understand the cost structure accurately before building. Thanks.
One more angle, since our case may differ from the earlier thread on this fee.
That answer described the obligation as sitting with the platform “integrating via the Orders API with a non-Square payments provider.” We aren’t a payments provider and we aren’t integrating one — the delivery platform took the payment entirely outside our system, and we’d be recording EXTERNAL purely as a bookkeeping entry. Does the 1% still attach to us in that case?
Also worth saying: we haven’t built against Square yet. If zero-priced line items or $0 EXTERNAL payments aren’t workable to begin with, that’s equally useful to know before we design around them.
Could you describe the use case / ideal flow a bit more? We only attribute the order fee to one party and in this flow it sounds like that fee would lie with the surface that took the payment rather than your application.
Happy to lay it out concretely.
The flow:
- A customer orders from DoorDash (or Grubhub, Slice, etc.) and pays DoorDash. Neither we nor the restaurant is involved in that transaction.
- DoorDash notifies the restaurant. That notification reaches us — by email, or by webhook where the platform supports it.
- We parse the order, sort the items into the sequence that restaurant’s kitchen prepares them, and substitute the restaurant’s own kitchen shorthand for the platform’s item names.
- We create an order on the restaurant’s Square account so a kitchen ticket prints at their station in that sequence.
What we are: a back-of-house ticket formatter. We never see the customer, never touch money, and hold no payment credentials of any kind. No funds move through us or into the restaurant’s Square account — DoorDash pays the restaurant separately on their own schedule, entirely outside Square.
Why we’d record an EXTERNAL payment at all: purely so the order doesn’t sit unpaid on the restaurant’s open-orders list. It’s a bookkeeping entry, not a payment. We’d expect to record it as $0, since no money reached the restaurant’s Square account.
So the “surface that took the payment” is DoorDash, which has no Square relationship at all in this flow.
Two things that would settle it for us:
- Does the fee attach to us in this case, given we neither process nor receive payment?
- Is recording a $0 EXTERNAL payment the right mechanism for closing an order that was paid entirely outside Square — or is there a better-fitting approach for an order that’s already settled elsewhere?
Worth noting: we’ve since learned from another thread that an order needs a zero balance to trigger printing, and that a $0 EXTERNAL payment won’t achieve it — we’d need to record the full order total. So the amount at stake here is 1% of every delivery order’s full value, which makes this question decisive for whether we can build on Square at all.