Testing and Go-Live
Saferpay offers an extensive Sandbox, that allows you to simulate transactions, flows and other things. 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, API user andpassword 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/Initialize and https://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.
If you have questions, problems or other inquiries, about testing, please contact the Integration Support for help.

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! Crd 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 Visa and 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
91108000500000005
Card "enrolled". This card is subjected to the full 3D Secure authentication process! Liability shift: YES, Authenticated: true
91108001501800005
"Authentication failed". The card holder failed to authenticate him/herself!
Important: In this case, the authorization will fail!

Bonus Card

It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test cards:
Card Number
Test-case
9090100052000007
"Success Card". This card simulates a successful transaction!
9090101052900006
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!
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

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
9050100052000005
Card "enrolled". This card is subjected to the full 3D Secure authentication process! Liability shift: YES, Authenticated: true
9050100052101001
Card "enrolled". Bank rejects liability shift despite a successful authentication! Liability shift: NO, Authenticated: true
Important: Saferpay will still attempt the authorization! Accepting or declining this transaction is up to the merchant!
9050100352000002
"Authentication Attempt". Simulates an authentication attempt, where the bank grants the liability shift Liability shift: YES, Authenticated: false
9050101052101009
Card "not enrolled". Bank rejects liability shift! Liability shift: NO, Authenticated: false
Important: Saferpay will still attempt the authorization! Accepting or declining this transaction is up to the merchant!
9050101152000002
"Unable to enroll". 3D Secure is not possible! Liability shift: NO, Authenticated: false
Important: Saferpay will still attempt the authorization! Accepting or declining this transaction is up to the merchant!
9050100152000004
"Authentication failed". The card holder failed to authenticate him/herself!
Important: In this case, the authorization will fail!
9050101052900004
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: Card "enrolled". This card is subjected to the full 3D Secure authentication process!
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

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

At this point, giropay cannot be tested.

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
For the Server-to-Server, please contact the Integration Support, as the testing is more involved.

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
9060100052000003
"Success Card". This card simulates a successful transaction!
9060101052900002
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!
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

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
9040100052000008
Card "enrolled". This card is subjected to the full 3D Secure authentication process! Liability shift: YES, Authenticated: true
9040100052101004
Card "enrolled". Bank rejects liability shift despite a successful authentication! Liability shift: NO, Authenticated: true
Important: Saferpay will still attempt the authorization! Accepting or declining this transaction is up to the merchant!
9040100352000005
"Authentication Attempt". Simulates an authentication attempt, where the bank grants the liability shift Liability shift: YES, Authenticated: false
9040100152000007
"Authentication failed". The card holder failed to authenticate him/herself!
Important: In this case, the authorization will fail!
9040101052900007
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
9040103204160001
Card, to simulate a Soft Decline. This card will ALWAYS return a Soft-Decline, even if SCA was performed!

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
9030004204000003
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.

Masterpass

Saferpay does offer an extensive Masterpass 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 Masterpass.

MyOne

It may be important to test certain flows and responses, during integration. For that, Saferpay offers the following test cards:
Card Number
Test-case
9080100052000009
"Success Card". This card simulates a successful transaction!
9080101052900008
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!
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

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 Card & eFinance

Saferpay does offer an extensive Postfinance simulator, for Postfinance E-Finance and Postfinance Card. All test-cases are controlled through the simulator-ui. The Secure Card Data feature is also supported!
Please contact the Integration Support, if you want to test Postfinance Card & eFinance.

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:
Please contact the Integration Support, if you want to test TWINT.
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 an authorization declined result
6661
Returns an authorization expired result

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: 9100100052000005.

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!

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 PENDING status and a subsequent call to the PendingNotification.NotifyUrl, in order to test the PENDING behaviour with Refunds. This simulates a delay of 300 seconds. You can change the value at the end to your liking.
Notify_DelayedResponse300

Go live

You have completed your testing and are now ready to go live, but do not know how?
Well, if you haven't already, you need to contact our Sales in order to sign a live contract. Please mention the payment methods and currencies you may want to be activated. Some 3rd party payment methods may also require you to configure certain things, like a UserId, or a password. Those are also necessary for our activation-team to know, so you can process the given method, through Saferpay.
We will then activate everything necessary for you and send you the respective logins and Ids (Customer-and TerminalId), you need to go live. However, there are things you need to change on your end, with the Go-Live, before you can start accepting payments:
  • As mentioned, you will get new Logins and IDs (Like the CustomerId and TerminalId) with your live account. Those have to be changed inside your application.
  • The JSON-API user and password need to be set. Once you have recieved your live Backoffice user, you need to log into the Saferpay Backoffice. There you need to create your own credentials under Settings > JSON API basic authentication or JSON API client certificate. Those credentials have to be entered inside your application, so your system may authenticate itself towards our gateway. It is exactly the same, as with the credentials, you have recieved with the e-mail for your test account. However, due to security constraints, we will not generate these for you for the live environment. That is why you have to do it yourself.
  • If you are in need of some 3rd party payment methods (e.g. PayPal, Klarna etc.), please make sure, that you also read the respective chapter to that payment method (See the respective Payment Method chapter.), as those contain vital information, not just for integration, but also activation!
  • Lastly, you need to change the request-gateway URL from https://test.saferpay.com/api/[...] to https://www.saferpay.com/api/[...] in order to send your requests to the Saferpay live-system, instead of the test-system. Some pre-made modules (Like our own) however offer a live-mode, or a possibility to set the gateway-URL! Please look inside the admin backend of your shop. As mentioned above, all functions, URLs etc. can also be found on the test environment, by just changing this small detail.
After that, we recommend trying out the payment methods, for example by using your own credit card for a test-order. You can always refund yourself inside the Saferpay Backoffice (If available for the given payment method! More in the respective payment methods chapter), or inside your shop directly, should you have access to refunds via API. This ensures, that everything works as smoothly, as possible. If you encounter any problems during this test, do not hesitate to contact us, so we may help you fix it as soon, as possible!
Last modified 19d ago