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

# Sandbox Environment & Access FAQ

> How the Waffo sandbox is provisioned, which URLs and merchant ID belong to it, how the sandbox setup wizard works and what each answer changes, where sandbox keys come from, and exactly how the sandbox is isolated from production.

Four pages cover sandbox work, and they answer different questions:

| Question | Page |
| - | - |
| Which URL, which test card, how do I simulate a result? | [Sandbox and testing](/docs/en/developer-docs/getting-started/sandbox) and [Sandbox simulator](/docs/en/developer-docs/tools-and-references/developer-tools/sandbox-simulator) |
| How do I get in, what is my sandbox merchant ID, what does the setup wizard change, what is isolated from production? | **This page** |
| What can and cannot be simulated, and which reserved amounts do what? | [Sandbox Simulation Limits FAQ](/docs/en/support/sandbox-simulation-limits-faq) |
| What must I finish before going live? | [Go-live checklist](/docs/en/developer-docs/getting-started/go-live) and [Integration acceptance criteria](/docs/en/developer-docs/tools-and-references/references/acceptance-criteria) |

## Do I need to ask Waffo to open a sandbox for me?

No. The sandbox is self-serve and is created for you automatically. When you
register and submit your business details, a default sandbox is provisioned for
your account without any further request, and without Waffo staff involvement.
There is no form to fill in to *ask* for one.

What you do next is optional refinement: the setup wizard lets you tell Waffo
which products, pricing model, markets and payment methods you want your sandbox
to look like, so that the sandbox reflects the integration you are actually
building.

## Which URLs are the sandbox, and which are production?

They are separate environments on separate hostnames. Nothing in the Portal
toggles between them — you sign in to one or the other.

| Surface | Sandbox | Production |
| - | - | - |
| Merchant Portal | `https://dashboard-sandbox.waffo.com` | `https://dashboard.waffo.com` |
| API | `https://api-sandbox.waffo.com` | `https://api.waffo.com` |
| Hosted checkout | `https://checkout-sandbox.waffo.com` | `https://checkout.waffo.com` |
| Cashier / subscription management pages | `https://cashier-sandbox.waffo.com` | `https://cashier.waffo.com` |
| Static assets | `https://cdn.waffo.com` | `https://cdn.waffo.com` |

The API address for the environment you are signed in to is also shown on
**Merchant Portal → Integration**, so you can always confirm it from inside the
Portal rather than from a document.

If you use a Waffo SDK, set `Environment.SANDBOX` or `Environment.PRODUCTION`
instead of editing URLs by hand.

## Which domains do I need to allow in my firewall or CSP?

For your own pages and your own network policy, the domains above are the
complete customer-facing set. In practice:

| What you are configuring | What to allow |
| - | - |
| Server-side outbound calls to Waffo | The API host for that environment |
| A page that opens or frames Waffo checkout | The checkout and cashier hosts for that environment |
| Images and logos rendered from Waffo | The static asset host |

Two cautions worth building in from the start:

* **Allow the hostname, not an IP.** The go-live checklist recommends a DNS TTL
  of 60 seconds and explicitly warns against pinning Waffo IP addresses; they
  are not stable and are not published.
* **Sandbox and production hostnames differ**, so a policy written against one
  environment will silently block the other. Parameterise the host by
  environment rather than hard-coding it.

## Is my sandbox the same merchant ID as production?

No — the sandbox has its own merchant ID, and your user account is attached to
that sandbox merchant ID while you are in the sandbox environment.

You never have to guess which one you are looking at. **Merchant Portal →
Integration** shows the merchant ID of the environment you are signed in to,
right above the credential table, together with that environment's API address.
A sandbox Portal session also carries a persistent banner stating that you are
in the sandbox and that all data is test data.

The consequence for your integration: a sandbox credential can only act on
sandbox data, and a production credential only on production data. Requests
authenticated with one environment's API key against the other environment's
host fail on the credential check, not on your business logic — see
[Authentication & Signature FAQ](/docs/en/support/auth-signature-faq) for
the exact error codes.

## What does the sandbox setup wizard actually change?

