Sandbox (Testing environment)

The Premium API - Payments is included in a Sandbox environment to test your applications before accessing to live data. A set of non-real users were created by default for each of your applications (see tables below). In order to test this service, use one of the accounts below as debtor account in the POST Payment Initiation Request method, and to ensure successful processing, please make sure the selected account matches the selected user. Additionally, make sure that selected user has sufficient financial resources on selected account. 

Sandbox available accounts

USER: Student (930423) 

Account identifier Balance
SK6911000000003968781519 200.20 €
SK5502000000007417228408 58.3€


USER: Affluent client (940423) 

Account identifier Balance
SK3711000000007417228416 5000.20 €

 

USER: Entrepreneur (950423) 

Account identifier Balance
SK5311000000008150082722 12000.20 €

 

USER: Small-medium enterprise (960423) 

Account identifier Balance
SK6411000000001067980992 15000.20 €

 

USER:  Large corporate (970423)

Account identifier Balance
SK1911000000001913888635 (Credit account) 25000.20 €
SK4011000000004145138420 (Debit account) 18000.20 €

 

Single Payments Sandbox limitations and conditions

Sandbox does not support banking days, cut off-times nor payment limits 
Sandbox accepts payments from Sandbox user accounts (listed above)
 

Possible Payment Initiation error use cases 

  • InstructionIdentification duplicity 
  • Payment made with old date 
  • Payment made with future date (more than 61 days)

Possible Payment Submission status conditions

  • Payment goes into status “ACSC” when it is submitted with today’s date
  • Payment goes into status “PDNG” when it is submitted with future date (no more than 61 days) 
  • Payment goes into status “ACSP” for two hours, if the creditor IBAN is non-SK. After two hours, the payment goes to status “RJCT” or “ACSC”. 

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 two hours after making the payment.

For example, you can use the following IBAN: CZ5508000000001234567899

Possible Payment Submission error use cases: 

  • Payment made in past (if payment would be made the next day after initiation) 
  • Insufficient funds on the selected account

Offline processing:

Expiration 
  • Every minute
  • Applies for payments in status ACTC with posting date in past
Processing of payments in status PDNG
  • Every hour (15th minute every hour)
  • Moves payments from PDNG to ACSC or RJCT 
Processing of payments in status ACSP
  • Every 15 minutes
  • Moves payments from ACSP to ACSC or RJCT

Single Instant Payments Sandbox limitations and conditions

  • Payment submitted as instant payment will remain in ACSP status for 30-60 seconds, then it goes to RJCT or ACSC status
  • The total amount of the payment is compared to the user’s Sandbox balance

Possible Single Instant Payment Initiation errors use cases

  • Instruction Identification duplicity 
  • Payment made with old date 
  • Payment made with future date (more than 61 days)

Possible Single Instant Payment Submission status conditions

•Payment goes into status “PDNG” when it is submitted with future date (no more than 61 days)

•Payment goes into status “ACSP” status if it was submitted as instant. It remains in this status for 30-60 seconds and then it moves into “RJCT” or “ACSC” status (simulation of the processing of instant payments).

  • Payment submitted with today’s date for SK IBAN goes to status ACSC
  • Payment goes into status “ACSP” for two hours, if the creditor IBAN is non-SK. After two hours, the payment goes to status “RJCT” or “ACSC”.

Possible Single Instant Payment Submission error use cases

  • Payment made in past
  • Insufficient funds on the selected account
  • Exceeded instant payment limit for instant payment (this only applies for instant payments and not for TB/RB internal payments)
  • If the payment was submitted as MANDATORY instant, it goes into status RJCT (after transition from ACSP status)
  • If the payment was submitted as OPTIONAL instant, it goes into ACSC status (after transition from ACSP status), meanwhile having filled structure instantPaymentInfo:
  • instantPayment = false
  • AdditionalReasonCode = AM23
  • AdditionalReasonDesc = Transaction amount exceeds settlement limit.

