Environment comparison

Before you start

• A Payvala account with access to the developer area
• A role that allows creating and viewing credentials [confirm role names, if applicable]
• A secure place to store credentials, such as a secrets manager

Environment variables (API key)

Use these values if API-key authentication applies.

PAYVALA_ENVIRONMENT=sandbox
PAYVALA_BASE_URL=<SANDBOX_BASE_URL>
PAYVALA_API_KEY=<SANDBOX_API_KEY>

Environment variables (client credentials)

Use these values if client ID and secret authentication applies.

PAYVALA_ENVIRONMENT=sandbox
PAYVALA_BASE_URL=<SANDBOX_BASE_URL>
PAYVALA_CLIENT_ID=<SANDBOX_CLIENT_ID>
PAYVALA_CLIENT_SECRET=<SANDBOX_CLIENT_SECRET>

Loading configuration in application code

Read values once and fail at startup if required values are missing.

export const payvalaConfig = {
  environment: process.env.PAYVALA_ENVIRONMENT,
  baseUrl: process.env.PAYVALA_BASE_URL,
  apiKey: process.env.PAYVALA_API_KEY,
};

if (!payvalaConfig.baseUrl || !payvalaConfig.apiKey) {
  throw new Error("Missing Payvala configuration");
}

Configuration recommendations

• Add the environment file to .gitignore
• Use separate configuration for development, CI, and staging
• Log the active environment name at startup, never the credentials
• Keep Sandbox and Production values in separate secret stores

Authentication failures

Example: API key in a request header (placeholder)

Illustrative only. Replace the header format with Payvala's confirmed scheme.

curl "<SANDBOX_BASE_URL>/<ENDPOINT_PATH>" \
  -H "Authorization: Bearer <SANDBOX_API_KEY>"

Example: exchanging client credentials for a token (placeholder)

Illustrative alternative. Use only if Payvala confirms client-credentials authentication.

curl -X POST "<SANDBOX_BASE_URL>/<TOKEN_ENDPOINT_PATH>" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "<SANDBOX_CLIENT_ID>",
    "client_secret": "<SANDBOX_CLIENT_SECRET>"
  }'

Request

Replace the path with a confirmed read-only endpoint.

curl "<SANDBOX_BASE_URL>/<FIRST_REQUEST_ENDPOINT_PATH>" \
  -H "Authorization: Bearer <SANDBOX_API_KEY>" \
  -H "Accept: application/json"

Response (shape to be confirmed)

Replace with the confirmed response for the chosen endpoint.

{
  "<RESPONSE_FIELDS>": "Replace with the confirmed response"
}

If the request fails, check

• The base URL is the Sandbox URL, not Production
• The credential is a Sandbox credential and has not been revoked
• The authentication header name and format match Payvala's documentation
• The endpoint path and HTTP method are correct
• Your network or proxy is not blocking outbound HTTPS

Flow test plan (fill in with confirmed Payvala flows)

Error scenarios to cover

Error response (shape to be confirmed)

Replace with Payvala's confirmed error format.

{
  "error": {
    "code": "<ERROR_CODE>",
    "message": "<ERROR_MESSAGE>"
  }
}

Minimal receiver (illustrative)

Verify, enqueue, and acknowledge. The signature scheme is not confirmed.

app.post("/webhooks/payvala", express.raw({ type: "application/json" }), (req, res) => {
  // 1. Verify the signature using <SIGNATURE_HEADER_NAME> [confirm scheme]
  // 2. Parse the event and enqueue it for processing
  // 3. Acknowledge immediately
  res.sendStatus(200);
});

Webhook handler requirements

• Verify authenticity of each event before processing [confirm signing method]
• Respond with a success status quickly and process work asynchronously
• Handle duplicate deliveries safely
• Do not depend on event ordering [confirm Payvala's guarantees]
• Handle retries after failure [confirm retry policy]

Test data reference (all values pending confirmation)

Differences to account for

• Transactions are simulated and have no real-world effect [confirm]
• Timing of asynchronous events may differ from Production [confirm]
• Rate limits and quotas may differ from Production [confirm]
• Third-party and network integrations may be simulated or unavailable [confirm which]
• Some features may be unavailable or behave differently [confirm list]
• Availability and maintenance windows may differ from Production [confirm]

Values to change

Pre-launch checklist

• All required flows pass end to end in Sandbox
• Error and edge cases are handled and tested
• Webhook handling is verified, including duplicates and failures
• Secrets are stored securely and absent from source control and logs
• Logging, monitoring, and alerting are in place
• Production access has been requested and approved