Delight Food Cafe POS

Restaurants in Pakistan are required to file invoices electronically with the tax authorities. That turns a till into an integration problem: every bill has to reach a government endpoint, in the right format, with the right seller identity attached.

The obvious implementation is also the wrong one. If the POS submits the invoice before completing the sale, then every time the authority's gateway is slow or offline the restaurant simply stops trading — at the till, during service, with a queue waiting.

The system needed to satisfy the filing requirement without ever putting a government API between a customer and their bill, while remaining a complete POS for a working cafe.

A point-of-sale application built around one architectural decision: a sale is recorded first and filed second.

Fiscal filing that cannot stop trading

When a bill is saved, the POS writes a fiscal invoice record per enabled authority and pushes a queued job to make the actual HTTP call. A network failure never rolls back the sale — it leaves a failed record that is retried automatically. For operators legally obliged to refuse unfiled sales, a Block Sale On Failure setting makes submission synchronous instead and surfaces the rejection to the cashier.

Both the Punjab Revenue Authority and FBR Digital Invoicing are supported, each with its own endpoint, credentials, seller identity and sandbox toggle. Every integration has a Test Connection action that posts a probe invoice and reports exactly what came back, so a wrong endpoint or expired token is found in configuration rather than during service.

Configuration instead of hard-coding

Business identity, tax numbers, invoice number prefix and padding, receipt footer, currency, receipt QR codes, standard and card tax rates, and inclusive versus exclusive pricing are all settings. API tokens and passwords are encrypted at rest with the application key rather than stored in plain text.

The rest of the till

Sales with counter management and barcode support, purchasing with purchase returns, product and category management, and expense tracking by category.

Customer and supplier accounts

Running ledgers for both customers and suppliers with payments recorded against them, so credit balances and outstanding amounts stay accurate rather than being reconciled separately.

Deployment and reporting

The POS is installable as a progressive web app for tablet use, with a desktop build packaged through NativePHP for counter terminals. Reporting spans sales, purchases, expenses and ledgers, with PDF receipts and reports and spreadsheet export.

Every bill is filed with the relevant authority without the till depending on that filing to complete a sale — a gateway outage produces a retry queue rather than a stopped restaurant.

Endpoints, credentials, tax rates and seller identity are all configurable per deployment, so the same system serves other restaurants without code changes, and connection problems are diagnosable from the settings screen.