What it touches
Order total, fulfillment type, and operator payment destination.
Customer + operator side / Planned next
A future external adapter can expose a familiar MobilePay-style pay-at-pickup instruction without making P4P the payment processor.
For a pizzeria
Lets pilot restaurants say whether an external MobilePay-style adapter is worth adding after cash-first feedback.
Where it fits
This is where payment stays intentionally simple and where identity or business verification can later become reviewable.
This page is the readable P4P explanation for one module. It is meant to be understandable before you open the raw manifest.
What it touches
Order total, fulfillment type, and operator payment destination.
What it does not own
It does not make P4P hold funds, process cards, or become merchant of record.
Current state
not enabled; external-developer invitation only after cash-first pilot feedback
Current declared data-access summary: Order total, fulfillment type, and configured operator payment destination. No card or account credentials.
Read next
This only makes sense after you read the simpler cash-first lane that defines the current live boundary.
The payment adapter still sits after the direct menu flow, not before it.
The provider page keeps this as a planned adapter candidate, not a claim that P4P is processing money.
Technical identity
p4p.payment.mobilepayIf you need the developer-facing version, open the GitHub module reference or the raw manifest. The public P4P page stays focused on what the module means operationally.
Open provider page / Open GitHub module reference / Open GitHub provider reference / Open raw manifest
Contact
Questions about this module, the provider layer, or the live-pilot boundary: hedegreen.research@gmail.com.
Public proof front door: https://pizza4people.com/.
Broader protocol-family direction: https://protocols4people.com/.