Testing
Saferpay offers an extensive Sandbox, that allows you to simulate transactions, flows and other things, like Mail Phone Order, or the Secure PayGate. When integrating Saferpay, it is very benefitial, to create your own test-account. You can get your own test-account over here.
Everything you need will be sent to you via E-Mail, ncluding things like your test CustomerId, TerminalIds, the login for the Saferpay Test-Backoffice, API user and password etc.
Difference between the Test and Live environments
First and foremost, test and live are completely seperated systems. So everything you do on one or the other, cannot be transferred to the other system, like your transactions or your saved cards. Due to this, it is very important, that you also seperate your data accordingly and keep an eye on which system the data belongs to. If actions are performed with data, that does not belong to the respective system, the action will fail. This is so merchants may not confuse one system, with the other. For example by running on the test environment, whilst thinking they're live.
To reinforce this philosophy, Saferpay will not accept real credit cards on the test environment and vice versa! The test environment uses especially designed test-card, which can be found further down on this page, alongside information about the simulators.
Furthermore, the test environment only runs simulators, that will emulate the behavior of the given payment method. However, no real money will be transferred, of course.
The test environment will behave as closely to the live environment, as possible -aside the above mentioned differences-. To ensure this, every function and every URL is mirrored onto the test environment. For example the live backoffice can be found under https://www.saferpay.com/bo/login, whereas the test backoffice can be found under https://test.saferpay.com/bo/login. You can access any URL, by simply changing the www to test and vice versa. This also applies to API URLs. For example
https://test.saferpay.com/api/Payment/v1/PaymentPage/Initializeandhttps://www.saferpay.com/api/Payment/v1/PaymentPage/Initialize. The JSON-Object structure is the same on both systems, making a switch as easy, as possible.
Simulators and Test cards
Saferpay offers an array of simulators and also connections to certain sandboxes.
In this chapter, you will find every information, you need in order to test and, if needed, activate your desired payment method for testing.
These test payment means only work on the Saferpay Test environment and not on any live-account/the production environment.
On production, you must use youir own, real payment means, like a credit card.
While we generally aim to make the simulators as intuitive, as possible:
They are simulators!
Not all test cases may be available, or are triggered the way you'd expect. All Saferpay Simulators do not connect to real sytems (especially important in cases, where a 3rd party is simulated) and thus do not perform end-to-end tests.
However Saferpay does offer the possibility to connect towards Sandboxes, if a 3rd party provider offers such an environment. Please contact the Integration Support, for information on the availability and how to connect towards a sandbox.
If you have questions, problems or other inquiries, about testing, please contact the Integration Support for help.
Account-to-Account Payments
Saferpay offers an A2A that is controlled via the amount and has the following values.
Authorization
| Amount | Test case |
|---|---|
40300tt | Simulates a PENDING authorization, that lasts tt seconds and then results in a successful transaction. |
40400tt | Simulates a PENDING authorization, that lasts tt seconds and then results in a declined transaction. |
4120000 | Results in a general decline. |
Refund
| Amount | Test Case |
|---|---|
8120000 | The refund will be declined. |
Any other amount may result in a general success.
Please contact the Integration Support, if you want to test Account-to-Account Payments.
Alipay
Please contact the Integration Support, if you want to test Alipay.
American Express
It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test cards:
Card Number | Test-case |
9070003150000008 | Frictionless Y. Card simulates a fully successful Frictionless Flow! Liability shift: YES, Authenticated: true |
9070003750000002 | LiabilityShift can't be granted, due to technical reasons. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift! Liability shift: false, Authenticated: N/A |
9070004950000008 | Challenged Y. This card simulates a successful challenged flow. Liability shift: true, Authenticated: true |
9070004250000005 | Challenged A. The authentication was not successful, but LiabilityShift is still granted. Liability shift: true, Authenticated: false |
9070004350000004 | Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case! Liability shift: N/A, Authenticated: N/A |
9070004150000006 | 3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift. Card goes through a Challanged flow beforehand! Liability shift: false, Authenticated: false |
9070103204160004 | Card, to simulate a Soft Decline. This card will ALWAYS return a Soft-Decline, even if SCA was performed! |
Apple Pay
Saferpay does offer an extensive Apple Pay simulator. All test-cases are controlled through the simulator-ui. Unlike production, you do not need an Apple device, or browser, to test Apple Pay!
Please refer to the Activation section, to see, how to activate Applepay on the test-environment.
Note, that the server-to-server method does not use the Saferpay simulator, but instead needs special test-cards provided by Apple, which you can find over here.
Please note: Only the Mastercard PANs are supported at this point!
Bancontact
It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test cards:
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 | Test-case |
9110803150000003 | Frictionless Card "enrolled". Liability shift: YES |
9110803350000001 | "Authentication failed". The card holder failed to authenticate him/herself! Important: In this case, the authorization will fail! |
9110804950000003 | Challenge Card "enrolled". This card is subjected to the full 3D Secure authentication process! Liability shift: YES |
Diners Club International & Discover Card
It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test cards:
Discover is tested as Diners, due to their similarities.
Card Number | Test-case |
9050003150000002 | Frictionless Y. Card simulates a fully successful Frictionless Flow! Liability shift: YES, Authenticated: true |
9050003250000001 | LiabilityShift can't be granted, due to technical reasons. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift! Liability shift: false, Authenticated: N/A |
9050004950000002 | Challenged Y. This card simulates a successful challenged flow. Liability shift: true, Authenticated: true |
9050004250000009 | Challenged A. The authentication was not successful, but LiabilityShift is still granted. Liability shift: true, Authenticated: false |
9050004350000008 | Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case! Liability shift: N/A, Authenticated: N/A |
9050004550000006 | 3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift! Crd goes through a Challanged flow beforehand! Liability shift: false, Authenticated: false |
e-przelewy
Please contact the Integration Support, if you want to test e-przelewy.
eps
Please contact the Integration Support, if you want to test eps.
giropay
Saferpay does offer an extensive giropay simulator. All test-cases are controlled through the simulator-ui, when opening up the payment page.
Please contact the Integration Support, if you want to test giropay.
Google Pay
Simply activate Google Pay for your terminal on the test environment (see Google Pay Activation). That will take care of everything necessary for the Payment Page. Google Pay on the Payment Page also supports
Please only activate the Google Pay Simulator for testing. Activating standard Google Pay will lead to processing-issues and thusly does not work.
For the Server-to-Server method, you can use our normal test cards in conjunction with our Google Pay Token generator, in order to test GooglePay Server-To-Server, using the normal test-cases, our cards offer you. The generated payment tokens just simply have to be submitted to Saferpay, as described above.
iDEAL
Saferpay does offer an extensive iDEAL simulator. All test-cases are controlled through the simulator-ui, when opening up the payment page.
Please contact the Integration Support, if you want to test iDEAL.
Testing Cases
The following cases must be simulated via amount and not GUI. Simply do a redirect, without selecting a case on the GUI!
Amount | Test-case |
490 | Session-Timeout: Transaction results in an Open-Case. User gets redirected to the FailUrl, with the Assert reporting a TRANSACTION_STILL_IN_PROGRESS error. The NotifyUrl is then called 10 minutes later, with the Assert reporting a success. |
Values for testing Pre-Selection
The following values can be used, if you want to test the Bank Pre-Selection:
Bank | Value |
Test Bank 1 | 0091 |
Test Bank 2 | 0092 |
JCB
It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test cards:
Card Number | Test-case |
9060003150000000 | Frictionless Y. Card simulates a fully successful Frictionless Flow! Liability shift: YES, Authenticated: true |
9060004950000000 | Challenged Y. This card simulates a successful challenged flow. Liability shift: true, Authenticated: true |
9060004250000007 | Challenged A. The authentication was not successful, but LiabilityShift is still granted. Liability shift: true, Authenticated: false |
9060004350000006 | Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case! Liability shift: N/A, Authenticated: N/A |
9060002750000006 | 3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift. Liability shift: false, Authenticated: false |
Klarna Payments
Saferpay does offer an extensive Klarna Payments simulator and also the possibility, to work on the Klarna Sandbox. All test-cases are controlled through the ui, however you must follow the rules under Integration, or Klarna won't be displayed.
Please refer to the Activation section, to see, how to activate Klarna Payments on the test-environment.
Maestro International
It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test cards:
Card Number | Test-case |
9040003150000005 | Frictionless Y. Card simulates a fully successful Frictionless Flow! Liability shift: YES, Authenticated: true |
9040003550000001 | LiabilityShift can't be granted, due to technical reasons. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift! Liability shift: false, Authenticated: N/A |
9040004950000005 | Challenged Y. This card simulates a successful challenged flow. Liability shift: true, Authenticated: true |
9040004250000002 | Challenged A. The authentication was not successful, but LiabilityShift is still granted. Liability shift: true, Authenticated: false |
9040004350000001 | Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case! Liability shift: N/A, Authenticated: N/A |
9040004350000001 | 3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift! Crd goes through a Challanged flow beforehand! Liability shift: false, Authenticated: false |
Mastercard
It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test cards:
Card Number | Test-case |
9030003150000007 | Frictionless Y. Card simulates a fully successful Frictionless Flow! Liability shift: YES, Authenticated: true |
9030003750000001 | LiabilityShift can't be granted, due to technical reasons. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift! Liability shift: false, Authenticated: N/A |
9030004950000007 | Challenged Y. This card simulates a successful challenged flow. Liability shift: true, Authenticated: true |
9030004250000004 | Challenged A. The authentication was not successful, but LiabilityShift is still granted. Liability shift: true, Authenticated: false |
9030004350000003 | Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case! Liability shift: N/A, Authenticated: N/A |
9030004150000005 | 3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift! Crd goes through a Challanged flow beforehand! Liability shift: false, Authenticated: false |
9030403104000006 | Frictionless Y with DCC. This card additionally will perform DCC. Card currency is USD! Liability shift: true, Authenticated: true |
9030503104000003 | Frictionless Y with DCC. This card additionally will perform DCC. Card currency is JPY! Liability shift: true, Authenticated: true |
9030403153150009 | General Decline. This card fails the authorization and also the card check! Liability shift: true, Authenticated: true |
9030403153900007 | Card for simulating response codes via the amount. The last two digits inside the amount are important. Down below you'll find some examples for return-codes/amounts. The codes must be the last digits of the amount eg. 123nn. Important Note: These are the most common codes! However some Issuers may return codes not on this list! 00: See Frictionless Y 01: Successful Authorization and 3DS process. However LiabilityShift will be rejected during authorization. 62: Restricted Card 51: Insufficient Funds 43: Stolen Card 34: Suspicion of manipulation 33: Card Expired 30: Format Error 14: Invalid Card 12: Invalid Transaction 09: Processing temporarily not possible 05: Authorization declined 04: Card Invalid 03: Invalid Merchant Number |
9030100000021017 | Card, to simulate a partial approval. |
9030103204160003 | Card, to simulate a Soft Decline. This card will ALWAYS return a Soft-Decline, even if SCA was performed! |
9030100000001019 | For Issuer Installments: One fixed installment plan. |
9030100000002017 | For Issuer Installments: Many fixed installment plans. |
9030100000003015 | For Issuer Installments: Custom Plan. |
paydirekt
Saferpay does offer an extensive paydirekt simulator. All test-cases are controlled through the simulator-ui, when opening up the payment page.
Please contact the Integration Support, if you want to test paydirekt.
PayPal
Saferpay does offer an extensive PayPal simulator. All test-cases are controlled through the simulator-ui, when opening up the payment page.
PostFinance Pay
Please contact the Integration Support, if you want to test PostFinance Pay.
SEPA Direct Debit
It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test IBANs:
IBAN | Test-case |
DE17970000011234567890 | "Success IBAN". IBAN to simulate a successful transaction. |
DE52970000021234567890 | IBAN to "simulate response codes". IBAN for controlling authorisation codes via the amount. 210nn simumulates a decline, where "nn" is the simmulated decline code. Requests with other amounts simumulate positive responses. |
Sofort by Klarna
Sofort only works via the Sofort Sandbox. In order to test Sofort, please follow the activation-guide here. However you also have to put your newely created project into Test Mode. Once you have activated your project in test-mode, please contact the Integration Support.
Please submit your Sofort project-details (Sofort CustomerId, ProjectId and Password), aswell as the Id of the test-terminal, you want Sofort to be activated on.
We recommend to use a seperate Project from your Live project! However if you decide to use the same project for both, make sure, that you de-activate Test Mode, once you go live. Otherwise, people will be able to "pay" in your shop, by using test-data!
Test-data will be provided by Sofort, once you have activated the Test Mode.
TWINT
On the test environment, Saferpay offers a TWINT Simulator for the Currencies 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:
The "Abort"-button does not work, unless a decline amount is set. It would result in an abort and then, after the 20 seconds (see below) are expired, the transaction is successful.
All test-cases are amount-controlled.
Any other amount will cause a success after 20 seconds!
Amount | Test-case | Payment Page | Authorize Direct |
30000tt | The execution of the (successful) authorization is delayed by tt seconds. | ✅ | ❌ |
4120000 | Authorization declined | ✅ | ✅ |
4220000 | Authorization expired | ✅ | ❌ |
4320000 | Authorization cancelled | ✅ | ❌ |
UnionPay
Saferpay does offer an extensive UnionPay simulator. All test-cases are controlled through the simulator-ui, when opening up the Payment Page. However, you need to use the following test-card, in order to activate it: 9100104952000008.
Visa & V PAY
It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test cards:
V PAY is tested and processed as Visa.
Card Number | Test-case |
9010003150000001 | Frictionless Y. Card simulates a fully successful Frictionless Flow! Liability shift: YES, Authenticated: true |
9010003750000005 | LiabilityShift can't be granted, due to technical reasons. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift! Liability shift: false, Authenticated: N/A |
9010004950000001 | Challenged Y. This card simulates a successful challenged flow. Liability shift: true, Authenticated: true |
9010004250000008 | Challenged A. The authentication was not successful, but LiabilityShift is still granted. Liability shift: true, Authenticated: false |
9010004350000007 | Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case! Liability shift: N/A, Authenticated: N/A |
9010004150000009 | 3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift! Crd goes through a Challanged flow beforehand! Liability shift: false, Authenticated: false |
9010403104000000 | Frictionless Y with DCC. This card additionally will perform DCC. Card currency is USD! Liability shift: true, Authenticated: true |
9010503104000007 | Frictionless Y with DCC. This card additionally will perform DCC. Card currency is JPY! Liability shift: true, Authenticated: true |
9010403153150003 | General Decline. This card fails the card check! Liability shift: true, Authenticated: true |
9010403153900001 | Card for simulating response codes via the amount. The last two digits inside the amount are important. Down below you'll find some examples for return-codes/amounts. The codes must be the last digits of the amount eg. 123nn. Important Note: These are the most common codes! However some Issuers may return codes not on this list! 00: See Frictionless Y 01: Successful Authorization and 3DS process. However LiabilityShift will be rejected during authorization. 62: Restricted Card 51: Insufficient Funds 43: Stolen Card 34: Suspicion of manipulation 33: Card Expired 30: Format Error 14: Invalid Card 12: Invalid Transaction 09: Processing temporarily not possible 05: Authorization declined 04: Card Invalid 03: Invalid Merchant Number |
9010100000020013 | Card, to simulate a partial approval. |
9010103204160007 | Card, to simulate a Soft Decline. This card will ALWAYS return a Soft-Decline, even if SCA was performed! |
WeChat Pay
Please contact the Integration Support, if you want to test WeChat Pay.
WL Crypto Payments
Saferpay does offer an extensive WL Crypto Payments simulator. Almost all test-cases are controlled through the simulator-ui, when opening up the payment page.
Please contact the Integration Support, if you want to test WL Crypto Payments.
The following test-cases must be controlled, via the Payment.OrderId:
Test case | Value |
Forcing a | Notify_DelayedResponse300 |
Last updated