Sandbox

The sandbox environment is a controlled and simulated environment that allows clients to test and validate their integrations. Developers can use the sandbox to simulate various scenarios and test different functionalities of their applications. This includes testing data inputs, processing logic, error handling, and other critical integration aspects.

The primary purpose of the sandbox is to test integration between Silverflow and the user’s systems enabling clients to identify and resolve any issues or bugs without affecting genuine users and data.

The sandbox environment replicates the key components and configurations of the production environment. This includes APIs, service configurations, and other dependencies to closely mimic the real-world scenario in which the integration will operate.

Please be aware that Silverflow’s sandbox environment does not connect to the card networks’ simulators. Card network and issuer responses are generated by Silverflow internal components, intended to mock production responses. This isolation from the card networks provides a safe space to make changes and troubleshoot without risking disruption to live services. 

Silverflow aims to allow maximum flexibility for its sandbox users. In order to accomplish this, in the sandbox environment Silverflow does not strictly validate PANs, rather it accepts a wide range of PANs, following the methodology per the table below. 

The Silverflow authorization in Sandbox is driven by amount-based testing. The sandbox logic standardizes testing by structuring amounts into three distinct parts:

Amount Structure:

E.g., in order to trigger an authorization test case with response code 05 (do not honor), use the amount 100005. Please note that only test case scenarios as defined below are supported.

For POS scenarios, test cases have been adjusted due to a technical limitation that prevents amounts exceeding 5000, as higher values would trigger a PIN requirement. To accommodate this, the “test case” portion has been removed, and only the “scenario” and “response code” are used.

See the table below for more amount based logic as described here above:

Reconciliation information is automatically generated as transactions are done on the platform. For each cleared transaction, there will also be a reconciliation entry. One chargeback is created each day for a random transaction of the previous day, and Silverflow also mocks two entries with fixed amounts for the card network fee types. This is visible in the reconciliationDetails report

To mimic bank reconciliation we aggregate all the captures, disputes and card network fees and mock a total bank transfer in the networkFundsTransfer report. The amount in this report matches with the aggregate of reconciliationDetails with the same networkFundsTransferKey