Environments

Audience: anyone integrating Mooov. One page answering "which hostname, which key, and where do I test?". What to actually do in test mode (test cards, webhook checks, the go-live checklist) lives on the sandbox page.

Mooov has test and live environments on the same canonical API hostname. Merchant keys select their environment: mk_test_* for test and mk_live_* for live. Hostname, body, query and forwarded headers cannot override a merchant key. Connect platform keys use a different selection rule: the request selects an environment and must have an active merchant grant in that environment, as described below.

1. Canonical API host

Use https://api.mooov.money for both mk_test_* and mk_live_* keys. Test mode moves no real money; live mode does.

https://sandbox.api.mooov.money remains a temporary compatibility alias during cutover. It does not select the request environment. New integrations should use the canonical host only.

2. Credentials

A merchant key's environment is fixed at minting time. Merchant key prefixes make the environment greppable: a mk_test_ key leaked into a live config is spotted at a glance. Pair both mk_test_* and mk_live_* keys with https://api.mooov.money. Platform keys are shared across environments. For merchant-scoped Connect API calls, send ?environment=test or ?environment=live. Omitting this query parameter selects live. The gateway verifies an active grant for the selected environment before setting the request context. The key alone does not select test mode.

In the merchant portal, the global Test / Live control selects which environment's objects you see. That portal mode is independent of the public API request: merchant API callers use the key environment; platform callers use the environment query and the corresponding grant.

3. Separation rule

Payments and merchant webhook destinations are scoped to test or live within one merchant account. Merchant keys and Connect grants are also environment scoped. A shared platform key may access both environments when separate active grants authorize it.

Run Connect consent with mode=test for a test grant and mode=live for a live grant. Consent defaults to live when mode is omitted. A test grant does not authorize live charges. Token exchange returns the grant's environment; use that value when constructing subsequent API requests.

Customer/provider mappings are not yet environment scoped. Customer-backed and saved-method API flows are therefore blocked with test credentials; see the sandbox restrictions. Connect platform webhook fan-out is currently live-only; a successful test payment does not produce a platform webhook delivery.

4. There is no dry-run on live keys

Live merchant keys have no test flag, no magic test cards, and no dry-run header. The verification path is:

1. Exercise supported flows with merchant test keys or explicit Connect test grants on the canonical host, including failure paths, using the go-live checklist.
2. Complete activation and select the live merchant key or live Connect grant (same base URL).
3. Coordinate a low-value live smoke test, including webhook delivery and a refund when the enabled rail supports it.

If you find yourself wanting to "test something quickly" with a live merchant key, use a test key. Platform callers must explicitly select test and have a test grant. Check sandbox restrictions before planning coverage.

5. Switching

For merchant API calls, switch to the live key pair and configure the live merchant webhook destination and secret. For Connect, complete live consent and explicitly select ?environment=live; changing a platform key alone does not switch modes. Coordinate platform webhook certification separately because test fan-out is unavailable. The base URL and signing scheme stay the same. Quickstarts: merchants, platforms.