> For the complete documentation index, see [llms.txt](https://docs.jgopay.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.jgopay.com/english/testing.md).

# Testing Your Integration

The staging environment supports **magic test amounts** so you can verify your full integration — payment creation, status polling, and callback handling — without moving real money.

> Magic amounts work **only on the staging environment**. On production they are treated as normal amounts and routed to a real payment channel.

## Magic Amounts

The trigger is the **last two digits of the integer part** of the amount:

| Integer part ends in | Result                                   |
| -------------------- | ---------------------------------------- |
| `11`                 | Transaction becomes `SUCCESS` in \~5–10s |
| `22`                 | Transaction becomes `FAILED` in \~5–10s  |
| anything else        | Routed to a real payment channel         |

Examples: `111.00` or `511.00` → SUCCESS; `122.00` or `522.00` → FAILED.

Decimals are ignored — `100.11` is **not** magic (integer part `100`), while `511.50` **is** (integer part `511`).

Magic amounts work for **all payment methods** (DuitNow, TNG, FPX) and for **both deposits and withdrawals**. The payment method you select does not matter; only the amount controls the outcome.

## What Happens

1. Create a payment (or withdrawal) with a magic amount, exactly as you would in production.
2. Deposits: the payment page shows a placeholder test QR code (it is not payable — no real charge can occur).
3. After \~5–10 seconds the transaction transitions to `SUCCESS` or `FAILED`.
4. Your `callback_url` receives a **real callback** — same payload shape, same signature scheme, same retry behaviour as production. Verify the signature exactly as documented in [Callbacks](/english/webhooks.md).
5. Balances, fees, and transaction history on staging update exactly as they would for a live transaction.

## Testing Withdrawals

Withdrawals require an available balance. Fund your staging balance first with a magic **deposit** (e.g. `111.00`), then create a withdrawal with a magic amount:

* Ending `11` → withdrawal confirms (`SUCCESS` callback).
* Ending `22` → withdrawal fails (`FAILED` callback) and the held amount is released back to your available balance.

Any valid bank code from [Bank Codes](/english/bank-codes.md) is accepted for magic withdrawals.

## Notes

* Magic amounts must still be within the currency's normal minimum/maximum limits.
* Test transactions book **zero fees** — fee fields in callbacks and reports will be `0` for magic-amount transactions.
* Magic amounts take precedence over `preferred_gateway`: a magic amount is always handled by the test channel, regardless of any preferred gateway in the request.
* To see the real payment page experience (actual QR, bank redirect), use any non-magic amount on staging — but note real channels on staging may reject transactions; magic amounts are the supported way to test end-to-end status flow.
* Avoid using amounts ending in `11` or `22` on staging for anything you do *not* want auto-completed.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.jgopay.com/english/testing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.