It is six steps, and each answer shapes what your sandbox looks like rather than
what it is allowed to do:

| Step | What you enter | What it affects |
| - | - | - |
| 1 | Legal company name, official website, business type, country of incorporation | Merchant identity shown in your sandbox, including the merchant name rendered on the checkout page |
| 2 | Products: one-time payment, subscription, or both | Which product flows your sandbox is configured for |
| 3 | Pricing strategy: `GLOBAL_USD` or `LOCAL_CURRENCY` | Whether your sandbox is set up to present a single settlement currency or local currency pricing per market |
| 4 | Target markets | Which countries the candidate payment method list is drawn from |
| 5 | Payment methods | Which payment methods are enabled in your sandbox |
| 6 | Sandbox ready | Shows your sandbox API key and key pair |

Steps 3 and 4 together drive step 5: the candidate list of payment methods is
derived from the products, the pricing strategy and the markets you selected. If
a method you expected is not offered in step 5, the cause is almost always a
market or pricing choice made two steps earlier, not a missing entitlement.

## Can I change my sandbox configuration afterwards, and does an edit add or replace?

You can change it, and an edit **replaces the whole selected set** — it is not
additive. When you resubmit, the selection you send becomes the complete
configuration: anything you left out is no longer part of it.

Practical consequence: before editing, open the current configuration and start
from what is already selected, rather than sending only the delta you had in
mind. Sending "just the new method" removes everything else.

## I pressed "Clear all" or "Reset". Can I undo it?

Yes — neither touches your saved configuration until you save.

| Action | What it does |
| - | - |
| **Clear all** | Deselects every payment method for the market you are currently looking at, in the edit you have in progress |
| **Reset** | Discards the unsaved market and payment-method changes and restores the configuration you last saved |

So `Reset` *is* the undo for `Clear all`, and leaving the screen without saving
also leaves the saved configuration untouched. Both actions ask for confirmation
first, because within an unsaved edit they are destructive of your in-progress
selections.

Two related behaviours in the same wizard, which surprise people more than the
buttons do: changing the **products** or the **pricing strategy** clears the
payment-method and currency selections underneath, because the previous
selection may not be valid under the new choice; and a market with no enabled
method is dropped from your market list rather than kept as an empty market.

## My sandbox status is stuck on PROCESSING. What does each status mean?

The configuration moves through three states, and only the last one means the
sandbox is live for you:

| Status | Meaning |
| - | - |
| `PROCESSING` | Submitted; Waffo is applying it asynchronously |
| `COMPLETED` | Applied; your account is attached to the sandbox merchant ID and key generation is finishing |
| `ACTIVE` | In effect; your Portal session is operating in the sandbox |

Because it is applied asynchronously, a short `PROCESSING` period is normal, and
the final step of the wizard polls until your keys exist rather than asking you
to refresh. If it does not progress, the configuration record carries an error
message that the Portal surfaces, and the failure also raises an alert on
Waffo's side — so the useful action is to contact integration support with your
sandbox merchant ID rather than resubmitting repeatedly.

## Where do my sandbox keys come from, and do I submit a public key?

Waffo generates the sandbox key pair for you. The final wizard step and
**Merchant Portal → Integration** show your sandbox API key, public key and
private key, so you can start signing immediately.

This is deliberately different from production:

| | Sandbox | Production |
| - | - | - |
| Key pair | Generated by Waffo and shown to you, private key included | You generate it; Waffo never holds your private key |
| Submitting a public key | Not available — there is nothing to submit | Submitted by you from the Integration page, then reviewed |
| Key rotation and version history | Not applicable | Available on the Integration page |

Two rules follow from this, and both are in the
[go-live checklist](/docs/en/developer-docs/getting-started/go-live):

* **Never carry sandbox key material into production.** Generate a fresh
  production pair. A key whose private half was displayed in a browser is not a
  production secret.
* **Switch the host and the credential together.** They are a set; changing one
  without the other produces a signature failure that looks like a code bug.

Production key submission, the exact format the field accepts and how rotation
works are covered in
[Production Public Keys & API Operation Types](/docs/en/support/production-api-key-and-public-key-faq).

