Skip to main content

Mock simulator

Introduction

The mock server for the acquiring system on SANDBOX (backend version 5.17.0) allows for the simulation of various backend responses by entering "magic numbers" as payment amount prefixes. These prefixes, when keyed into the terminal, force the MOCK server to return a predefined result, facilitating the testing of different application response scenarios.

Card Transactions

Magic Numbers: 42.XX - Simulation of Specific Response Codes

Mechanism: By entering an amount starting with 42. followed by a numeric code XX, the mock server returns the response code specified by XX. The client application's SDK maps these codes to localized user messages.

Code (42.XX)Response CodeDescription
42.0000Approved
42.0606Sequence error
42.0909Processing
42.1010Partial approval
42.1111Invalid transaction
42.2121No action taken
42.3333Card expired
42.4343Stolen card
42.5555Incorrect PIN
42.5656No card in DB
42.5858Terminal unknown
42.6060PIN necessary
42.6161Exceeds limit
42.6767Cash limit
42.7777PIN try limit
42.8686Frequency limit
42.8787Purchase only
42.9797Security breach
42.9898Time not plausible
42.9999PAC error (PIN Authentication Code)
Any otherXXGeneral Decline

Magic Numbers: 43.XX - Latency and Timeout Simulation

Mechanism: By entering an amount starting with 43. followed by a numeric value XX, the MOCK server simulates a successful transaction (corresponding to a Code 00) after a delay of XX seconds.

Behavior and Limits: If XX <= 30 seconds: Simulates a successful transaction after the specified delay. If XX > 30 seconds: The application or SDK, typically configured with a 30-second connection timeout, will throw a connection or timeout error.

Magic Numbers: 44.XX - Infrastructure Error Simulation

Mechanism: By entering an amount starting with 44. followed by a numeric value XX, the mock server forces a critical internal failure of the mock server itself.

Result: A server error is simulated (e.g., 500 Internal Server Error). The SDK will not receive a valid ISO-8583 response code; instead, a network or HTTP exception will be generated. There is no specific information detailing what XX values can be introduced to generate each particular error, as the error is simulated at the infrastructure level of the mock server.

APM Mockup on Sandbox Environment: Test Cases

Trx AmountBusiness Case
0,10Checkin DECLINED after 5s
0,11Checkin DECLINED after 10s
0,20Checkin EXPIRED after 5s
0,21Checkin EXPIRED after 10s
0,30Checkin SUCCESSFUL after 10s
0,31Checkin will never response
0,40Payment DECLINED after 5s
0,41Payment DECLINED after 10s
0,50Payment EXPIRED after 5s
0,51Payment EXPIRED after 10s
0,60Payment SUCCESSFUL after 10s
0,61Payment will never response
0,70Error from SATA in qr checkin
0,71Error from SATA in make
0,72Error from SATA in status
0,73Error from SATA in confirm
0,74Error from SATA in reversal (can be validate on scheduler)
1,00Refund CONFIRMED after 5s
1,10Refund CANCELLED after 5s
1,20Refund DECLINED after 5s
1,30Refund left in ACCEPTED status (auto reversal success)
1,70Error from SATA in makeRefund
1,71Error from SATA in monitorRefund
1,72Error from SATA in confirmRefund (possible only for SUCCESSFUL response)*
1,73Error from SATA in cancelRefund (possible only in autoreversals)
1,74PaymentNotification is sent after process ends: 10s

Defaults

  • Checkin: successful (CHECKINED) after 5s
  • Payment: successful (ACCEPTED) after 5s
  • Confirm/cancel: always succeed
  • Refund: successful after 5s

BLIK transactions