Errors and testing

Two things on this page:

• How Payment Platform reports errors back to you.
• The test cards you use in your sandbox environment to exercise every payment outcome.

For the complete error reference (every code, every message, with cause and fix) see the API error reference. For symptom-cause-fix breakdowns of common failures, see the troubleshooting page.

info

There are no common sandbox URLs. The host you call depends on your own environment, so take it from your account manager rather than from this page.

Errors

When Payment Platform rejects a request, the synchronous response carries:

Parameter	Description
result	ERROR
error_code	Numeric code identifying the error class
error_message	Human-readable explanation of what went wrong
errors	Array of per-field validation errors (present when error_code is 100000)

Most common error codes on S2S CARD

This list covers the codes you are most likely to hit during integration. The API error reference carries the full catalogue; the troubleshooting page has symptom-cause-fix breakdowns for the most common ones.

Code	Where it fires	Meaning
100000	Request validation	Generic validation failure. The errors array carries the per-field reasons. Also used for Hash is not valid and several not-found cases (see below).
101000	Status lookup, CAPTURE (post 6.7.0)	Specific not-found code introduced by Changelog for transaction and order entities. Messages include Transaction does not exist. and Order does not exist.
204002	Routing	Enabled merchant mappings or MIDs not found.
204005	Routing	Payment action not supported by the MID.
204006	Routing	Payment system / brand not supported.
204007	Routing	Day MID limit not set or exceeded.
204014	Routing	Month MID limit exceeded.
204015	Routing	Week merchant mapping limit exceeded.
205005	Card token	Card token is invalid or not found.
205006	Card token	Card token is expired.
205007	Card token	Card token is not accessible.
208003	Payment flow	Capture requested on a payment not in pending status.
208005	Payment flow	Refund requested on a payment not in settled status.
220002	Credentials	Live merchant key used against the sandbox. Use the test key.

For the per-entity rule that decides between 100000 and 101000 on not-found responses (it depends on which action you called), see the troubleshooting page's not-found section.

Example validation failure

A typical 100000 response with the errors array filled in:

Sample error response

{
  "result": "ERROR",
  "error_code": 100000,
  "error_message": "Request data is invalid.",
  "errors": [
    { "error_code": 100000, "error_message": "card_number: This value should not be blank." },
    { "error_code": 100000, "error_message": "card_exp_month: This value should not be blank." },
    { "error_code": 100000, "error_message": "card_exp_year: This value should not be blank." },
    { "error_code": 100000, "error_message": "card_cvv2: This value should not be blank." },
    { "error_code": 100000, "error_message": "order_id: This value should not be blank." },
    { "error_code": 100000, "error_message": "order_amount: This value should not be blank." },
    { "error_code": 100000, "error_message": "order_currency: This value should not be blank." },
    { "error_code": 100000, "error_message": "order_description: This value should not be blank." },
    { "error_code": 100000, "error_message": "term_url_3ds: This value should not be blank." }
  ]
}

Payer fields are configurable since 6.7.0

payer_address, payer_country, payer_city, payer_zip are no longer required at the API layer by default. They are enforced only when the Protocol Mapping setting is set to Required. See Changelog.

Testing

The sandbox accepts the test cards below. Every transaction runs through a Test engine, so no real money moves and no real acquirer call is made.

Card number	Card expiration date (MM / YYYY)	Result
4111111111111111	01/2038	Successful sale. Also the card you use for recurring payments to get a recurring token on the initial sale; other test cards do not support recurring. SALE: {action: SALE, result: SUCCESS, status: SETTLED} AUTH: {action: SALE, result: SUCCESS, status: PENDING}
4111111111111111	02/2038	Declined sale. SALE: {action: SALE, result: DECLINED, status: DECLINED} AUTH: {action: SALE, result: DECLINED, status: DECLINED}
4111111111111111	03/2038	Successful AUTH then declined CAPTURE. AUTH: {action: SALE, result: SUCCESS, status: PENDING} CAPTURE: {action: CAPTURE, result: DECLINED, status: PENDING}
4111111111111111	05/2038	Successful sale after 3DS verification. Initial: {action: SALE, result: REDIRECT, status: 3DS} After ACS return: {action: SALE, result: SUCCESS, status: SETTLED}
4111111111111111	06/2038	Declined sale after 3DS verification. Initial: {action: SALE, result: REDIRECT, status: 3DS} After ACS return: {action: SALE, result: DECLINED, status: DECLINED}
4111111111111111	12/2038	Successful sale after redirect. Initial: {action: SALE, result: REDIRECT, status: REDIRECT} After return: {action: SALE, result: SUCCESS, status: SETTLED}
4111111111111111	12/2039	Declined sale after redirect. Initial: {action: SALE, result: REDIRECT, status: REDIRECT} After return: {action: SALE, result: DECLINED, status: DECLINED}
4601541833776519	not applicable	Successful CREDIT2CARD. Response: {action: CREDIT2CARD, result: SUCCESS, status: SETTLED}

A minimal credential-verification call

GET_TRANS_STATUS against a made-up trans_id does not check your signature. Payment Platform resolves the payment before it compares the hash, so an unknown trans_id comes back as

{ "result": "ERROR", "error_code": 100000, "error_message": "Payment not found.", "errors": [] }

whatever you put in hash. That 100000 comes from the hash-validation step, which resolves the payment before the status lookup runs; the 101000 not-found codes in the not-found table come from the lookup itself, after a request has passed hash validation. Use this call to confirm the endpoint and your client_key are reachable, not to validate your hash recipe.

To check the recipe, send a real SALE with the test card 4111111111111111, expiry 01/2038. That call is signed with Formula 1 and its hash is validated: a wrong recipe comes back as 100000 with hash: Hash is not valid. inside errors, a correct one as {action: SALE, result: SUCCESS, status: SETTLED}. Once you hold a real trans_id from that sale, GET_TRANS_STATUS on it is signed with Formula 2 and its hash is checked too.

See the troubleshooting page for the most common hash-recipe mistakes.

What's next

• API error reference: every error code with cause and fix.
• Troubleshooting: symptom-cause-fix breakdowns for the most common integration failures.
• Hash signature: which formula each action and callback uses, for all three protocols.
• Changelog: release entries that affect error behaviour (PX-13015, PX-12615, others).
• Payment operation types: per-action request and response shapes.
• Redirect / 3DS handling: the redirect flow for payments that require payer interaction, and what the callback carries - callback parameters, transStatus values and 3DS attributes.