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.
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:
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 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:
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.
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:
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:
Two rules follow from this, and both are in the
go-live checklist:
- 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.
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.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.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 thantest 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.
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:
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 for what can be reproduced, and to Sandbox Testing FAQ for the simulator walkthrough.