Skip to main content
An error returns a non-2xx HTTP code and a JSON object containing at least a message field. Some responses add a status field (for example {"status": "failed", "message": "…"}), or replace message with an errors array — this is the case for validation errors on a payment link. The exact messages are listed below, first by authentication step, then by operation.

​
Authentication and headers

These checks run in this exact order on every authenticated operation: the first unmet condition is the one that determines the response. A Sandbox key used with Ipay-Target-Environment: live (or the reverse) fails at step 6, not before: it is syntactically valid but does not match any account for the requested environment.

​
Create a payment

​
Retrieve or list payments

  • Never automatically retry a 400, 401, 403, 404, 406 or 422 error without fixing the request that caused the refusal: these are all validation errors, not transient incidents.
  • If you get no response (timeout, network outage) when creating a payment, do not blindly replay the call: first check the actual state with Retrieve a transaction, which accepts your transaction_id. Duplicate detection on external_reference is applied at the application level and is not guaranteed under concurrent calls: two requests sent at the same moment with the same transaction_id may both succeed. The 422 above is the established behavior in Live; in Sandbox, the response to a duplicate is not guaranteed to be identical (to be confirmed with support). Recommendation (not a behavior guaranteed by the API): generate a unique transaction_id for each attempt and check the status before retrying.
  • Log the HTTP code, the message returned, and your own references (transaction_id, iMoney Encaissement reference) for support — never the API keys or the customer’s payment data.
  • No rate limit is documented by this contract at this time: to be confirmed with support before bulk sending or frequent polling.