Handle responses

Idempotency

The POS payments API supports idempotency in the same way as other Adyen APIs. This means you can retry a request multiple times while only performing the action once, for example, when a timeout occurs.

To minimize unwanted side effects when requests are duplicated, you can take the following actions:

• Implement webhooks.
  The webhooks help you keep track of missing responses, a common consequence of a data transmission timeout.
• Enable idempotency in your POS payments API requests.

For more information and instructions, see API idempotency.

No result received

When you aren't sure what happened with your request, you can:

• Check the webhooks you received for the request. For this, you need to implement webhooks.
• Check the transactions in your Customer Area.

Declined transaction

If an authorization is declined, use the following authorization response fields to determine the cause and decide on your next step:

• resultCode: Authorised, Refused, Error, or Cancelled.
• refusalReason: Adyen's mapped reason for the refusal. This is a generalization of similar refusal reasons from different card schemes.
• refusalReasonCode: a code corresponding to Adyen's mapped refusal reason.
• emvData.tag8a: the raw Authorisation Response Code (ARC) for a chip card transaction.
• authorisationResponseCode: the ARC for a transaction, corresponding to the raw response value.

Note that the ARC can differ depending on the card scheme, so in general it is not recommended to code against this field. But if you have a multiple-acquirer setup where your code is already based on variable ARC values, you can use the ARC to determine the authorization status.

Error response

The following example shows the type of information you receive when an error occurs with your API request.

Error codes

For information about error codes you can receive, see Generic error codes.

See also