> ## Documentation Index
> Fetch the complete documentation index at: https://developer.gcashier.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Test and Production Environments for Gcashier Pay

> Learn how to set up the Gcashier Pay sandbox for testing, transition to production, and use mock testing rules to automate your integration test suite.

Gcashier Pay provides two fully isolated environments — a sandbox for integration testing and a production environment for live transactions. Both environments share the same API surface, the same encryption scheme, and the same request/response envelope. The only differences are the base URL, the RSA key pair you use, and the merchant credentials tied to each account. Moving from sandbox to production is a matter of swapping those three values.

## Sandbox (test) environment

The sandbox lets you exercise every API operation without touching real money. Responses follow predictable mock rules (described below) so you can write deterministic automated tests against specific outcome scenarios.

### Setting up for testing

<Steps>
  <Step title="Generate a test RSA key pair">
    Create a dedicated 2048-bit RSA key pair specifically for the test environment. Do not reuse your production keys in the sandbox — keeping them separate prevents accidental cross-environment credential leaks.

    ```bash theme={null}
    mkdir -p tmp
    openssl genrsa -out tmp/tmp_rsa_private_key_2048.pem 2048
    openssl pkcs8 -topk8 \
      -in tmp/tmp_rsa_private_key_2048.pem \
      -out rsa_private_key_2048_test.pem \
      -nocrypt
    openssl rsa \
      -in tmp/tmp_rsa_private_key_2048.pem \
      -out rsa_public_key_2048_test.pem \
      -pubout
    ```
  </Step>

  <Step title="Send your test public key to Gcashier Pay">
    Provide the contents of `rsa_public_key_2048_test.pem` to the Gcashier Pay onboarding team. They will register it against your test merchant account and return their sandbox RSA public key for you to store.
  </Step>

  <Step title="Apply for a test merchant account">
    Request a sandbox `merchantNo` from Gcashier Pay. This identifier is separate from your production `merchantNo`. You will use it in the `merchantNo` POST parameter and, where required, inside the encrypted `body` of test requests.
  </Step>

  <Step title="Receive your sandbox base URL">
    Gcashier Pay will provide you with the `{baseUrl}` hostname for the sandbox. All test endpoint calls follow the pattern:

    ```
    https://{baseUrl}/api/<endpoint-path>
    ```

    Store this value in your environment configuration (e.g. an `.env` file or a secrets manager) so you can switch between environments without code changes.
  </Step>
</Steps>

<Note>
  The sandbox processes requests through the same encryption pipeline as production. A decryption or signature failure in the sandbox reflects a real implementation bug, not a sandbox limitation.
</Note>

## Production environment

When your integration tests pass and you are ready to accept live transactions, follow the go-live steps below. Gcashier Pay reviews your production application before granting access.

### Going live

<Steps>
  <Step title="Generate a production RSA key pair">
    Create a fresh 2048-bit RSA key pair for production. These keys must be generated on infrastructure you control and stored with appropriate access controls.

    ```bash theme={null}
    mkdir -p tmp
    openssl genrsa -out tmp/tmp_rsa_private_key_2048.pem 2048
    openssl pkcs8 -topk8 \
      -in tmp/tmp_rsa_private_key_2048.pem \
      -out rsa_private_key_2048_prod.pem \
      -nocrypt
    openssl rsa \
      -in tmp/tmp_rsa_private_key_2048.pem \
      -out rsa_public_key_2048_prod.pem \
      -pubout
    ```
  </Step>

  <Step title="Provide your production public key to Gcashier Pay">
    Send the contents of `rsa_public_key_2048_prod.pem` to Gcashier Pay through the secure channel they designate. You will receive Gcashier Pay's production RSA public key in return.

    <Warning>
      Do not transmit your production private key through any external channel. If you suspect your private key has been exposed, contact Gcashier Pay immediately to invalidate the key and rotate to a new pair.
    </Warning>
  </Step>

  <Step title="Provide your server IP address">
    Gcashier Pay allowlists the IP addresses from which your servers will call the production API. Provide the static egress IP address (or CIDR block) for each production server or gateway that will make API calls.
  </Step>

  <Step title="Apply for your production merchant account">
    Request a production `merchantNo` from Gcashier Pay. Once approved, you receive the production `{baseUrl}` and your live `merchantNo`. Update your environment configuration to point at the production base URL and use the production key pair.
  </Step>
