Payment Status

The Payments API use two status codes that serve for two different purposes:

  1. The HTTP Status Code reflects the outcome of the API call (the HTTP operation on the resource). For more information see RFC2616 Status Code Definitions.
  2. The Status field in the Payment API payloads reflect the status of the payments resources. This Status is limited to the ISO 20022 Payment Status Code code-list enumeration.

Possible HTTP Status Codes for the Payments API are described in the Payments API Documentation.

Payment Status Code

Payment status code indicates the status of a single payment transaction. The Payment API supports following codes:

  • ACTC Accepted Technical Validation
  • ACSP Accepted Settlement In Process
  • ACSC Accepted Settlement Completed
  • ACCC Accepted Settlement Completed Creditor – in case of instant payment
  • PDNG Pending
  • RJCT Rejected


Payment initiation

To initiate a payment, you have to call one of the initiation methods e.g. POST /payments/ecomm/sba. After successful payment initiation with HTTP 201 Created response your payment may enter ACTC or RJCT state. Initiated payment can be rejected due to business validation rules fault e.g. AC01 - Creditor IBAN is not valid: CZ6575000000001234567891.

    "orderId": "EDE04525712C6C4B0FFC17D178BBB290",
    "status": "ACTC",
    "statusDateTime": "2017-11-07T10:16:29.198+01:00"


Payment order identifier

If the payment is initiated successfuly, the bank server returns Order ID which is unique identifier of the payment. This identifier may be used as a parameter for checking a payment status with GET /payments/{orderId}/status.

Payment submission

If the payment is initiated successfuly, the payment is in ACTC state and you can let your customer authorize the payment. in order to submit the payment, you have to call POST /payments/submission method. After your customer authorizes the payment and it is submitted, it changes its status:

  1. ACSP in case of successfull payment authorization
  2. PDNG in case of requested execution date is in future
  3. RJCT in case of failing business validation rule

Simulating ACSP status

In order to simulate the payment status ACSP, you should use any foreign beneficiary IBAN (non-SK). In case of using foreign beneficiary IBAN, the transaction goes to ACSP status for 30 second after making the payment.

For example, you can use the following IBAN: CZ5508000000001234567899

Transaction Reason Code

Transaction Reason code specifies the reason for a transaction to be rejected, returned or reversed by an instructed agent or somebody acting on behalf of an instructed agent. This reason is limited to the ISO 20022 Transaction Reason Code code-list enumeration.

    "status": "RJCT",
    "reasonCode": "AC01",
    "additionalInformation": "Creditor IBAN is not valid: CZ6575000000001234567891.",
    "statusDateTime": "2017-11-07T10:14:57.990+01:00"

The Payments API supports following codes:

  • AC01 Format of the account number specified is not correct.
  • AC04 Account number specified has been closed on the Receiver's books.
  • AG01 Transaction forbidden on this type of account.
  • AM03 Specified message amount is in a non processable currency outside of existing agreement.
  • AM04 Amount of funds available to cover specified message amount is insufficient.
  • AM05 This message appears to have been duplicated.
  • AM09 Amount received is not the amount agreed or expected.
  • AM10 Sum of instructed amounts does not equal the control sum.
  • DT01 Invalid date (e.g., wrong settlement date).
  • MS03 Reason has not been specified by agent.
  • RC01 Bank identifier code specified in the message has an incorrect format.
  • RR03 Missing creditor name or address (defined by SEPA Credit Transfer Scheme Rulebook).
  • TM01 Associated message was received after agreed processing cut-off time.