Saferpay Test Account
Saferpay offers the possibility to test all interfaces in a specially for you created test account.
The Saferpay test account allows you to implement Saferpay into your system and make test transactions over several payment simulators before going live.
The https interface is NOT available for individual test accounts! We strongly recommend using the Saferpay JSON API. If this is not feasible, use the general test account for the https interface!
Looking for the entry to the Saferpay test Backoffice?
IMPORTANT: The Saferpay test account is separated from your Saferpay live account. Access details, log-in data etc. for the test account CANNOT be used on the live account and vice versa.
Therefore, please ensure that you use the correct access data upon changing over from the test account to the live account.
By default, all Saferpay functions are activated on the test accounts, including Saferpay Business functions. Please note that the Business functions will no longer be available on your account later if you have not concluded a Saferpay Business contract.
Please consult the licence matrix in the JSON API documentation in order to evaluate which functions are available with which licence.
Using Saferpay JSON API with the test account
To ensure that the requests are sent to the test account, you are required to adjust the base URL for requests.
Base URL: https://test.saferpay.com/api
All other URLs are derived from this base URL. For example:
https://test.saferpay.com/api/Payment/v1/Transaction/Initialize
Credentials for HTTP Basic Authentication can be created in the test Backoffice under "Settings > JSON API Basic Authentication"
JSON API Online Help
Do you need help with the integration?
You can now also view the Saferpay specifications and documentations online. This includes a number of examples which you can use as well as a full parameter description for all interfaces to and from Saferpay.
Older API
If desired, older Saferpay interfaces can be tested either with the Saferpay Client Libraries for JAVA and .NET or the https interface.
The general test account features all the necessary functions
Please note that older Saferpay interfaces will not be developed further. We therefore STRONGLY recommend choosing the JSON API for a new implementation.
You can derive the ACCOUNTID from the data specified above as follows: CUSTOMERID-TERMINALID, i.e. 401860-17795278
The Saferpay Clients are available in the Saferpay Backoffice download center. In order to ensure that all of the functions described in the documentation are available, you should always use the latest version.
The recent version of the Saferpay Java Client Library is 2.1.1.
The version can be retrieved by a command line call:
java -jar Saferpay.jar -h
The recent version of the Saferpay .NET Library is 3.0.0.
Find out your version of the .NET Library by right-clicking on com.saferpay.Client.dll, choosing "Properties" and "Version".
Information about the Client Libraries can be found in the Payment Page Specification and in the Authorization Interface Documentation, in each case in chapter 2.
The following command line call will configure the Java LIB for the test account:
java -jar Saferpay.jar -conf -p . -r https://test.saferpay.com/user/setup.asp -u <BACKOFFICE USER> -w <BACKOFFICE PASSWORD>
The .NET Client can be configured by a command line call as well:
saferpay -conf -p . -r https://test.saferpay.com/user/setup.asp -u <BACKOFFICE USER> -w <BACKOFFICE PASSWORD>
Call the command line help to show all options:
saferpay.exe -h
If you prefer to configure the .NET Client in a GUI, you can download a .NET Client that is already modified for the Saferpay test account from the download center.
ATTENTION!
When you are executing the configuration inside your existing config-folder, Saferpay will overwrite it. If you want to use both, test and production, then you have to follow the next steps.
Changes inside your application-code
First of all you have to change your existing AccountId with the one for you testaccount.
You can derive it from your test-data using the following format:
CUSTOMERID-TERMINALID
Switching between test and production
If you want to switch between test and production at will, then you have to change your program code to be able to switch between the two configurations.
First it is important to create a configuration for test AND production (see above).
In order for them to be crated in different folders, so they not interfere with each other, you can use the attribute -p. This accepts the corresponding path for the new configuration.
Once you have created both configurations, you need to pass the new paths to your application.
For that you have to search for a code-line similar to this:
mf.open("C:\\path\to\configuration");
You have to make sure, that the correct path is passed to this method, when you are switching between test and production.
Saferpay Test Data
WARNING! The simulators do not accept genuine credit cards or payment means.
You can enter a random value for CVC/Expiry date, but please note that a date in the past will cause an error because the card is expired.
Credit- and debit cards
| Card number |
Type | |
|---|---|---|
| 9010100052000004 |
Card "enrolled". This card is subjected to the full 3D Secure authentication process. Liability shift: YES (ECI=1, Authenticated=true) | |
| 9010101052000002 |
Card not enrolled". Bank grants liability shift. Liability shift: YES (ECI=2, Authenticated=false) | |
| 9010101152000001 |
"Unable to enroll". Simulates an impossible 3D secure authentication. Liability shift: NO (ECI=0, Authenticated=false)Haftungsumkehr: NEIN (ECI=0, Authenticated=false) | |
| 9010100152000003 |
"Authentication failed". This card simulates the failed authentication of the cardholder. Liability shift: NO (ECI=0 after forwarding, Authenticated=false) | |
| 9010100352000001 |
"Authentication attempt". Simulates an authentication attempt in which the bank grants a liability shift. Liability shift: YES (ECI=2, Authenticated=false) | |
| 9010101052101008 |
"Not enrolled". Liability shift is rejected. Liability shift: NO (ECI=0 with authorisation response, Authenticated=false) | |
| 9010100052101000 | "Enrolled". Liability shift is rejected despite authentication. | |
| 9010101052900003 |
Card for controlling authorisation codes via the amount.
| |
| 9010500004000004 | Card for DCC requests with the card currency JPY. | |
| 9010400004000007 | Card for DCC requests with the card currency USD. | |
| 9010000004150008 | "CARD_CHECK_FAILED". A decline will be simulated by internal card check with Alias InsertDirect. Authorization request with this card will be declined as well. |
| Card number |
Type | |
|---|---|---|
|
9030100052000000 |
Card "enrolled". This card is subjected to the full 3D Secure authentication process. Liability shift: YES (ECI=1, Authenticated=true) | |
| 9030101152000007 |
"Unable to enroll". Simulates an impossible 3D secure authentication. Liability shift: NO (ECI=0, Authenticated=false) | |
| 9030100152000009 |
"Authentication failed". This card simulates the failed authentication of the cardholder. Liability shift: NO (ECI=0 after forwarding, Authenticated=false) | |
| 9030100352000007 |
"Authentication attempt". Liability shift: YES (ECI=2, Authenticated=false) | |
| 9030101052101004 |
"Not enrolled". Liability shift is rejected. Liability shift: NO (ECI=0 with authorisation response, Authenticated=false) | |
| 9030100052101006 |
"Enrolled". Liability shift is rejected despite authentication. Liability shift: NO (ECI=0 with authorisation response, Authenticated=true) | |
| 9030101052900009 |
Card for controlling authorisation codes via the amount.
| |
| 9030500004000000 | Card for DCC requests with the card currency JPY. | |
| 9030400004000003 | Card for DCC requests with the card currency USD. | |
| 9030000004150004 | "CARD_CHECK_FAILED". Simuliert eine Ablehnung bei der internen Kartenüberprüfung mit Alias InsertDirect. Autorisationsanfragen mit dieser Karte werden abgelehnt. |
| Card number |
Type |
|---|---|
|
9070100052000001 |
Card "enrolled". This card is subjected to the full 3D Secure authentication process. Liability shift: YES (ECI=1, Authenticated=true) |
| 9070101152000008 |
"Unable to enroll". Simulates an impossible 3D secure authentication. Liability shift: NO (ECI=0, Authenticated=false) |
| 9070100152000000 |
"Authentication failed". This card simulates the failed authentication of the cardholder. Liability shift: NO (ECI=0 after forwarding, Authenticated=false) |
| 9070100352000008 |
"Authentication attempt". Simulates an authentication attempt in which the bank grants a liability shift. Liability shift: YES (ECI=2, Authenticated=false) |
| 9070101052101005 |
"Not enrolled". Liability shift is rejected. Liability shift: NO (ECI=0 with authorisation response, Authenticated=false) |
| 9070100052101007 |
"Enrolled". Liability shift is rejected despite authentication. Liability shift: NO (ECI=0 with authorisation response, Authenticated=true) |
| 9070101052900000 |
Card for controlling authorisation codes via the amount.
|
| Card number |
Type |
|---|---|
|
9040100052000008 |
Card "enrolled". This card is subjected to the full 3D Secure authentication process. Liability shift: YES (ECI=1, Authenticated=true) |
| 9040100152000007 |
"Authentication failed". This card simulates the failed authentication of the cardholder. Liability shift: NO (ECI=0 after forwarding, Authenticated=false) |
| 9040100352000005 |
"Authentication attempt". Simulates an authentication attempt in which the bank grants a liability shift. Liability shift: YES (ECI=2, Authenticated=false) |
| 9040100052101004 |
"Enrolled". Liability shift is rejected despite authentication. Liability shift: NO (ECI=0 with authorisation response, Authenticated=true) |
| 9040101052900007 |
Card for controlling authorisation codes via the amount.
|
| Card number |
Type |
|---|---|
|
9050100052000005 |
Card "enrolled". This card is subjected to the full 3D Secure authentication process. Liability shift: YES (ECI=1, Authenticated=true) |
| 9050101152000002 |
"Unable to enroll". Simulates an impossible 3D secure authentication. Liability shift: NO (ECI=0, Authenticated=false)Haftungsumkehr: NEIN (ECI=0, Authenticated=false) |
| 9050100152000004 |
"Authentication failed". This card simulates the failed authentication of the cardholder. Liability shift: NO (ECI=0 after forwarding, Authenticated=false) |
| 9050100352000002 |
"Authentication attempt". Simulates an authentication attempt in which the bank grants a liability shift. Liability shift: YES (ECI=2, Authenticated=false) |
| 9050101052101009 |
"Not enrolled". Liability shift is rejected. Liability shift: NO (ECI=0 with authorisation response, Authenticated=false) |
| 9050100052101001 | "Enrolled". Liability shift is rejected despite authentication. |
| 9050101052900004 |
Card for controlling authorisation codes via the amount.
|
| Card number |
Type |
|---|---|
| 9060100052000003 |
Card to simulate a successful transaction. |
| 9060101052900002 |
Card for controlling authorisation codes via the amount.
|
| Card number |
Type |
|---|---|
| 9080100052000009 | Card to simulate a successful transaction. |
| 9080101052900008 |
Card for controlling authorisation codes via the amount.
|
| Card number |
Type |
|---|---|
| 9090100052000007 | Card to simulate a successful transaction. |
| 9090101052900006 |
Card for controlling authorisation codes via the amount.
|
Bancontact uses an authentication-procedure similar to 3D Secure with VISA and MasterCard. However the difference is, that Bancontact will automatically refuse all payments, that aren't fully authenticated. Due to this, there are only these few outcomes possible.
| Card number |
Type |
|---|---|
| 91108000500000005 |
Card "enrolled". This card is subjected to the full 3D Secure authentication process. Liability shift: YES (Authenticated=true) |
| 91108001501800005 |
"Authentication failed". This card simulates the failed authentication of the cardholder. Liability shift: NO (Authenticated=false) |
| IBAN | Type |
|---|---|
| DE17970000011234567890 | IBAN to simulate a successful transaction. |
| DE52970000021234567890 |
IBAN for controlling authorisation codes via the amount. 210nn simulates a decline, where "nn" is the simulated decline code. Requests with other amounts simulate positive responses. |
PayPal Simulator
PayPal payments can be operated by a simulator in the Saferpay test account. The first version of the simulator supports successful transactions and declines only. The range of function will be upgraded soon.
On the test environment, Saferpay offers a TWINT Simulator for the currency CHF only, since this payment method is only avalable for the Swiss market.
The Simulator is controlled by submitting different amount-values to simulate the following cases:
Any other amount will cause a success after 20 seconds!
| Amount | Test Case |
|---|---|
| 6611 | The execution of the debit callback is delayed by 1 second |
| 6612 | The execution of the debit callback is delayed by 10 seconds |
| 6613 | The execution of the debit callback is delayed by 60 seconds |
| 6614 | The execution of the debit callback is delayed by 120 seconds |
| 6615 | The execution of the debit callback is delayed by 600 seconds |
| 6651 |
Returns authorization declined result |
| 6661 | Returns authorization expired result |
Saferpay provides an extensive iDeal simulator. All test-cases are controlled through the simulator-user-interface, when opening up the payment page.
Saferpay provides an extensive paydirekt simulator. All test-cases are controlled through the simulator-user-interface, when opening up the payment page.
Saferpay provides an extensive UnionPay simulator. All test-cases are controlled via the simulator-user-interface, when opening up the Payment Page. However, you need to use the following test-card, in order to activate the UnionPay simulator: 9100100052000005
General Test Account
Alternatively the general Saferpay test account can be used.
PLEASE NOTE:
This general test account may only be used, if the Saferpay https-Interface (Hosting-Service) is needed. If you are planning on using the Saferpay JSON-API, or even the old client libraries for .NET or JAVA, we advise you, to register your own test account!
All Saferpay functions are activated on the test account as standard, including Saferpay Business functions.
This also implies the "new" function for Secure Card Data.
Even if you do not want to or cannot use Business, you can test all standard functions as usual.
Please note that the Business functions will no longer be available on your live account later if you have not concluded a Saferpay Business agreement.
Please consult the feature matrix in the appendix of the JSON API in order to evaluate which functions are available with which agreements.
General test account credentials
Saferpay test Backoffice credentials
- User name: e401860001
- Password: 6JE54wBz
Various terminals are available within the test account which can be accessed by CUSTOMERID and TERMINALID:
| CUSTOMERID | TERMINALID | Description |
|---|---|---|
| 401860 | 17795278 | Standard eCommerce terminal without DCC. |
|
17795484 |
eCommerce terminal for DCC payments in the base currency EUR. PLEASE NOTE: DCC is only available for Mastercard and Visa. | |
| 19304840 | Phone mail terminal for payments without 3DS and DCC. |
You can derive the ACCOUNTID from the above-specified data as follows: CUSTOMERID-TERMINALID, i.e. 401860-17795278
To test the Saferpay https Interface, please adjust the base URL. This makes sure that requests are sent to the test system.
Base URL: https://test.saferpay.com/hosting/
All other URLs are derived from this, for instance: https://test.saferpay.com/hosting/CreatePayInit.asp
For usage of the general test account the https password is obliged.
https Interface Access (spPassword): 8e7Yn5yk
Find a description of the HI methods in the Payment Page Specification (pdf) and in the Authorization Interface Documentation (pdf), in each case in chapter 4.
Please note that on the test account you must provide the spPasswort when calling up PayComplete. This is a feature of Saferpay Business and is later no longer necessary for Saferpay E-Commerce clients.
New certificate for test environment
For the Saferpay test environment (https://test.saferpay.com) the SSL security certificate was renewed. Modifications on your site are not necessary in most cases, because normally a certificate is updated automatically.
The new certificate must be imported only if you use your own truststore.
Download of the new certificate
You can download the new certificate for https://test.saferpay.com here: Certificate test environment (zip).