Custom Ordering Website + Existing POS: What to Check Before You Build

TL;DR

• A branded ordering website does not automatically require custom development. Identify the customer or staff workflow that a ready-made option cannot support.
• Reading menu data and submitting orders are different permissions. Confirm the actual account, locations, integration route and payment options before accepting a build estimate.
• Test the complete basket for the selected branch: item identifiers, required choices, prices, availability and fulfillment time. A successful API response does not prove all those checks happened.
• Keep payment status, POS order creation and kitchen handling distinct. Define what the customer sees when money has moved but the order's outcome is still uncertain.
• Require a demonstration of corrections, repeated requests and failed handoffs. Include the people, access and procedures needed to operate the connection after launch.

‍

Start with the ordering requirement, not a POS replacement

For example, suppose a restaurant group wants a new website for two locations. Customers should choose a branch, customize a meal and book a collection time. Staff want those orders in the POS they already use, without retyping a confirmation email into a till.

That is a brief to test, not proof that the group needs custom software. Start with the POS vendor's ordering product and supported ordering partners. Syrve already advertises branded websites and apps as part of its delivery offering. Having your own brand on the checkout is therefore not, by itself, a reason to build one from scratch.

Ask a candidate to demonstrate the actual basket and branch rules. Custom work becomes worth considering when a required journey, business rule or connection remains unsupported, and the restaurant is prepared to maintain the missing component. The result might be a custom storefront with a supported connector, rather than a new ordering backend and payment system as well.

The two-location example and the proposed checks below are hypothetical. They do not describe a Caemcore client project.

Confirm order-writing access before commissioning the interface

Ask the POS vendor or implementation partner to confirm the exact product, edition, region, locations and operations available to the restaurant's account. Reading a menu does not establish permission to create an order. A developer's access to a demonstration account does not establish production access for your locations either.

Toast distinguishes standard, custom and partner integrations. Standard API access is read-only. Its custom integration route supports organization-specific work by an internal team or trusted technology partner, with access requested through the restaurant's Toast account representative. Do not treat purchasing standard access as completion of the order-submission prerequisite.

Syrve describes a different route. Its Simple Order Injection guide, published in May 2025, describes integration profiles, menu mapping, order creation and status updates for external ordering channels, and presents the capability as available to Enterprise customers. Confirm the applicable edition, enablement and configuration with the supplier rather than interpreting that guide as unrestricted access for every account.

Before approving the build, request evidence for menu retrieval, order submission, status retrieval and the chosen payment flow. Record any missing permission or vendor approval as an unresolved dependency, with someone responsible for obtaining it. A price can be conditional on that dependency; a promise that it is already solved cannot.

These examples explain why access needs checking. They are not a claim that Caemcore holds a Toast partner certification or that either vendor has approved a particular project.

Give each part of the order an owner

In the hypothetical two-location build, keep the POS responsible for its catalogue and accepted orders. Let the website manage the customer's shopping journey, with a server-side ordering service performing the supported checks and transfers. Existing vendor services may supply some or all of that ordering service.

Use this responsibility map to discuss the proposed solution. The final column is evidence to request, not a claim that every POS exposes the same capabilities.

Do not make the website another place where staff independently maintain sellable items, prices and order status. Public descriptions and photos can have a separate editorial owner, but they need a stable connection to the records used to order food. Our guide to connecting business systems without replacing them covers the broader ownership and recovery decisions.

Validate the whole basket, not just the product name

Use a representative item with a required choice and a paid extra. Check the product identifier, size, modifier group, permitted combinations and quantity rules for the selected location. Two branches selling a meal under the same name do not establish that its identifiers, price or available options are interchangeable.

Syrve's order-injection guide describes mapping external menu identifiers and an optional check that rejects orders whose submitted prices differ from the restaurant's prices. Decide which configuration applies to your channel and what customers see when a basket needs updating.

Toast has a more specific pricing requirement. Its order-price documentation identifies the /prices endpoint as the supported way to determine the payment amount for a check. It also says that API orders do not automatically receive service charges: the integration must include the applicable ones. A copied list of item prices is not the full checkout calculation.

For the example, have the server validate the selected basket through the agreed pricing process before payment. Present any changed amount or unavailable choice to the customer before they commit. Repeat the check when a change of branch, collection time or basket contents affects those conditions. Do not silently substitute a different product to make a request pass.

Keep the accepted basket and its amount with the order history. That gives staff something specific to compare when a customer questions an extra charge or an omitted modifier.

Check whether the restaurant can fulfill the order

Treat stock, menu availability, service hours and capacity as separate requirements. A dish may exist in the catalogue but be unavailable at the selected branch. A branch may be open while a particular collection slot is no longer offered.

