Test mode

The mode is baked into the API key prefix:

• mrd_test_…: reads and writes test data only.
• mrd_live_…: reads and writes live data only.

A leaked test key cannot reach live data and vice versa. The prefix is the only source of truth, so you don't need to set a header or a base URL. Point everything at https://api.meridapay.com and the key picks the side.

Create keys for either side from Settings → API keys. The dashboard's mode toggle (top of the sidebar) controls which side you're viewing.

Test and live are independent on every object that holds money or customer data: products, customers, checkouts, subscriptions, invoices, meters, balances, webhook endpoints, webhook deliveries.

Things that are shared: your organisation, team members, branding, and account settings. Creating a product in test does not create one in live. You have to create it on both sides when you're ready to ship.

Use a test API key on the same /checkouts endpoint. The returned URL routes the buyer to the same hosted checkout, but the rail accepts test card numbers and never charges a real card.

curl -X POST https://api.meridapay.com/checkouts \
  -H "Authorization: Bearer mrd_test_..." \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "<test-mode-product-id>",
    "customer_email": "[email protected]"
  }'

Available test cards are shown on the hosted checkout page itself when the session was minted with a test key, so you don't have to look them up.

Register a separate webhook endpoint while the dashboard is in test mode. Test events fire to that endpoint only. Live events fire to the endpoints you registered in live mode. The signing secret is per-endpoint, so a leaked test secret cannot validate a live delivery.

When the integration works end to end in test mode, switch the dashboard to live, create the same products and meters, mint a live API key, and swap the key in your secrets store. The code does not change.