Card testing

With the help of our test functionality, many situations can be tested prior to going live. Different ways of how to test payment transactions using DIBS Web Solution are described here. It is recommended to test page sets and credit card payments before going live

The DIBS gateway has a feature called “Test Mode”. When Test Mode is not activated, no tests may be performed on this merchant account.

Test Mode is activated in DIBS Manager under

General / Test Mode

After you have activated Test Mode, it will stay active for a short time period. Currently the default value is 3 days, but this is subject to change at any time with no prior warning.

Only if you have activated Test Mode, you will be able to use the Test Acquirer and the Test Purchase feature in DIBS Manager.

Before you can test with the test credentials, you should assure that you are using the method "cc.test" which triggers the test acquirer.

Once the method “cc.test” is used, the transaction will not be sent to a real acquirer, but will instead be handled by the test acquirer. When a test transaction is carried out, it can be seen in DIBS Manager, where the transaction can also be settled, reversed or refunded. Test transactions can also be settled, reversed or refunded using the Server Solution APIs.

In DIBS Manager, test transactions can be distinguished from actual transactions, since test transactions are shown on a grey background instead of a white background. Also, the displayed name of the acquirer for test transactions is “TestAcquirer”. Test transactions will not be included in accounting and payment reports.

The Test Acquirer is set up so that certain card numbers give certain replies. If a card number, contrary to those described below, is inadvertently sent, the authorization response will be reply “D” (Denied) and replyText “verification denied”. For more examples see the tables below.

Please note that test payments can never be sent to a real acquirer. When going live, make sure that you are not using the “cc.test” method.

Test Card Numbers

Below is a list of card numbers relating to various card types which return different error types (or are approved) so you can test your own system’s reactions to these responses. Test card numbers are composed of a prefix and a postfix. The prefix indicates the card type and the postfix indicates the desired result, i.e.:

Test card number = prefix + postfix

Example: You wish to test the authorization of a VISA card, and to have it approved

Prefix for VISA card: 4711
Code for approval: 100000000000
Test-VISA card with an approved authorization: 4711100000000000
Expiry Date: Mandatory parameters, but values will not be checked. For example use expM=06, expY=24.
SecurityCode/CVC: Optional parameter, value will not be checked. For example use securityCode=684.

The following contains prefixes of the test cards available. The prefex is combined with the following table, containing postfixes, to create a full card number. The combination gives a possibility to test certain scenarios, where the auth or capture is declined.

Card Prefix
Dankort 5019
EuroCard / Mastercard 5100
VISA 4711
VISA / Dankort 4571
Postfix Process Reply ReplyText
100000000000 All A (Accepted) verification OK
000000000001 Authorization D (Denied) timeout (2)
000000000002 Authorization D (Denied) server error (contact Verifyeasy)
000000000003 Authorization D (Denied) server error (contact Verifyeasy)
000000000004 Authorization D (Denied) verification denied
100000000001 Capture D (Denied) timeout (2)
100000000002 Capture D (Denied) server error (contact Verifyeasy)
100000000003 Capture D (Denied) server error (contact Verifyeasy)
100000000004 Capture D (Denied) verification denied


Do you have a question or need help?
Follow us
Nets Online Payments

Oslo: +47 21 55 44 00
Stockholm: +46 (0)8-527 525 00
København: +45 7020 3077
Jyväskylä: + 358 010 80 40 40
Close menu