Toast's Orders API overview says the API does not check restaurant service hours or item availability based on time, menu visibility or inventory. The integration has to enforce those conditions. Successful order creation is therefore not evidence that the proposed collection time or item was available.

Toast also distinguishes stock updates from menu updates. Its documentation says scheduled future orders from the Orders API decrement quantity-based stock when fired to the kitchen, not when created. A current stock count must not be presented as proof that an item is reserved for a later order.

Ask who can pause ordering for one branch, change the offered preparation time or remove an unavailable option. Define what happens when an availability source cannot answer. The business may choose to stop the affected checkout or use a clearly communicated staff-confirmation process. That is an operating policy to approve and test, not an invisible assumption in the connector.

Decide what counts as restaurant confirmation

Write separate meanings for payment confirmed, order created in the POS and order routed into the restaurant's fulfillment process. Then map customer-facing messages to the evidence actually available. Do not show "the kitchen is preparing your order" merely because a payment succeeded.

The POS's own behavior matters. Toast documents direct kitchen routing when a restaurant uses a kitchen display system and a correctly configured auto-firing device. In that configuration, API orders are not held for manual approval. A proposed website cannot assume staff will review each order before it reaches the kitchen.

For the two-location example, test the destination branch, fulfillment type, requested time and kitchen ticket or display. Check how the restaurant knows an order failed to reach the expected place, and who contacts the customer. Where automated receipt confirmation is unavailable, state the actual operational check rather than inventing a reliable-looking status.

Keep notifications in the scope too. The Toast Orders API overview says API-entered orders do not initiate its SMS notifications. Verify who sends each confirmation or readiness message, what triggers it and how repeated events are prevented from sending misleading updates.

Work through the paid-but-unconfirmed order

Confirm the payment arrangement with the POS and payment providers before choosing a checkout library. Establish who takes the payment, which methods the integration supports, how it is represented in the POS and who can reverse it. An order-writing API is not permission to attach any payment processor or reuse every native payment feature.

As a payment-handling example, Stripe's Checkout fulfillment guide requires webhooks rather than relying only on the customer's return to a success page. The customer can pay and lose connectivity before that page loads. It also requires handling repeated, potentially concurrent attempts to fulfill the same Checkout Session. This is an example of payment confirmation, not a statement that Stripe is an approved choice for a particular POS integration.

Now suppose the hypothetical restaurant's approved design takes payment before submitting the POS order. The POS creates the order, but its response never reaches the website. The customer sees a delay. Sending another new order or asking them to pay again could duplicate work that already succeeded.

The proposed system should retain the website order reference and payment reference, mark the POS outcome as uncertain, and use the supported lookup or retry procedure to establish what happened. Toast requires unique external identifiers and rejects submissions containing identifiers already used for another order, check or selection. That behavior is useful to understand, but a rejected repeat request does not itself complete reconciliation or prove the intended kitchen outcome.

If the result remains uncertain, put it in a staff-visible queue with a named responder. If the order was definitely rejected and will not be fulfilled, follow the agreed cancellation and payment-reversal process. Do not label a refund complete until the responsible provider confirms its status. The payment sequence may differ for another integration; the unresolved outcome still needs an owner and a recovery rule.

Stripe's webhook documentation separately warns that events may be delivered more than once and out of order, and requires signature verification. Have the developer distinguish repeated notifications from genuinely new orders and verify current state before applying a delayed update. A late payment event should not silently reopen an order staff have already resolved.

Give the supplier one end-to-end demonstration script

Run these checks with synthetic customers, test payments and a non-production POS environment or vendor-approved test arrangement. Identify the kitchen destination first so the rehearsal cannot create real food tickets or messages to customers. Have both the integration lead and a restaurant operator take part.

1. Complete the ordinary order. Choose a branch, an item with a required modifier and a paid extra, and an offered collection time. Trace the confirmed basket and amount through payment, the POS record and the kitchen destination. Staff must find the order from the customer's website reference without re-entering it.
2. Change the basket's conditions. Make an option unavailable after it has been added, change the selected branch and try a time outside its ordering rules. Check that the basket is revalidated and that any correction is explained before a new payment commitment. An invalid combination must not become a different meal silently.
3. Lose the response after order creation. Simulate the POS saving the order while the response is lost. Repeat the customer's submission and a payment notification through the supported test tools. Recover the original result without creating another charge or kitchen ticket; show how staff find the uncertain order.
4. Fail before the restaurant can fulfill. Simulate a rejected order or an unavailable destination. Verify the customer message, staff alert, branch-pause control and the agreed payment outcome. Check that restoring the connection does not release an expired or cancelled order into the kitchen.
5. Cancel and reconcile. Follow the agreed cancellation path for a test order, including a partial refund if that is in scope. Compare the website record, POS record and payment record using their identifiers. Confirm what changed in each system and which actions remain pending.
6. Hand the problem to the operating team. Give an operator a stalled order without coaching them through developer logs. They should be able to identify its branch, customer-facing reference, payment state, last known POS outcome and next action. Verify that their permissions do not expose unrelated branches or payment administration they do not need.

