This is
the playbook.

Your pre-service checklist.

YallaBill runs at pos.ashik.ai: these pages, the merchant workspace, staff boards and every restaurant storefront share one address. The homepage tour is a simulation; Ashik Lounge is a real storefront served by the live ordering system.

1. Sign in as the owner. Open Merchant sign-in with the owner credentials configured for your installation. Never share one staff account across the whole team.
2. Set the restaurant profile. Profile holds the name, address, public slug, time zone, ordering switch, tax confirmation and payment settings. Owners add more locations from the same page.
3. Add your team. Team creates owners, managers, kitchen, runner and counter accounts with their own passwords (12+ characters). Roles decide which boards a person can open.
4. Bring a menu. Menu studio accepts schema-valid JSON (paste, upload, or load the demonstration menu); Imports turns PDFs or menu photos into a draft when Azure Document Intelligence and an Azure AI Foundry model are configured. Save a draft, review it, then publish.
5. Prepare payments. Enter the restaurant's eligible Stripe connected account in Profile, confirm tax configuration and, if applicable, record hookah approval. Checkout stays closed until this is done.
6. Set up the floor. Tables creates unique QR codes; print the cards. Register each kitchen, bar, runner or counter device in its own browser from Status.
7. Run a full rehearsal. Order, fulfill, call a server, pay, split a bill and refund. Test on actual phones and tablets before enabling live service.

Let AI do the first pass.

1. Configure the server-side Document Intelligence and Foundry endpoints, keys and model deployment. Keep credentials out of browsers, HTML, Git and screenshots.
2. In AI menu imports, choose the correct food, drinks or hookah section and explicitly submit a photo or PDF. Use clear, readable source documents you have permission to process.
3. Review the extracted text, warnings and draft. Check names, prices, taxes, quantities, modifier limits, station routing and restricted-item flags.
4. Apply the reviewed draft to Menu studio. Applying a draft is not publishing.
5. Make any final edits, check availability, review tax configuration and explicitly publish.

Document Intelligence extracts text and layout; a separate language model interprets the result into the versioned menu schema. Missing configuration or provider errors should be fixed, not treated as a successful import.

Images, descriptions and safety

Optional description enrichment must not change prices, taxes or modifiers. Merchant photos can be uploaded; illustrative AI images require a separately configured image deployment and human review. Never infer allergens, ingredients, health claims or dietary suitability from product names.

Prefer an external workflow? Import schema-valid menu JSON, or export the menu and its JSON Schema. The application exposes the schema at /api/menu-schema.

Your account. Verified payments.

"Connect" means configure an existing eligible connected account; automatic OAuth onboarding is not being promised.

1. Set the backend to PAYMENT_MODE=stripe, with a server-side Stripe secret key and the webhook signing secret.
2. Set PUBLIC_URL to the deployed application's reachable HTTPS origin. Use https://pos.ashik.ai only after the backend actually serves that hostname.
3. Enter the restaurant's acct_... connected-account ID. It must support card payments and merchant-paid processing fees (controller.fees.payer=account, typically Standard). A different account ID does not fix incompatible account settings.
4. Register a Connect webhook at /api/webhooks/stripe for the connected-account checkout, payment and refund events used by the backend. Use this endpoint's signing secret.
5. Review taxes, merchant policies, restricted-business eligibility and your processor's configuration before enabling live ordering.

Card entry happens on Stripe-hosted Checkout. Apple Pay appears only where supported by the account, device, browser and transaction. Returning from checkout or opening a payment link is not proof of payment; wait for server-confirmed payment status.

Refunds aren't invisible

Rejecting an ordinary order line stops that line's preparation and refunds its quantity, modifiers and allocated tax; the original tip and application fee remain. A full ordinary-order refund includes the remaining tip and application fee. Split-tab and combined-bill allocations follow their specific payment records; use the app's scoped refund controls and reconcile each contribution.

Pending refunds are not completed refunds. Stripe may retain its original processing fees. Never substitute application totals for the processor's settlement report. Read Stripe's direct-charge documentation.

Give every table a front door.

1. Publish the approved menu in the application. A restaurant menu lives at /s/your-restaurant.
2. Create each table in Tables & QR. The app generates a unique token that connects orders and service requests to that table.
3. Copy the full link, such as https://pos.ashik.ai/s/your-restaurant?t=ACTUAL_TABLE_TOKEN. This is a format example, not a working table link.
4. Download the app's QR or paste the actual link into this site's table QR generator. Label, download and print the card.
5. Scan every printed code on a phone. Check restaurant, table, menu and ordering state before putting it on the floor.

Changing the domain, restaurant slug or table token can invalidate printed links. Plan the final hostname before a full print run. If a table is retired, disable its ordering link in the workspace.

At the table. At the counter.

Authorize the actual counter device

An owner or manager signs in on the counter tablet, selects a location and kiosk name, and chooses Authorize & sign out of management. Staff then select their own name and enter their own six-digit PIN. There is no default PIN. Lock the kiosk between staff members.

The server validates current prices, modifier constraints and availability. An old browser view is not a price guarantee. If a submission result is uncertain, recover the original request rather than recreating items and risking duplicates.

Give every ticket a clear path.

1. Accept. Kitchen and bar see eligible tickets with their original placement time. Accept the order and review modifiers and notes.
2. Prepare. Work in the appropriate station view. Rejected items and refund state remain explicit; one rejected line needn't erase the rest of the order.
3. Mark ready. A ready ticket joins the runner queue. Runners can also see a read-only preparing look-ahead.
4. Claim & deliver. A runner claims responsibility, completes applicable age/service checks and marks the order delivered.
5. Follow progress. Guests track order status; the team uses the operational boards. Payment and fulfillment are separate states.