## Are sandbox rates, settlement cycles, withdrawal thresholds and limits my real commercial terms?

No. Sandbox configuration is provisioned from defaults so that the flows work
end to end; it is not a copy of your commercial agreement, and no figure you see
in the sandbox should be read as a quotation or as the number that will apply in
production. Treat sandbox amounts, cycles and thresholds as scaffolding for
testing the *mechanics* — the field is populated, the calculation runs, the
status transitions — and confirm the actual values against your production
configuration once you are live.

## Does the sandbox connect to real payment channels?

No. The sandbox does not connect to real payment channels, and no real money
moves. Instead of a real payment method selection, the sandbox checkout page
gives you simulation controls that let you decide the outcome directly. The
simulation flow is the same for every payment method.

That is the single most important thing to internalise about sandbox results:
the sandbox proves that **your** integration handles each outcome correctly. It
does not prove anything about how a specific payment method behaves for a real
end user. What can and cannot be reproduced is enumerated in
[Sandbox Simulation Limits FAQ](/docs/en/support/sandbox-simulation-limits-faq).

## Does enabling a payment method in the sandbox enable it in production?

No, and neither direction syncs. Sandbox configuration and production
configuration are independent: the sandbox setup wizard exists only in the
sandbox Portal and cannot be reached at all from production, and changes you
make to your production configuration do not flow back into the sandbox.

So a sandbox that can transact with a given method tells you your code path
works — it is not an entitlement. Production availability follows your
agreement, and enabling a method for production is a separate step; see
[Payment method enrollment](/docs/en/support/payment-enrollment-faq).

## Will my sandbox transactions show up in real settlement, billing or reconciliation files?

No. Sandbox is a separate environment with its own data; sandbox activity
produces only sandbox-side records, and sandbox exports are written to a
sandbox-scoped location. Nothing you do in the sandbox reaches production
settlement batches, production statements or production reconciliation files.

The mirror of that isolation is also worth planning for: sandbox settlement
records exist for testing your file parsing and your reporting, and they carry
sandbox amounts derived from defaults rather than from your agreement.

## Can I use real customer email addresses and phone numbers in the sandbox?

Do not. The acceptance criteria already require realistic-looking parameter
values rather than `test` placeholders, and the recommended form for a customer
email is a `userId@examples.com`-style address that is unique per test user —
which satisfies both requirements at once without ever addressing a real inbox.
See the parameter requirements in
[Integration acceptance criteria](/docs/en/developer-docs/tools-and-references/references/acceptance-criteria).

Two reasons this matters beyond politeness: sandbox flows do generate
notifications, and an address you do not control cannot be inspected when you
need to prove a notification was produced. Use addresses you own.

## How long does it take for a credential or configuration change to become effective?

Different surfaces, different windows — and neither is instant:

| Change | When it takes effect |
| - | - |
| A public key becoming `Active` | Shortly after activation; only `Active` keys verify signatures, and the lookup used on the request path is refreshed on a short interval rather than instantly |
| An IP allowlist edit | Almost immediately; saving also invalidates the cached lookup |

So a test run immediately after a credential change can legitimately fail on the
old configuration. If a request fails right after you rotated or activated
something, wait out the window above and retry the identical request before
debugging your signing code.

## Who on my team can see the sandbox credentials?

The Integration page — API key, Waffo public key, and in the sandbox the
generated private key — requires the **Dev** or **Admin** role. Production key
material on that page is masked with a show/hide control and a copy action that
works without unmasking; use the copy action rather than revealing a value on a
shared screen or a recorded call.

Because sandbox private key material is displayed by design, treat sandbox
credentials as shared team test material and production credentials as secrets
with a different handling standard. They are not the same class of thing.

***

Ready to test outcomes rather than access? Continue to
[Sandbox Simulation Limits FAQ](/docs/en/support/sandbox-simulation-limits-faq) for
what can be reproduced, and to
[Sandbox Testing FAQ](/docs/en/support/sandbox-testing-faq) for the simulator
walkthrough.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.