Sandbox vs. Production Environments
Relevant source files
The following files were used as context for generating this wiki page:This document outlines the distinction between the Sandbox and Production environments within the zalopay integration library. The library is designed to interact with the ZaloPay API, and its environment is determined entirely by a configuration object provided during initialization. This allows developers to test their integration against a safe Sandbox environment before switching to the live Production environment for real transactions.
The core logic in lib/ZaloPay.js is environment-agnostic; it relies on the provided configuration to target the correct API endpoints and use the appropriate credentials. The example implementation demonstrates how to manage this configuration for different API calls like creating an order or checking its status.
Configuration
The environment selection is managed through a single configuration object. The example implementation provides a template for this configuration, which is used to instantiate the ZaloPay class.
Sources: example/config.js, lib/ZaloPay.js:12-14
Configuration Parameters
The configuration object defines the credentials and the API endpoint to be used for all transactions. The example file example/config.js provides the values for the Sandbox environment. For a Production environment, these values would be replaced with live credentials provided by ZaloPay.
| Parameter | Type | Description |
|---|---|---|
app_id | String | The application ID provided by ZaloPay. |
key1 | String | The first key (Key1) for generating the mac (message authentication code) for request signatures. |
key2 | String | The second key (Key2) for verifying callback signatures from ZaloPay. |
endpoint | String | The base URL for the ZaloPay API. This is the primary value that distinguishes Sandbox from Production. |
Sources: example/config.js:1-6
Example Sandbox Configuration
The following code snippet shows the sandbox configuration provided in the repository.
// example/config.js
module.exports = {
app_id: "2553",
key1: "PcY4iZIKFCIdgZvA6ueMcMHHUbRLYjPL",
key2: "kLtgPl8HHhgwk_3F1_8_V5fRbdG5Fp26",
endpoint: "https://sb-openapi.zalopay.vn/v2/create",
};
Sources: example/config.js:2-6
ZaloPay Class and Initialization
The main ZaloPay class is initialized with the configuration object. This object is stored internally and used by all methods that interact with the ZaloPay API.
// lib/ZaloPay.js:12-14
class ZaloPay {
constructor(config) {
this.config = config;
}
//...
}
The diagram below shows the structure of the ZaloPay class, which takes the configuration upon construction and uses it in its methods.
Sources: lib/ZaloPay.js:12-79, example/config.js
API Request Flow
All API requests, such as creating an order or getting an order's status, use the endpoint defined in the configuration. The distinction between a Sandbox call and a Production call is therefore determined at the point of initialization.
The following sequence diagram illustrates how a "Create Order" request is processed. The flow is identical for both environments; only the config.endpoint value changes.
This diagram shows the interaction when a client calls the /api/createorder endpoint on the example server. The server logic uses the ZaloPay library, which in turn makes a POST request to the configured ZaloPay API endpoint.
Sources: example/index.js:11, example/api/createorder.js:10-14, lib/ZaloPay.js:25-33
API Endpoints
The system is designed to point to different base URLs for testing and live transactions. The provided example code is configured for the ZaloPay sandbox.
| Environment | Endpoint URL | Source |
|---|---|---|
| Sandbox | https://sb-openapi.zalopay.vn/v2/create | example/config.js:5 |
| Production | (Not specified) | Would be set in config.js:5 |
Note: The production endpoint URL is not included in the source files. To switch to production, the endpoint value in config.js must be updated to the live URL provided by ZaloPay.
Sources: example/config.js:5
Summary
The zalopay library provides a clear and simple mechanism for switching between Sandbox and Production environments. This is achieved by abstracting environment-specific details into a single config object. Developers can perform comprehensive testing in the sandbox by providing the sandbox configuration, and then switch to live operations by simply changing the app_id, key1, key2, and endpoint values to their production credentials. This design ensures that no code changes are needed within the application logic to move from testing to production.