Merchant-scoped credentials
Server credentials resolve to an explicit merchant boundary. Browser-supplied merchant identifiers do not establish authorization.
Security
Security boundaries are part of the API model.
MemberConsole makes merchant scope, commercial state, customer access, and event integrity explicit on authenticated server paths.
Merchant authorizationCredential scoped
Checkout authorityServer resolved
Event integritySigned delivery
Customer accessVerified identity
Control plane
Apply authorization at the request boundary.
Merchant scope, customer access, pricing, and event verification stay on trusted server paths throughout the request lifecycle.
Database authorization
Customer-sensitive and merchant-sensitive records are protected by authorization controls, with privileged writes kept behind trusted backend paths.
Server-authoritative commerce
Pricing, merchant ownership, routing, and other material checkout decisions are validated on trusted server paths before they become canonical.
Signed event delivery
Outbound merchant events carry identifiers, timestamps, and signatures so consumers can verify authenticity and handle retries safely.
Customer identity boundaries
A verified customer can connect eligible purchases without giving one merchant access to another merchant's records.
Canonical state
Orders, payments, refunds, subscriptions, receipts, and fulfillment remain attached to an authoritative commerce model for reconciliation.
Request boundary
A merchant request should prove its context before it can touch commerce state.
The platform derives merchant identity from authenticated server context, validates the requested resource inside that scope, applies trusted configuration, then returns or mutates only records that belong to the authorized boundary.
Read the API key guide1. Authenticate
Resolve the server credential to a merchant scope.
Authorization2. Authorize
Check the requested product, order, or action inside that scope.
merchant_id3. Resolve trusted state
Validate price, currency, ownership, and route configuration.
server state4. Commit canonical state
Persist the authoritative record before downstream notification.
canonical5. Deliver signed events
Notify the merchant endpoint independently with retry-safe IDs.
signatureWebhook integrity
Verify first. Process second.
Merchant consumers should verify the event signature and timestamp before processing the payload, persist or deduplicate event IDs, acknowledge valid deliveries promptly, and move longer work to their own background jobs when practical.
Signature verificationTimestamp validationIdempotent consumersRetry aware
Webhook verification model
const signature = request.headers.get("Webhook-Signature")
const timestamp = request.headers.get("Webhook-Timestamp")
const eventId = request.headers.get("Webhook-Id")
verifySignature({
body: await request.text(),
signature,
timestamp,
secret: process.env.MEMBERCONSOLE_WEBHOOK_SECRET
})
if (alreadyProcessed(eventId)) return new Response(null, { status: 200 })Treat duplicate delivery as normal retry behavior, not a second business event.
Engineering checklist
Apply the same controls in production.
Keep credentials, commerce state, and event verification consistent across code, configuration, testing, and operations.
Credentials
Keep secret keys server-side
Rotate credentials deliberately
Never infer merchant scope from browser input
Separate customer and merchant authorization
Commerce state
Resolve amounts on trusted paths
Use canonical order identifiers
Verify provider state server-to-server
Do not make redirects authoritative
Events
Verify signatures and timestamps
Deduplicate by event identifier
Expect retryable delivery
Keep consumers safe to replay
Need implementation-level guidance?
Use the Resources hub for API keys, checkout, merchant orders, webhook verification, testing, refunds, and fulfillment guidance.
Found a security issue?
Send a focused report with the affected route or endpoint and safe reproduction steps. Avoid including passwords, raw payment credentials, private keys, or unrelated customer data.