Payments Access

payments has two access layers human dashboard access is controlled at the team level, while payments api keys are scoped to one environment payments ui access payments dashboard access follows the user's team permissions read view supported wallets, balances, payments, and related resources across the team's payments environments write create or manage supported payments resources, create environment api keys, and perform permitted payment actions across the team's payments environments team level ui write cannot be limited to only staging or only production within one team when human ui access must be isolated between environments, use a separate team boundary payments api key access payments api keys are scoped to one environment and sent in the x api key header read view supported resources in that environment write create or manage supported writable resources in that environment a payments api key does not grant access to another environment, an infrastructure api key, or an lnd macaroon dashboard key setup open the selected environment's api keys page to list or create payments api keys the creation form supports a descriptive name, read and write permissions, and an optional ip allowlist the plaintext key is a one time result after creation never include it in screenshots or documentation; close the result after storing it in an approved secret manager empty api keys page for the selected environment payments api keys are listed and created within the selected environment recommended pattern use separate staging and production environments give people team read or write only when they need dashboard access use a separate team when ongoing human staging and production ui access must be isolated issue a dedicated environment scoped api key to each application or service apply read or write permissions according to the service's actual workflow review and remove access during role changes, incidents, and production launches production key hygiene use separate keys for separate services use descriptive names that include the environment and purpose apply least privilege restrict production keys by ip when the calling network is stable store keys in an approved secrets manager rotate or delete keys when team membership, service ownership, or infrastructure changes ip allowlisting restrict an api key to the specific ip addresses or ranges used by its service when possible leave the allowlist empty only when the service must call from changing or unbounded source addresses review allowlists during network changes, incident response, and production launches create api key form with permissions and an example ip allowlist apply least privilege and restrict the key to stable source addresses when possible webhook secrets webhook signing secrets are separate from api keys store them securely and verify each webhook signature before accepting or processing the event use the maintained payments webhooks documentation for key generation, signature verification, delivery handling, and reconciliation api reference payments api base url https //voltageapi com/v1 openapi reference https //voltageapi com/v1/docs