White-label platforms

Channel provisioning supports a platform-owned merchant journey, while the public checkout-session response can carry buyer-safe branding. Treat branding as presentation data; it does not change credential ownership, merchant scope, or the payment state machine.

Boundaries

• Keep the channel key in platform server infrastructure.
• Associate each merchant with your own tenant record and send X-Merchant-Id only from that trusted mapping.
• Create checkout sessions on the server from authoritative order data.
• Allow only the exact merchant origins that host embedded or direct checkout.
• Keep payment, refund, dispute, and webhook records partitioned by merchant even when your UI presents a unified platform brand.

Choose Hosted Checkout, Embedded Checkout, or the published maxanapay.js SDK for the production product surface, subject to each presentation’s documented capability limits. Presentation does not change the need for server-side credentials and reconciliation.

Current limits

PayPal’s seller-onboarding consent screen identifies maxanapay as the partner, not the channel. That is the production application’s name; sandbox runs a different PayPal application and shows a different name. The buyer’s later PayPal payment window uses the merchant’s own business name, so this branding exposure is limited to seller onboarding. A channel cannot replace that partner identity through the current onboarding operation.