Can I add or rotate my public key myself in the Merchant Portal?
Yes. Production public keys are submitted online through the Integration page. Each submission registers a new key record with its own API key — you do not edit an existing key in place. The submission goes through Waffo review:
You receive an email when the key is activated or rejected (rejection emails
include the reason). To rotate keys, submit the new public key, wait for it to
become Active, then switch your integration to the new API key.
Why does submitting a public key require signing a challenge string?
To prove you actually hold the private key paired with the public key you are uploading. The Portal shows a fixed challenge string in the formWAFFO_VERIFY_{mid}; sign it locally with your private key and submit the
signature together with the public key. Waffo verifies the signature with the
submitted public key before accepting it.
The same public key cannot be submitted twice for the same merchant.
How many API keys and public keys can I have?
Each API key maps to exactly one public key. A merchant can hold multiple API keys, scoped by API operation type:
A per-operation-type limit applies to how many public keys you can hold; it is
generous enough to keep old and new keys active in parallel during a rotation,
and the Portal tells you when you reach it. The count includes submissions that
were rejected, so clean up abandoned attempts if you approach the limit.
Where do I configure the refund and chargeback notification URLs?
Also on Merchant Portal → Integration. Unlike public keys, notification URL changes need no approval — once the URL passes validation, it takes effect immediately. Validation rules: the URL must start withhttp:// or
https://, conform to RFC 3986 (no spaces or non-ASCII characters), and be at
most 512 characters. Clearing the field and saving deletes the configuration.
Can I set different notification URLs per API key?
No. Each MID has one global Refund Notify URL and one global Chargeback Notify URL — they are not stored per API operation type. The Chargeback Notify URL applies to card acquiring only. Withdrawal notifications do not use these settings: the withdrawal notify URL is passed per order in the API request.How do I restrict API access to my servers’ IP addresses?
Enable the IP allowlist in the Portal — an optional safeguard that is off by default. Once enabled, a request whose signature is valid but whose source IP is not on your allowlist is rejected with errorA0046 (“Access denied:
the request IP is not in the whitelist”, HTTP 401). Configuration changes take
effect shortly after you save — saving also invalidates the cached lookup, so in
practice it is usually immediate. Merchants that never enable it see no behavior
change.
The allowlist is evaluated after signature verification, so a request with
a bad signature fails on the signature error (A0002) rather than A0046,
even when its IP is also off the list.
What formats and limits does the IP allowlist support?
- Entries accept IPv4 addresses and CIDR ranges (for example
203.0.113.7or198.51.100.0/24). IPv6 is not currently supported. - Up to 20 entries per merchant; duplicates are rejected.
- Each entry can carry a label and be toggled on or off individually.
- The allowlist cannot be switched on with no active entries, and deleting or disabling the last active entry automatically turns the master switch off.
What happens if Waffo cannot determine my request’s source IP?
By default, a request whose source IP cannot be determined is allowed and logged — only an IP that is determined and not on your allowlist is blocked. Waffo supports stricter and looser enforcement policies than this default, but the Portal exposes only the master on/off switch; the policy itself is set on Waffo’s side. Contact integration support if you want to run in observe-only mode first, or if you need requests blocked even when the source IP cannot be determined.How does the two-step verification challenge work at sign-in?
Two-step verification is a sign-in control rather than an Integration setting — the account-side questions (who can switch it on, what to do when codes never arrive) are in Merchant Portal Operations. Mechanically it is checked during the login call, not after it:- You submit the sign-in form as usual. If the account has a confirmed two-step method, no session is issued: the sign-in comes back as a challenge required response, and a code is already on its way to the account’s login email.
- The Portal opens the Verification dialog with a short-lived resend token attached to that sign-in attempt.
- You enter the code and the Portal repeats the same sign-in, this time with the code. Only then is a session issued.
Why does Resend stop working if I leave the sign-in page open?
At that point you have no session, so Resend cannot be authorised by one. It is authorised by the resend token handed out with the challenge. That token belongs to a single sign-in attempt and expires after a while; reloading the page or starting a new attempt discards it. If Resend fails, sign in again — that issues a fresh challenge and a fresh token.What does each two-step verification control actually do?
All of these are Portal actions performed with your Portal session — they are not part of the API-key-signed merchant API and cannot be scripted against with your integration keys.
Three consequences are worth knowing:
- A binding only counts once the code is verified. Closing the dialog after the code was sent leaves the attempt unconfirmed and two-step verification off; switching the toggle on again starts a fresh round.
- The first method you confirm becomes the default — and the default is the one the sign-in challenge uses.
- Switching off is authorised by your password, not by a code, travelling encrypted the same way the sign-in form’s password does. A wrong password returns the standard wrong-password error and the method stays bound.