Key handling
- Never ship server API keys (
x-api-key,x-commerce-api-key) to browsers. - Use server-to-server auth for privileged merchant/commerce operations.
- Treat API keys as secrets: store them in environment variables or a secret manager, rotate regularly, and avoid logging them.
Browser-safe auth (payor flows)
Payor/session routes use browser-safe auth headers:x-session-tokenx-signature
ws_token minted server-to-server and passed as a websocket query param.
SDK safety defaults
Pepay SDK is designed to be safe-by-default in browser contexts:- By default, the SDK rejects server API keys in browser runtimes.
- Use session tokens / ws tokens for client-side integrations.
Idempotency and retries
Network failures happen. Use a consistent strategy:- Writes should include an
Idempotency-Key(the SDK auto-generates one by default). - Retries should respect
Retry-Afteron rate limits. - Prefer a single canonical “Errors” page and link to it from every endpoint page.
Wallet execution isolation (TEE)
- When Pepay performs wallet execution as part of embedded/agentic payment flows, signing is isolated from application code:
- Temp Wallet execution occurs inside a Trusted Execution Environment (TEE).
- Client apps and merchant servers do not receive raw key material.
Transaction submission and MEV resistance
On supported networks, Pepay will preferentially submit payment intents via:- Private / miner-protected routes
- Private RPCs / protected relays
- MEV-resistant paths where available
- This is best-effort and network-dependent (not every chain has equivalent private relay infrastructure).
- When private paths are unavailable, Pepay falls back to standard transaction propagation.