Instant Payment statuses

  • Please note that Instant payments submitted for TB/RB accounts won’t be executed as instant payments. If these payments finish with ACSC status, the instantPaymentInfo will be following:
  • instantPayment = false
  •         - additionalReasonCode = instantPaymentInfo.setAdditionalReasonCode("AG03");
  •         - additionalReasonDesc = instantPaymentInfo.setAdditionalReasonDesc("Instant payment is not supported for swift TATRSKBX, payment will be processed as internal payment");

Instant Payment cancelation

  • Permissible cancelation is only allowed for payments with status ACTC and PDNG

Offline processing:

  • Expiration of initiated payment is executed every day at 00:10 AM including all the payments in status ACTC that have posting_date in the past.
  • Processing of payments in status PDNG run every hour (every 15th minute of new hour) including payments transitioning the payments from PDNG into ACSC or RJCT
  • Processing of payments in status ASCP runs every minute and transmissions payments from ACSP TO ACSC OR RJCT if the payment was initiated more than 30 seconds before. The status changes after 30-60 seconds.

 

Bulk Standard and Instant Payments Sandbox limitations and conditions

Sandbox does not support banking days, cut off-times nor payment limits, current exchange rates
Sandbox accepts payments from Sandbox user accounts (listed above).
 

Possible Payment Initiation error use cases

  • instructionIdentification duplicity 
  • Payment made with old date 
  • Payment made with future date (more than 61 days)
  • Debtor account is not one of the Sandbox users account
  • Debtor account is one of the Sandbox users account but it is not TB account
  • Payments in the bulk does not have same ReqdExctnDt
  • Payments in the bulk does not have same debtor account
  • Invalid creditor account 
  • Combination of SK and non-SK IBANs for a bulk where debtor account is in EUR
  • More than 500 payments in a bulk 
  • Charge bearer (ChrgBr) is not SLEV
  • Payment method (PmtMtd) is not TRF
  • PmtTpInf.InstrPrty is not NORM
  • PmtTpInf.SvcLvl is not SEPA
  • PmtTpInf.LclInstrm is NO_FNDS_CHK
  • DbtrAgt.FinInstnId.BIC is not TATRSKBX
  • All initiated transactions have to be set as instant in sandbox bulk instant payment

Possible Payment Submission status conditions

  • Payment goes into status “ACSC” when it is submitted with today’s date
  • Payment goes into status “PDNG” when it is submitted with future date (no more than 61 days) 
  • Payment goes into status “ACSP” for two hours, if the creditor IBAN is non-SK. After two hours, the payment goes to status “RJCT” or “ACSC”. 
  • Instant Bulk payment goes into "ACSP" for 30-60 seconds , then automatically switched to "RJCT" or "ACSC"
  • Standard bulk payments goes into "ACSC" status immediately

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 two hours after making the payment.

For example, you can use the following IBAN: CZ5508000000001234567899

Possible Payment Submission error use cases: 

  • Payment made in past (if payment would be made the next day after initiation) 
  • Insufficient funds on the selected account
  • Bulk payment limit exceeded
    • MANDATORY flow - all transactions and bulk rejected
    • OPTIONAL flow - bulk ends with "ACSC" and additional information will be send in additionalInformation section as a second part of response (MULTIPART/mixed)
  • In case of bulk instant payment, path parameter "pain.001-instant-sepa-credit-transfers" as payment-product attribute mentioned in swagger has to be used, otherwise error will be returned.

Cancel payment

  • Possible in "PDNG", "ACSP" status
  • For "ACTC" will return error with description "WILL_BE_EXPIRED" - means that initiated payment will be marked as expired

Offline processing:

Expiration 
  • Every minute
  • Applies for payments in status ACTC with posting date in past
Processing of payments in status PDNG
  • Every hour (15th minute every hour)
  • Moves payments from PDNG to ACSC or RJCT 
Processing of payments in status ACSP