Skip to main content
The sandbox is a full copy of Hermes. It runs on its own domain, with its own data. All money in the sandbox is test money. A sandbox request cannot move real funds. Use the sandbox to build and test your integration. Do all of your development here first. When your integration works, do the steps in Go live to move to production.

​
Sandbox addresses

The sandbox has its own dashboard and its own API base URL: Send every sandbox request to api.sandbox.jenzy.com. A sandbox key does not work against the production API. A production key does not work against the sandbox.

​
Get a sandbox key

Jenzy ops must activate your account one time. After that, your keys and your integration settings are self-serve.
1

Make an account

Open https://hermes.sandbox.jenzy.com and select Sign up. Your account then waits. Jenzy ops activates the account and attaches it to your org.
2

Sign in to the sandbox dashboard

Open https://hermes.sandbox.jenzy.com and sign in to your org.
3

Make a key

Open Integration → API keys and select Create key. The full key appears one time only. Copy it now into your secrets manager.
Sandbox keys start with jz_live_, the same as production keys. The prefix does not tell you the environment. The base URL selects test money or real money. Keep your sandbox key and your production key apart. Label each key clearly. See Authentication.

​
Add test funds

A payout draws down your balance, so you must fund the balance first. In production you fund the balance with a real pay-in to your account number. In the sandbox you simulate that pay-in yourself. A simulated pay-in is a real pay-in in every way that changes your code. It becomes a collection. It credits your balance less the fee. It sends your endpoint a collection.settled webhook. Nothing marks it as simulated. Simulate a pay-in from the API:
The response is the collection, already credited:
amount_mwk is what the sender pays. The fee comes out of it, so your balance increases by amount_credited. This is what production does. To fund a specific balance, ask for more than that balance. Set rail to momo or bank to choose where the sender pays from. The rail does not change the fee. Omit it for momo. You can also do this in the sandbox dashboard. Open Simulate a pay-in in the Sandbox menu. Every member of the org can use it. Run it as often as you want. Each call is a separate collection.
This request is not idempotent. A 202 means that the pay-in exists, but it did not credit your balance yet. Do not send the request again. Read GET /collections instead. A second request makes a second pay-in.Only 4xx and 503 mean that Hermes made nothing.
This endpoint is sandbox only. In production it answers 403 with the code sandbox_only. Money can arrive in production only when a sender pays your account number.

​
Make a test payout

After your balance has funds, create payouts as in production. Use the same endpoints, the same body, and the same idempotency rules as Quickstart. Only the base URL is different. The sandbox pays only the given test accounts. The sandbox refuses a real bank account or a real mobile number, because it has no connection to the rails. Choose any institution from GET /institutions that agrees with the rail of your endpoint. A failed payout releases its hold back to available. The failure.code field gives the reason. See Errors.

​
What is real in the sandbox

The sandbox tests the full payout path, but with test money:
  • Balances, holds, payouts, and webhooks behave as in production.
  • Test funds have no real value. They exist only in the sandbox.
  • Rate limits, IP allowlists, and idempotency apply, the same as in production.