Comptes de test Saferpay pour les développeurs

Tester toutes les interfaces Saferpay et effectuer des transactions de test

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.

Looking for the entry to the Saferpay test Backoffice?

Go to 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.

• JSON API specifications

• JSON API documentations

Saferpay Test Data

Various simulators are available on the Saferpay test account. The following payment methods can be tested:

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

Visa

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. The last two digits in the currency amount determine the issuance of the authorisation request. A successful payment is only triggered with a value equal to "00" or "01". While requests with the AMOUNT "00" simulate a request with an "enrolled" card, the amount "01" simulates a transaction without a liability shift. For all other values that are different to "00" or "01", a rejection is simulated with the authorisation.
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.

Mastercard

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". Simulates an authentication attempt in which the bank grants a liability shift. 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. The last two digits in the currency amount determine the issuance of the authorisation request. A successful payment is only triggered with a value equal to "00" or "01". While requests with the AMOUNT "00" simulate a request with an "enrolled" card, the amount "01" simulates a transaction without a liability shift. For all other values that are different to "00" or "01", a rejection is simulated with the authorisation.
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.

American Express

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. The last two digits in the currency amount determine the issuance of the authorisation request. A successful payment is only triggered with a value equal to "00" or "01". While requests with the AMOUNT "00" simulate a request with an "enrolled" card, the amount "01" simulates a transaction without a liability shift. For all other values that are different to "00" or "01", a rejection is simulated with the authorisation.

Maestro International

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. The last two digits in the currency amount determine the issuance of the authorisation request. A successful payment is only triggered with a value equal to "00" or "01". While requests with the AMOUNT "00" simulate a request with an "enrolled" card, the amount "01" simulates a transaction without a liability shift. For all other values that are different to "00" or "01", a rejection is simulated with the authorisation.

Diners Club

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. The last two digits in the currency amount determine the issuance of the authorisation request. A successful payment is only triggered with a value equal to "00" or "01". While requests with the AMOUNT "00" simulate a request with an "enrolled" card, the amount "01" simulates a transaction without a liability shift. For all other values that are different to "00" or "01", a rejection is simulated with the authorisation.

JCB

Card number	Type
9060100052000003	Card to simulate a successful transaction.
9060101052900002	Card for controlling authorisation codes via the amount. The last two digits in the currency amount determine the issuance of the authorisation request. A successful payment is only triggered with a value equal to "00" or "01". While requests with the AMOUNT "00" simulate a request with an "enrolled" card, the amount "01" simulates a transaction without a liability shift. For all other values that are different to "00" or "01", a rejection is simulated with the authorisation.

Card number

Type

9060100052000003

Card to simulate a successful transaction.

9060101052900002

Card for controlling authorisation codes via the amount.

The last two digits in the currency amount determine the issuance of the authorisation request. A successful payment is only triggered with a value equal to "00" or "01". While requests with the AMOUNT "00" simulate a request with an "enrolled" card, the amount "01" simulates a transaction without a liability shift. For all other values that are different to "00" or "01", a rejection is simulated with the authorisation.

MyOne

Card number	Type
9080100052000009	Card to simulate a successful transaction.
9080101052900008	Card for controlling authorisation codes via the amount. The last two digits in the currency amount determine the issuance of the authorisation request. A successful payment is only triggered with a value equal to "00" or "01". While requests with the AMOUNT "00" simulate a request with an "enrolled" card, the amount "01" simulates a transaction without a liability shift. For all other values that are different to "00" or "01", a rejection is simulated with the authorisation.

Card number

Type

9080100052000009

Card to simulate a successful transaction.

9080101052900008

Card for controlling authorisation codes via the amount.

Bonus Card

Card number	Type
9090100052000007	Card to simulate a successful transaction.
9090101052900006	Card for controlling authorisation codes via the amount. The last two digits in the currency amount determine the issuance of the authorisation request. A successful payment is only triggered with a value equal to "00" or "01". While requests with the AMOUNT "00" simulate a request with an "enrolled" card, the amount "01" simulates a transaction without a liability shift. For all other values that are different to "00" or "01", a rejection is simulated with the authorisation.

Card number

Type

9090100052000007

Card to simulate a successful transaction.

9090101052900006

Card for controlling authorisation codes via the amount.

Bancontact

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)

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)

SEPA ELV

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 TWINT

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

iDeal paydirekt UnionPay

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

Cartes-cadeaux rechargeables

Comptes de test Saferpay pour les développeurs

Contenu

Saferpay Test Account

Looking for the entry to the Saferpay test Backoffice?

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.

Using Saferpay JSON API with the test account

JSON API Online Help

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

PayPal Simulator

New certificate for test environment

Suivez-nous

Benefit from our myAnalytics offer