Provision merchant access
Set up the merchant boundary and the scopes your backend needs.
Developers
Build your product on a commerce layer you can reason about.
MemberConsole gives merchant backends a clean way to work with canonical orders, payments, refunds, fulfillment, subscriptions, and signed events. Start with the server integration guide, then use the Merchant API for current state and reconciliation.
API version 2026-09-01REST + JSONServer-side authenticationSigned webhooks
List orderscurl
curl https://api.memberconsole.com/v1/merchant/orders?limit=25 \ -H "Authorization: Bearer $MEMBERCONSOLE_API_KEY" \ -H "Accept: application/json" # Merchant identity comes from the credential. # Keep the key on your server.
GET /v1/merchant/ordersCanonical read path
Documentation
Go straight to the part you need.
The docs follow the integration work. Start with the server contract or jump directly to authentication, events, or API surfaces.
01 · START HERE
SDK & webhook guide
The full server-side implementation contract for signatures, retries, event handling, idempotency, and reconciliation.
Read the integration guide 02 · APIMerchant API
Read canonical orders, payments, refunds, subscriptions, events, and operational state inside your merchant scope.
Explore API surfaces 03 · AUTHAPI keys & environments
Understand merchant-scoped credentials, server-only secret handling, scopes, rotation, and production access.
Read authentication guide 04 · EVENTSWebhooks
Verify signed events, acknowledge quickly, tolerate retries, and keep downstream systems safe when events repeat.
Open webhook docsQuick start
From merchant credentials to production.
Your server authenticates the merchant. MemberConsole holds canonical commerce state, and signed events tell your systems when that state changes.
Get API access
Store the API key server-side
Keep the live credential in your server environment or secret manager, never a browser bundle.
Verify signed events
Read the raw body, validate timestamp and HMAC signature, then claim each event ID once.
Test recovery paths
Exercise duplicate events, failed requests, refunds, fulfillment updates, downtime, and reconciliation before launch.
Merchant API
A focused API for operational work.
Merchant credentials carry explicit scopes. Use the API for canonical reads, operational updates, event inspection, webhook tooling, and reconciliation while keeping merchant authorization on the server.
Orders & fulfillment
GET /ordersGET /orders/:orderPATCH /orders/:order/fulfillmentPOST /orders/:order/shipmentsMoney & subscriptions
GET /paymentsGET /refundsPOST /orders/:order/refundsGET /subscriptionsEvents & operations
GET /eventsGET /events/:eventPOST /events/:event/replayGET /webhook-endpointsGET /integration-healthRequest and response behavior
The SDK guide covers event envelopes, signature verification, idempotency, retries, reconciliation, framework examples, secret rotation, and production testing.
Trust model
Authenticate on the server. Verify before you act.
Merchant identity comes from the authenticated credential, not a browser-provided merchant ID. Webhook consumers verify the timestamp, signature, and event ID before applying business effects, and the Merchant API remains available when your system needs current canonical state.
Merchant scopedServer authoritativeRetry safeSigned events
Have an integration question that the docs do not answer?
Tell us what you are building and which commerce surfaces need to stay in sync. For customer account or order-access questions, use the Help Center instead.