Please note that the Paylink simulator is causing problems with versions 3.1.x of Paylink, we are hoping to get an update out soon on the 3.2.x release.
Paylink includes a simulator which allows you to test post backs and redirects against test transactions. To use the simulator set the payment request test parameter to simulator .
You will be presented a page with a warning stating that you are using the simulator.
The page will initially display a tab asking you to process an authorisation. First though, we need to check that Paylink has received and configured the session against our parameters.
Select the tab header for "API Config". You will notice that details sent in the API are displayed as configured values in the API. Complex objects such as the Card Holder details are displayed in JSON format for inspection.
The redirection or POSTback URLs are shown with the source of the configuration. You may see
"ApiCall' - the url was defined via the API
"StoreConfig" - the url was defined in a configuration on our systems
"Default" - the url was taken from a default setting, normally inherited. This for example may be the default redirect parameter in preference to the success or failure url parameters.
"Simulator" - the url was provided directly by the simulator (you can change this url for testing)
JSON API Config
The JSON API config tab differs by showing the full packet of data that is used to configure Paylink under the hood. Whilst this is the same set of data, it is useful to interpret how Paylink will behave while performing integration testing.
To run a test transaction move back to the Process Auth tab.
On the process auth tab, we load dummy card data into the transaction and forward a transaction in real time to the authorisation test server. This simulates a live transaction however a "test" authorisation is enforced.
Once successfully processed, you should see a message stating that the transaction was authorised and the error code result message. Data is stored within the page for inspection and allows you to view the authorisation data as seen by the Paylink page.
The inspect result is available if a transaction has been processed and will display the outcome of the test transaction. This data can be used as an example of the data sent back for a POSTback call or a redirection.
Once data is returned you can run sample redirects between the Paylink engine and your server. Redirects are performed once a transaction has been authorised to return the user back to your store (redirect_success). If a user presses cancel or if a user's transaction is declined and they do not wish to proceed, the user is redirected to the redirect_failure url.
The simulator allows you to edit the API values below for testing during your session.
Clicking on the run modal redirect test will show a modal dialog and will allow multiple redirection tests to be performed for your integration testing
If you wish to edit the URL for testing, you may click on each URL to edit the value as required.
Once data is returned you can run sample postback tests between the Paylink engine and your server. The simulator allows you to edit this value below if you wish to forward a test elsewhere.
A dialog will display illustrating the postback call's result, 200 here being HTTP 200 OK.
Once data is returned you can test the email functionality of the account by sending a test customer email or merchant email based on the transaction result. To use, simply enter the required email address to receive the configured email for your account.
Our logging method returns, in brackets -
ME - if a Merchant Email
CE - if a Customer Email
followed by the result i.e. ...Email Sent to ...
If you request that emails are bypassed in the API or Merchant configuration, you will notice a result similar to [ME] ...Bypassed.