Staging Environment
9 min
staging environment use a staging environment to build and test a payments integration without moving real funds keep staging wallets, credentials, webhook destinations, and test data separate from production getting started create or open a staging environment in the voltage dashboard add a development wallet using the currency required by your test wait for the wallet overview to load create an environment scoped api key with the minimum required permissions store the one time key value in an approved secret manager choose the development wallet that matches the implementation being tested mutinynet bitcoin bitcoin backed implementations, including node backed bitcoin and credit backed bitcoin mutinynet usd usd line of credit implementations that move payments over bitcoin or lightning while using a usd denomination voltage cash experimental stablecoin testing only it is not currently live for production use because the intended tether backed asset has not yet been minted development balances have no real world value development wallet choices showing mutinynet bitcoin selected with mutinynet usd and voltage cash unselected choose mutinynet bitcoin for bitcoin backed tests, mutinynet usd for usd line of credit tests, or voltage cash only for experimental stablecoin testing staging environment with two ready development wallets keep test wallets and their credentials inside the staging environment api access base url https //voltageapi com/v1 authentication send the staging environment's key in the x api key header do not reuse a production key in staging or a staging key in production create a staging wallet through the api use current organization, environment, and funding identifiers returned by the payments api the following request shows the route shape; verify the request schema in the voltage payments api docid\ ee9anjjlombmff1vx4ujw reference before sending it curl 'https //voltageapi com/v1/organizations/{organization id}/wallets' \\ \ request post \\ \ header 'content type application/json' \\ \ header 'x api key your staging api key' \\ \ data '{ "environment id" "{environment id}", "id" "{client generated wallet id}", "line of credit id" "{line of credit id}", "limit" 100000000, "name" "staging wallet", "network" "mutinynet" }' wallet creation is asynchronous treat an accepted response as the start of provisioning and read the wallet state before depending on it test payments send create a test payment request in another development wallet or approved test wallet enter the request in the staging wallet review the amount, maximum fee, method, route, and truncated destination submit the payment and wait for a terminal status test lightning payment review drawer review the test payment details before submitting it completed test lightning payment confirmation wait for the final result before treating the staging payment as complete receive select receive enter a test amount and optional memo select create payment request use the request only in a test workflow confirm the incoming payment in all payments for api workflows, see sending docid\ ijeswowxjhpgyt6fv1kk1 , receiving docid uq9knquoc9sgq0kuogmy , and webhooks docid\ pdeh 4et9aqawca5q91na verify status and history treat accepted or generated states as non terminal confirm the final payment status before fulfilling an order or updating an external ledger use webhooks for event driven updates and api reads for reconciliation use payment filters and reports when investigating a test flow do not rely on fixed settlement timing, fixed test credit amounts, or automatic credit expansion current limits and availability are product controlled and can change move to production complete the staging integration and failure path tests create or obtain the intended production environment and wallet create new production api keys and webhook registrations update the application configuration without carrying over staging credentials or identifiers run a controlled production verification with current operational approval never use the mutinynet workflow as evidence that mainnet funding, limits, fees, or settlement behavior will be identical