Environments
A key, a connection, a policy, a webhook endpoint and every record belong to exactly one environment; test is where every workspace lives today, and nothing converts to live.
Written for developers and the people who hold the keys.
Two sets of objects
Test and Live are not two views of one thing. They are separate provider credentials, separate webhook secrets, separate encryption contexts, separate audit trails, separate policies and separate API keys. Every list and every API call names its environment through the x-pehmen-environment header, which defaults to test.
An API key is minted for one environment and its prefix says which: pehmen_test_ or pehmen_live_. A key that names the other environment in the header gets 403 environment_mismatch. A key can only be revoked from its own environment.
How a credential is bound
The provider credential decides the environment, not a setting:
| Provider | Test binding | What is refused |
|---|---|---|
| Stripe | Key prefix rk_test_ | rk_live_ and sk_live_ (LIVE_KEY_IN_TEST_ENVIRONMENT); any sk_ secret key (SECRET_KEY_NOT_ALLOWED_USE_RESTRICTED); unknown shapes (KEY_PREFIX_UNRECOGNIZED) |
| HitPay | The sandbox host, api.sandbox.hit-pay.com | Nothing to refuse by shape; a test connection cannot reach the production host by construction |
| Airwallex | The sandbox host, api.sandbox.airwallex.com | Same |
The refusal happens before anything is stored, by the key's shape, not by a policy someone could edit.
The seeded demo
The seeded demo is a test workspace populated with synthetic sellers, payments, decisions, payouts and cases, running on Pehmen's own provider test accounts through pooled demo connections. It is for reading, and for running the dashboard's own flows. Its credential is read-only and rate-limited; payout release on a pooled demo connection is refused; and nothing in a demo workspace ever counts toward activation.
Your own workspace is different: your own sandbox credentials, your own data, your own keys.
What Live requires
Live is fully built and gated. A workspace needs an entitlement granted by two platform administrators under dual control, against evidence matched to anchors deployed with the software: a counsel opinion, passed safety acceptance tests, a signed pilot order, and four per-merchant caps. Above all of that sits a deployment-wide switch, LIVE_OPERATIONS_ENABLED, which is off. Until both are true, no live key can be minted and no live connection can be created. The Test and Live page in the manual shows the screen.
When Live is granted, going live means creating new connections with live credentials, each dual-approved. Nothing from Test is promoted, and a live dispatch is re-checked against the kill switch, the entitlement, the caps and the connection's binding before every outbound call.
Which hosts each environment reaches
| Provider | Test | Live |
|---|---|---|
| Stripe | https://api.stripe.com (bound by key prefix) | https://api.stripe.com |
| HitPay | https://api.sandbox.hit-pay.com/v1 | https://api.hit-pay.com/v1 |
| Airwallex | https://api.sandbox.airwallex.com | https://api.airwallex.com |
The host is chosen by the environment the connection belongs to, never by anything in a request.
Provider webhooks
Providers call POST https://pehmen-api.huper.technology/webhooks/{stripe|hitpay|airwallex}/{connectionId}. For Stripe, a connection whose key has Webhook Endpoints: Write registers this endpoint itself when it is created. For HitPay and Airwallex you create the endpoint in the provider's dashboard at the URL the connection shows and paste the signing secret through POST /v1/connections/{id}/webhook-secret. Until then the connection is DEGRADED (it still routes) or waiting on the secret.