Record passed, failed and untested results separately, together with the tested configuration. These checks are a proposed acceptance exercise, not a complete security or payment certification. Require the normal functional, access and release testing as well.

For daily reconciliation, keep website, POS and payment references connected. Matching totals alone cannot explain a missing order and a duplicate of the same amount. Our guide to multi-location reporting explains how source definitions and reconciliation affect the figures staff rely on.

Compare the full scope before accepting a price

Ask the quote to separate the customer interface from catalogue work, order integration, payment handling, testing, rollout and ongoing support. Include recurring vendor access charges and any supported connector the design keeps. A website-design quote is not comparable to delivery of an operating ordering channel.

Identify whose work each dependency requires. The restaurant may need to clean up modifier configuration; its POS partner may need to enable the order source; the payment provider may need to approve the chosen flow. Keep those dependencies distinct from the developer's implementation schedule.

Start the rollout with a bounded, representative scope and a way to pause new orders while preserving accepted ones. Name the person handling incidents during trading hours and agree how the previous ordering route remains available during the switch. Do not turn off the old path while open orders still depend on it.

If the vendor's existing ordering product passes the required journey, use it. If a supported connector closes the only gap, price that smaller project. A custom website is justified by the ordering work it makes possible, with a demonstrated route into the existing POS and a workable plan for the orders that do not go through normally.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Not sure what you need? A 30-minute call, free: what the task actually is, whether it needs building or an off-the-shelf tool covers it, a range and a timeline. You get that whether we work together or not.

FAQ

Can the new website run alongside delivery marketplaces?

Yes, when the POS and integration arrangement support the channels you retain. Give each order a traceable source and test whether menu changes, stock updates and order limits reach every channel that needs them. Keep existing channels running during a controlled launch. A new direct-ordering site does not by itself justify switching off a channel customers already use.

Can one website connect to different POS systems across locations?

Potentially, but assess each connection separately. Establish which system receives each branch's order, how its menu and payment rules differ, and which customer features all selected branches can support. Do not promise one combined basket across incompatible fulfillment or payment arrangements without a separate design. A shared website can offer consistent navigation while keeping branch-specific ordering rules explicit.

Should customer accounts and loyalty be included in the first release?

Include them when they are necessary for the chosen ordering journey, not merely because the old site has a login button. Test balance lookup, redemption, earning and reversals through the proposed integration before promising continuity. Where those features are not required, a supported guest-checkout route can reduce the first scope. State clearly which existing benefits customers can and cannot use.

Can customers change the pickup branch after paying?

Treat that as an operational change, not an edit to the delivery label. The other branch may have different products, prices or a separate payment account. Define whether staff can transfer the order through supported operations or must cancel and place a new one. Preserve the original references and resolve the payment outcome before telling the customer the move is complete.

What should the restaurant retain if the developer stops supporting the website?

Retain control of the domain, hosting, relevant vendor accounts and recovery contacts, plus the agreed rights to the code. The handover should include menu mappings, configuration instructions, alert routing and procedures for stalled orders and refunds. Test the export of orders and their POS and payment references. A code archive alone does not show that another team can operate the ordering channel.

Sources

• Syrve, Restaurant delivery software. Checked 15 September 2026.
• Toast, Toast integration types. Checked 15 September 2026.
• Toast, Custom integration overview. Checked 15 September 2026.
• Syrve, How Syrve Works #2: Order Injection. Checked 15 September 2026.
• Toast, Order prices. Checked 15 September 2026.
• Toast, Orders API overview. Checked 15 September 2026.
• Toast, Stock overview. Checked 15 September 2026.
• Toast, Creating orders. Checked 15 September 2026.
• Stripe, Fulfill orders with hosted Checkout. Checked 15 September 2026.
• Stripe, Receive Stripe events in your webhook endpoint. Checked 15 September 2026.

Platform details were checked on 15 September 2026 using the vendors' own documentation. These are capability examples, not hands-on integration tests or confirmation of access for a particular restaurant. The two-location scenario, responsibility map and test script are hypothetical. They are not Caemcore client results or a complete payment, security or regulatory assessment.

‍