Customer + operator side / Planned next

External MobilePay adapter

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

Payment and business trust

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

Planned next

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

Do not stop at one module page.

Start from the cash baseline

This only makes sense after you read the simpler cash-first lane that defines the current live boundary.

Then return to the customer order surface

The payment adapter still sits after the direct menu flow, not before it.

Keep the provider boundary explicit

The provider page keeps this as a planned adapter candidate, not a claim that P4P is processing money.

Technical identity

p4p.payment.mobilepay

If 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.

Contact

This module page is still part of the same narrow proof story.

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/.