Call a server, without waving

On a valid table-linked menu, a guest can send a service request. Staff acknowledges and resolves it. A request is not a new food order or payment, and a device being online is not evidence that a person acknowledged it.

Keep tablets in the loop

Register each physical tablet in its own browser, with a recognizable name and station. Active screens poll every three seconds. Keep devices awake, visible and connected; browsers can suspend background tabs. Offline/stale status must be treated as unknown service connectivity, not a green light.

Enable and test optional sound alerts on each operational screen. Readiness estimates need sufficient recent history and are estimates, not promises. Closing a service's finished-ticket stack archives the view, not underlying orders or unpaid tabs.

Room for another round.

A staff-created dine-in open tab explicitly authorizes service before payment. Ordinary unpaid guest checkouts do not have that permission.

1. Select the table and guest in the POS, add items, and choose Keep tab open.
2. Return to that same tab for additional rounds. Only new unsent batches go to preparation; older tickets aren't resubmitted.
3. When ready to settle, choose either a frozen combined bill or the live shared-bill workflow.

A frozen combined bill

Send or remove unsent batches, confirm the guest-approved tip, and choose Freeze bill & get payment link. One immutable bill covers the saved items. Extras after freezing need a new tab.

Show its checkout QR, copy/open the payment link, or send a transactional SMS if Twilio is configured and the guest explicitly consents. A provider accepting the SMS request is not a delivery guarantee. Recover an expired or uncertain checkout using the original payment-link recovery action rather than making a duplicate bill.

A live shared tab

Choose Split bill to share a visit-specific bill with the party. Staff may continue adding rounds while guests pay reviewed contributions. This is different from freezing a combined bill.

Everybody gets a fair share.

1. Staff opens the shared bill and gives its link or QR only to the party. Anyone with that link can view the shared bill and public contribution activity.
2. Guests choose items or shared portions, split equally, choose a percentage or custom amount, or pay the remainder.
3. Each guest reviews item allocations, tax, any disclosed restaurant service fee and their own optional tip before authorizing payment.
4. A payment in progress reserves its amount against other checkouts. Reserved does not mean paid. The provider must confirm it.
5. After the last payment and the last round, staff explicitly closes the tab. A temporary zero balance does not automatically release the table.

A percentage contribution uses the displayed bill snapshot. If the bill changes, review again before authorizing a new payment. Previous payments and receipts aren't silently rewritten by a later round. Tips belong to their payments and don't reduce the meal's unpaid balance.

The restaurant may configure its own separately disclosed service fee where legally and contractually permitted. It is not the YallaBill application fee. Configuration records the merchant's decision; it doesn't establish legal or processor approval.

Try the equal-split simulation using the final step of the tour. No real payment is collected.

Meet guests where they already are.

The simplest option is a direct link to your published restaurant menu. An iframe can display that menu inside your website once the live application and hosting policies permit it.

1. Use the restaurant URL, without a table token. Website visitors should not accidentally order to a particular physical table.
2. Generate a snippet with the embed builder and paste it into your site's HTML block.
3. Ensure your website's frame-src permits the app and the app's frame-ancestors allows only your approved website origin(s). Conflicting X-Frame-Options headers must be handled on the app, not weakened globally.
4. Keep the included Open menu & order in a new tab fallback. Use a top-level window for hosted checkout if the provider/browser will not run it inside the frame.
5. Test mobile sizing, scrolling, service context and checkout on actual browsers. A generated snippet does not validate those integration requirements.

<iframe
  src="https://pos.ashik.ai/s/your-restaurant"
  title="Our restaurant menu"
  width="100%"
  height="760"
  loading="lazy"
></iframe>
<a href="https://pos.ashik.ai/s/your-restaurant"
   target="_blank" rel="noopener">
  Open menu & order in a new tab
</a>

This is a placeholder URL. It won't work until the application is deployed and that restaurant exists. The marketing website's own frame policy is separate; it is not the menu app.

One address. A staged launch.

Going live with payments

1. The deployment starts in Stripe sandbox mode. Guests can browse, build carts, choose tables and follow the tracker, but a checkout is refused until the restaurant profile has an eligible connected account and confirmed tax settings.
2. To accept real cards, an operator replaces the platform's secret key and Connect webhook secret in Key Vault with live-mode values and restarts the revision. Only then enter the production acct_… connected account in Profile.
3. Verify the webhook, one real order, one refund and the receipt e-mail flow before opening the doors.

Menu intelligence

PDF and photo imports, description enrichment and image generation use Azure Document Intelligence and Azure AI Foundry. They are optional and are enabled by adding the service endpoints and keys to Key Vault and the container configuration; until then Imports shows a setup notice and JSON menus remain fully supported.

Clear about what happens here.

• The interactive tour uses bundled sample menu and order data. It doesn't call AI providers, upload documents, notify staff, create accounts or charge money.
• The QR generator renders the URL you enter locally in the browser. It doesn't invent table tokens or check whether your destination is live. Anyone scanning the downloaded or printed QR can open that URL.
• The embed builder creates code locally. It doesn't fetch your menu or test your server's frame policy. Keep bill-sharing links out of public embeds.
• No analytics or lead capture is configured in these pages. The selected theme is kept in the URL. Hosting providers may still process ordinary access logs and connection metadata according to your deployment.
• Live application processing is separate. Explicit menu imports send selected documents to configured AI services. Checkout uses your configured payment provider. Optional SMS sends to the provider only after staff obtains the guest's transactional consent.

Before launching a real service, publish the business's reviewed privacy notice, terms, refund policy and contact information. This product guide is not a substitute for those business-specific documents.

Brand resources: download the original YallaBill SVG logo or the editable social artwork. Built by Ashik.ai.