</Steps>

## Environment configuration summary

| Setting                       | Sandbox                            | Production                            |
| ----------------------------- | ---------------------------------- | ------------------------------------- |
| Base URL                      | `https://{sandboxBaseUrl}/api/...` | `https://{productionBaseUrl}/api/...` |
| `merchantNo`                  | Test merchant number               | Live merchant number                  |
| Your RSA private key          | Test private key                   | Production private key                |
| Gcashier Pay's RSA public key | Sandbox public key                 | Production public key                 |
| Real money movement           | No                                 | Yes                                   |
| Mock testing rules            | Yes                                | No                                    |

<Tip>
  Structure your code so that the base URL, `merchantNo`, and both RSA key paths are injected at runtime from environment variables. A single config change should be all it takes to flip between environments — no code modifications required.
</Tip>

## Mock testing rules

The sandbox uses deterministic rules to drive automated test outcomes. By choosing specific field values, you can reliably trigger success, rejection, or pending states in your test suite without manual intervention.

### sp1101 — Merchant access application

The outcome is determined by the **last digit of `merNameEn`** (the merchant's English name field).

| Last digit of `merNameEn` | Simulated outcome |
| ------------------------- | ----------------- |
| 0 – 3                     | ✅ Approved        |
| 4 – 6                     | ❌ Rejected        |
| 7 – 9                     | 🕐 Under review   |

```json theme={null}
{ "body": { "merNameEn": "Test Company A3" } }
```

The example above ends in `3` → the application will be approved.

***

### sp1202 — FX trading

The outcome is determined by the **single digit of `amount`** (i.e. the units digit of the trade amount).

| Units digit of `amount` | Simulated outcome |
| ----------------------- | ----------------- |
| 0 – 3                   | ✅ Success         |
| 4 – 6                   | ❌ Failed          |
| 7 – 9                   | ⏳ Processing      |

```json theme={null}
{ "body": { "amount": "500.00" } }
```

The units digit is `0` → the FX trade will succeed.

***

### sp1303 — International remittance confirm

The outcome is determined by the **units digit of either `debitAmount` or `arriveAmount`**.

| Units digit of amount | Simulated outcome     |
| --------------------- | --------------------- |
| 0 – 3                 | ✅ Success             |
| 4 – 6                 | ❌ Rejected            |
| 7 – 9                 | — No action (pending) |

***

### sp1305 — Withdrawal

The outcome is determined by the **last digit of `bankAccountNo`** (the beneficiary bank account number).

| Last digit of `bankAccountNo` | Simulated outcome     |
| ----------------------------- | --------------------- |
| 0 – 3                         | ✅ Success             |
| 4 – 6                         | ❌ Rejected            |
| 7 – 9                         | — No action (pending) |

```json theme={null}
{ "body": { "bankAccountNo": "6217001234567892" } }
```

The last digit is `2` → the withdrawal will succeed.

***

### sp1105 — Flow-order association

This API associates a flow order from a prior sp1104 call. The outcome is determined by the **units digit of the `amount` from the referenced sp1104 transaction**.

| Units digit of sp1104 `amount` | Simulated outcome     |
| ------------------------------ | --------------------- |
| 0 – 3                          | ✅ Success             |
| 4 – 6                          | ❌ Rejected            |
| 7 – 9                          | — No action (pending) |

***

### sp1301 — RMB payment

The sandbox applies specific mock rules for RMB payment requests. Contact Gcashier Pay's integration support team for the full mock value matrix for sp1301, as the triggering field depends on the collection method you are testing.

<Note>
  Mock rules only apply in the sandbox environment. Production responses reflect actual processing outcomes and are never deterministic in the same way.
</Note>
