P4P Pizza4People

Current tool source / Shared reference stack

P4P Reference Modules

Right now the public Pizza4People tools come from one shared reference provider inside the repo.

Back to provider catalog Module catalog GitHub provider reference

For a pizzeria

The current menu, order, and operator pages come from one shared reference stack, not from a big live marketplace of outside vendors yet.

What it is

A shared reference provider for the first customer pages, operator tools, simple pay-at-pickup flow, and local test modules in the current proof.

What it is not

Not a live certification authority, not a marketplace full of competing vendors, and not proof that every declared module is production-ready.

What this covers right now

One shared reference stack behind the current public site.

For a shop: The current menu, order, and operator pages come from one shared reference stack, not from a big live marketplace of outside vendors yet.

Good first pages for a shop

  • Edit menu and prices The restaurant can change names, prices, categories, and whether an item is active.
  • Simple online menu A customer opens a normal menu list and sends the order directly to the restaurant.
  • Order status page A customer can check whether the order was accepted, rejected, or is ready for pickup.
  • Pay at pickup / cash The restaurant can keep payment simple by taking cash or direct in-person payment outside the protocol.

Not yet: No broad provider marketplace yet. No certification layer yet.

Current modules

What this provider publishes right now.

What the customer sees

These are the public surfaces a customer can actually open during discovery and ordering.

  • Order status pageA customer can check whether the order was accepted, rejected, or is ready for pickup. Shown in proof.
  • Simple online menuA customer opens a normal menu list and sends the order directly to the restaurant. Shown in proof.
  • Clickable photo-style menuA customer taps a paper-menu style surface instead of a plain item list. Shown in proof.

What the shop uses behind the counter

These are the restaurant-side tools for menu control, kitchen flow, stock, printing, and fallback alerts.

  • Edit menu and pricesThe restaurant can change names, prices, categories, and whether an item is active. Operator-side prototype.
  • Scan a paper menuThe restaurant can scan a paper menu into draft catalog rows before a human review. Operator-side prototype.
  • Kitchen order queueStaff can see incoming orders and move them through kitchen states. Operator-side prototype.
  • Operator email alertThe system can send an email when an order needs attention or a printer flow fails. Planned next.
  • Operator SMS alertThe system can send a short phone alert when an order or printer problem needs fast attention. Planned next.
  • Bell or light alertA local box can ring, beep, or flash when a new order or hardware problem needs attention. Operator-side prototype.
  • Print to kitchen or POSAccepted orders can later be printed or forwarded to a restaurant-owned printer or POS surface. Planned next.
  • Backup printer pathIf the first printer path fails, the order can be rerouted to a second print target or local spool. Operator-side prototype.
  • Ready-for-pickup boardA simple local screen can show which direct orders are accepted or ready at the counter. Operator-side prototype.
  • Final stock checkThe system can do one last local stock check before the next order step continues. Operator-side prototype.

Payment and business trust

This is where payment stays intentionally simple and where identity or business verification can later become reviewable.

  • Pay at pickup / cashThe restaurant can keep payment simple by taking cash or direct in-person payment outside the protocol. Shown in proof.
  • External MobilePay adapterA future external adapter can expose a familiar MobilePay-style pay-at-pickup instruction without making P4P the payment processor. Planned next.
  • Business identity checkA later trust layer can connect a node identity claim to a Danish CVR lookup or trust claim. Trust direction.

Internal tests and future extras

These modules are not the live restaurant offer today. They are internal test scaffolding or planned next-step pieces.

  • Ugly-case payment testerAn internal mock for timeouts, wrong amounts, duplicate callbacks, and other payment chaos scenarios. Internal test only.
  • Fake payment testerAn internal mock can randomly accept or reject a test payment during local debugging. Internal test only.

Technical record

p4p.reference

Status: unsigned-reference

Supported lanes: public_capability, operator, trust

Current module count: 18

Website: https://github.com/DennisHedegreen/p4p

This local page is the P4P-readable surface. The GitHub reference and raw manifest remain the developer-facing source material.

Back to provider catalog / Open GitHub provider reference / Open raw provider manifest

Contact

Questions about who stands behind these tools?

Questions about this provider page, module ownership, or the live-pilot boundary: hedegreen.research@gmail.com.

Public proof front door: https://pizza4people.com/.

Broader protocol-family direction: https://protocols4people.com/.