Native integration boundaries
The Customer App can present experiences that depend on device capabilities, Ordering services, or external services. Source presence alone does not prove that an integration is configured, available, authorized, or able to complete.
One integration has several gates
Treat each gate as a separate decision. Passing one gate does not pass the next.
| Gate | Owner | What it establishes |
|---|---|---|
| Release inclusion | Release and native-platform owners | The approved app variant contains the intended integration code. |
| Public configuration | Product and configuration owners | The current experience may present an integration entry point. |
| Purpose and consent | Privacy and product owners | The intended data use is permitted for the current purpose. |
| Device capability and permission | Operating system | The device can present or allow a platform capability. |
| Account and resource authorization | Ordering services | The current customer may access the exact Ordering resource. |
| External handoff | External service | The service accepted a request or presented its own experience. |
| Ordering settlement | Ordering services | The authorized application result is durably reconciled. |
| Logout, withdrawal, or project change | App, Ordering, and external-service owners | Prior identities, tokens, callbacks, and cached state no longer apply. |
A permission result is not consent. A configured control is not authorization. An external-service success is not an Ordering settlement.
Integration classes
| Integration class | Customer App responsibility | Ordering-service responsibility | External or device responsibility |
|---|---|---|---|
| Analytics and advertising | Start only after the approved purpose gate; minimize event data; stop and clear state when required. | Define allowed events and data minimization. | Receive only approved events and apply its retention and deletion contract. |
| Fraud and risk | Collect only the approved device or account signal for an eligible action. | Bind the signal to the authorized customer and transaction without treating it as payment authority. | Evaluate the signal and return a bounded risk result. |
| Customer support | Open support only after an explicit customer action and current identity check. | Attest the support identity and limit shared account context. | Present the support experience and end the identified session when instructed. |
| Push notifications | Keep permission, preference, installation, and navigation state separate. | Bind the installation to the current app, project, account, and purpose; minimize notification content. | The operating system controls permission and presentation; the transport service controls delivery. |
| Maps and location | Request location only at an approved point and minimize coordinates sent outside the app. | Return only the authorized location and business data needed by the current journey. | The operating system controls location permission; map services control geocoding, maps, and directions. |
| Social sign-in | Present the provider choice and pass an opaque provider assertion to Ordering. | Verify the assertion, link the correct account, and issue the Ordering session. | Authenticate the external account and return a provider result. |
| Payments | Present an eligible method and pass only provider-approved opaque results. | Bind customer, cart, merchant, amount, currency, callback, and final order settlement. | The operating system or payment service owns collection, challenge, and provider authorization. |
| Media | Preview and confirm the intended image or attachment before an authorized upload. | Validate the target, type, size, audience, and retention policy. | The operating system controls the picker; the media service controls storage and transformation. |
The focused contracts for payment, social sign-in, and push notifications define additional boundaries. They do not make the other gates optional.
Lifecycle contract
An integration needs a complete lifecycle, not only an initialization call:
- Resolve the approved app variant, project, account, purpose, and resource.
- Keep the integration inactive until every required gate has passed.
- Bind callbacks and cached state to that exact lifecycle generation.
- Ignore a late result after logout, withdrawal, account change, project change, or navigation away.
- Remove or rotate external identity, installation, token, listener, and local state when the lifecycle ends.
- Re-authorize sensitive Ordering data before using a provider callback to navigate or display details.
Initialization success does not prove cleanup. Hiding an external-service UI does not prove that its identity, queued work, or stored data was removed.
Configuration boundary
Use only an approved public configuration contract to decide whether an entry point may be presented. Do not infer runtime enablement from a package import, native manifest entry, build placeholder, source constant, provider key, or another Customer App experience.
Configuration must not supply application authorization, a customer identity, a payment result, or permission consent. Treat missing, stale, malformed, or unrecognized public configuration as unavailable until the responsible owner recertifies it.
Verify without contacting a provider
A safe verification plan substitutes every external boundary before the Customer App screen mounts. It should prove:
- zero external-service calls before the approved gate;
- zero calls after withdrawal, logout, or an account or project change;
- no real customer, location, message, media, payment, or device data;
- one current identity and callback generation with late results ignored;
- no secret, token, private identifier, or provider payload in logs or output;
- a local unavailable or error state when the provider is denied or absent;
- cleanup of listeners, timers, queued work, cached identity, and reserved test state.
Provider availability, delivery, challenge, or settlement needs a separately authorized integration test. It is not part of documentation verification.
Troubleshoot by observable state
Start with the owner of the state that is visible. Do not use one layer to infer the status of another.
| Observable state | First responsible owner | Safe disposition |
|---|---|---|
| An expected entry point is absent | Release, product, and public-configuration owners | Keep the integration unavailable; do not infer a provider outage. |
| A device permission is denied or blocked | Operating-system and native-platform owners | Show a local unavailable state; do not repeatedly prompt or contact the provider. |
| A control is visible but the handoff is unavailable | Product, Ordering-authorization, and external-service owners | Recheck the separate gates; visibility is not entitlement or readiness. |
| An external handoff returned but the app is still pending | Ordering settlement owner | Keep the result pending or unknown; do not repeat the external action. |
| The account or project changed during a handoff | Session and integration-lifecycle owners | Discard the old result and clear its callbacks, identity, and reserved state. |
| Logout or withdrawal leaves an integration active | Privacy and provider-identity owners | Keep the integration blocked until teardown is proven. |
| An unexpected destination, message, or media resource appears | Routing, content-security, and media owners | Fail closed without opening, rendering, or forwarding it. |
| A substituted provider returns an error in verification | Integration owner | Verify the local error and cleanup state; do not switch to a live provider. |
Recertification triggers
Repeat the responsibility and lifecycle review after changes to:
- App, shared-components, Ordering-service, or release-artifact authority;
- native dependencies, manifests, permissions, schemes, or build variants;
- public configuration filtering, integration eligibility, or project/site selection;
- consent purposes, policy version, withdrawal, or data minimization;
- account, session, device-installation, token, callback, or project teardown;
- map/location, media, support, analytics, fraud/risk, social, payment, or push boundaries;
- external destinations, callback interpretation, retry/recovery, or Ordering settlement; or
- logging, screenshots, diagnostics, retention, deletion, or redaction rules.
Public documentation boundary
Public documentation can name the responsible layer, the pre-action state, the required gates, and the evidence needed for recertification. It must not include setup values, credentials, tokens, private identifiers, provider payloads, callback formats, live endpoints, or instructions for exercising a live customer or provider account.
For focused boundaries, see Configuration and experience boundaries, Consent and privacy choices, Platform and accessibility considerations, Payment boundaries, Social sign-in boundaries, and Push-notification boundaries.