Website integrations and external handoffs
The Ordering Website can start experiences that another service completes. Keep the customer on the project's canonical Website and preserve the exact provider-generated values instead of reconstructing tokens, callbacks, or payment state.
Handoff boundaries
| Handoff | Ordering Website responsibility | External responsibility |
|---|---|---|
| Payment | Present eligible methods, collect the customer's choice, and continue with the resulting order state. | Tokenize sensitive details, authorize or redirect payment, and return a provider result. |
| Maps and location | Request or accept the customer's ordering location and apply it to discovery and fulfillment. | Resolve map, place, or geolocation data according to provider and browser permissions. |
| Social sign-in | Show configured sign-in choices and continue with the returned account result. | Authenticate the external identity and enforce provider consent/security. |
| Push notifications | Register supported notification behavior and open an order when a notification includes an order destination. | Obtain notification permission and deliver messages to the browser/device. |
| Analytics and project code | Load configured tracking or project code after the required consent state. | Process data according to the project's provider configuration and privacy obligations. |
| Smart app banner | Show configured app-store destinations on supported devices. | Serve the store listing and installation experience. |
Payment handoffs
Available methods vary by project, business, country, customer, cart, and provider. Some methods remain inside the Website while others open a provider-owned redirect or embedded form.
- Never collect raw card data outside the supported provider component.
- Never copy a payment token into a URL, log, screenshot, or documentation example.
- Treat a provider result as pending until the Website displays the resulting order or error state.
- A visible payment method does not guarantee that the provider will authorize the transaction.
Authentication handoffs
A supported social or integration sign-in can be exposed by the current Website or supplied link. The Website can show a generic handoff and continue according to route and account state; a visible loading state or destination does not prove provider acceptance.
Do not build integration-login links by hand. Use the complete link or redirect supplied by the supported integration, keep it confidential, and do not assume it is single-use, time-limited, erased from browser history, or safe to reopen.
Location links
For a public discovery link, finite non-zero lat and lng values can initialize a location context.
The Website can then remove those values from the visible URL after applying the context. Browser or map
provider permission can still be required when the customer chooses automatic location detection.
Failure handling
- Return customers to the Website with the provider's supported result; do not invent callback parameters.
- Show the Website's verified failure state and preserve the cart or account context when supported.
- Do not promise provider uptime, authorization, identity acceptance, or delivery.
- Send server-side requests through the published API contract, not through browser-only handoff values.
Related references: Website routes and deep links · Website experience and configuration