Whish MoneyDevelopers
Reliability & Idempotency
Timeouts and retries happen. This guide keeps your Whish integration correct when they do, starting with the one thing that trips people up: the two environments handle a repeated request differently.
- Know which environment you're on
- Use a unique id per operation
- Store it before you send
- Prefer callbacks, confirm before fulfilling
Whish runs on two independent environments. They use different identifiers and react differently when the same request arrives twice, so always follow the rules for your environment and never assume the other one behaves the same way.
Step 1 · Find your environment
| If you are integrating… | Your environment | Base host |
|---|---|---|
| Whish Pay, Whish Pay QR, Direct Credit, Bills, Vouchers, Variable Topup, International Topup | Whish | api.whish.money/itel-service/api |
| International Money Transfer | Whish Money | api.woocash.money |
Step 2 · Follow your environment's rules
Whish
externalId that you generate, sent in the request body. One value per operation.externalId and return the already-processed result instead of creating a duplicate. Where that is not guaranteed, your unique externalId is the safeguard, so do not treat a blind resend as safe.status: true is success. status: false with code: 500 means the outcome is unknown, so treat it as pending and escalate to Whish; do not mark it failed. Any other code is a failure.Whish Money
Request-id in the request header. The same value is reused as requestId to look a transfer up later.Request-id. If it never arrived, the transfer is created now. If it did arrive, nothing is duplicated and you get transfer.already.done: then call Get Transfer Status with that requestId to read the outcome. Resend first, do not query status first: a transfer that never arrived is not there to find.200, so branch on the status and code in the body, not the HTTP code. See the handling guide for the exact codes.Callback source IPs
When Whish calls your callback URL (Whish → you), the request comes from a fixed set of source IPs. If your callback endpoint restricts inbound traffic, allowlist these so callbacks are not blocked. The two environments use different addresses, so allowlist the set that matches yours.
Whish · Whish Pay, Whish Pay QR
| Environment | Callback source IPs |
|---|---|
| Production | 18.213.222.4552.21.189.5152.21.55.64 |
| Sandbox | 52.4.4.47 |
Whish Money · International Money Transfer
| Environment | Callback source IPs |
|---|---|
| Production | 3.214.156.22834.225.14.166 |
| Sandbox | 3.219.107.220 |
Allowlist every address for the environment you use. This is only about receiving callbacks; calling the Whish APIs from your servers is separate (some endpoints require Whish to allowlist your IPs instead).
Step 3 · Principles that apply everywhere
- Store your identifier before you send. Save the
externalIdorRequest-idwith the order first, so you can reference it exactly when you follow up. - A timeout means "unknown", not "failed". Never treat it as a failure, and never resend with a new identifier: that is what creates duplicates. Recover with the identifier you already sent, following the rule for your environment above, and confirm the real state before you refund or cancel.
- Confirm before you fulfil. Act on a confirmed result from a callback or the status endpoint, never on an assumption.
- Read the response body, not just the HTTP status. Whish returns a
statusflag (and often acode) that carries the real result.
Checklist: know your environment · unique identifier per operation · store it before sending · prefer callbacks · confirm via status before fulfilling · branch on the body, not the HTTP code.
For the exact fields, error codes, and callback payloads, use each API's own reference page. This guide stays general on purpose.