Square Pickup Quotes and Checkout Links Are Different Steps

A Square pickup quote and a checkout link represent different steps. A quote helps the caller review items and a total. A checkout link creates a way to pay for a specific proposed pickup. Neither, by itself, means the restaurant has accepted the order or started preparing food.

Burki's optional Square pickup workflow is deployment-dependent and requires additional authorization. Its current evidence is Sandbox-based. Use the following distinctions to evaluate the workflow without turning test results into live restaurant promises.

Start with a complete quote

Before checkout, confirm the items, supported options, quantities, location and requested pickup time. A caller who changes one of those details may need a new quote rather than an old total repeated with new wording.

A quote does not reserve inventory or create an order. The assistant should say what the quote represents and wait for the caller to approve the complete proposal before requesting checkout.

The Square integration guide separates menu, quote and pickup actions. Give each assistant only the relevant permissions; a menu-only assistant should not gain checkout capability merely because the workspace has authorized it.

Check the pickup prerequisites

Optional pickup needs the appropriate Square access, a selected location, explicit workspace enablement and individual assistant actions. The business must also review preparation settings, the maximum total and whether the location's configured hours are suitable for pickup.

An administrator granting Square permissions is not the same as the business enabling a particular assistant to create checkout links. Keep those decisions separate and review them together before use.

Square's official Checkout API guide describes hosted payment pages. Card entry belongs on the supported hosted page; callers should not read card details to the voice assistant.

Review who is allowed to change those settings and how staff will notice when a location or authorization change requires another check.

A hypothetical quote-to-link conversation

Imagine a caller choosing two items for pickup. The assistant prepares a quote and reads the items, total, restaurant location and proposed pickup time. The caller confirms those details.

Only then does the workflow request the unpaid checkout. If the caller wants the link sent by SMS, that is another action with its own consent and messaging prerequisites. A created link does not prove that the text arrived, that the customer opened it or that payment succeeded.

This hypothetical sequence illustrates the decisions. It is not a live Burki restaurant-ordering result, and a simulated browser interaction does not create the Square order, payment link or text.

Keep the states visible to staff

Staff should be able to distinguish quoted, checkout creation unconfirmed, payment pending, paid and cancellation or review states. A single green “success” label cannot communicate all of those meanings.

If checkout creation is uncertain, inspect the existing checkout before making another one. If an unpaid checkout remains unresolved, changing merchant or location should not be used as a shortcut around cleanup.

The customer-facing language can remain simple: “The payment link is ready” is different from “payment received,” and both are different from “the restaurant accepted your pickup.”

Review the final business outcome separately

Restaurant fulfillment remains a separate process. Even when payment is received, the team needs to know how the order reaches the people who prepare it and how acceptance is established.

The restaurant use-case page should lead buyers to this operational review rather than implying that a payment integration automatically completes the kitchen workflow.

For a controlled Sandbox review, inspect the quote, created checkout, current payment status and fulfillment status independently. Do not rely on an old checkout-creation response as proof of the current payment state.

Before enabling a broader workflow, ask staff to describe exactly what each status allows them to tell a caller. If they cannot distinguish a quote from a paid and accepted pickup, improve that operating language first. It is the foundation for honest voice answers and manageable exceptions.