Testing Your Integration
We provide a demo environment so you may test your integration before going live.
Demo server host is
https://demo.naspay.net and the production server is
For DEMO server use:
- API Token URL
- API URL
For PRODUCTION server use:
- API Token URL:
- API URL:
See API Reference.
Test cards should be used for integration purposes only. Real cards will not be accepted in test mode vice versa test cards will not be accepted on production.
There are a number of predefined cards that are accepted in in test mode. First 6 digits is the card BIN (Bank Identification Number). The only accepted BINs are:
|520 000||Master Card|
|555 500||Master Card|
Card Authorization Behavior
Card authorization behavior on demo server is controlled by the digits in specific positions in the card number (PAN). Each position is responsible for behavior of particular operation.
0” in particular position means the success of related operation.
Other digits defines an error codes or operation statuses and usually means operation failure.
|2||Failure||Transaction declined by anti-fraud|
|4||Authorized||Transaction is risky. It will not be captured automatically due to high probability of fraud.|
|n-2||3D-Secure||0||Success||Customer was successfully authenticated|
|1||Authentication Failed||Customer failed or cancelled authentication. Transaction denied.|
|4||Not 3D-Secure Enrolled||Cardholder not participating. Transaction will proceed as non-3D.|
|n-1||Authorization||0||Success||Card authorization will be successful|
The last digit (n-0) is a control digit, calculated using Luhn algorithm (should be valid).
Let’s consider the card number (PAN)
|BIN||Not used, can be anything||Ant-Fraud||3D-Secure||Authorization||Check digit|
|4000 0000 0000 0002||3D-Secure Enrolled, Authorization Successful|
|4000 0000 0000 0010||3D-Secure Enrolled, Authorization will fail|
|4000 0000 0000 0101||3D-Secure Enrolled, 3D-Secure will fail|
|4000 0000 0000 2008||3D-Secure Enrolled, Anti-fraud will fail|
|4000 0000 0000 4004||3D-Secure Enrolled, Anti-fraud will cause transaction to be Authorized even if SALE was requested.|
|4000 0000 0000 0408||Non-3D-Secure, Authorization Successful|
|4000 0000 0000 0416||Non-3D-Secure, Authorization will fail|
Testing Post-Authorization Operations
Behavior of post-authorization (back-office) operations (Confirm, Reversal, etc.) is controlled by transaction amount (in the currency of the transaction).
|Operation||1 – 200||201 – 300||301 – 400||> 400|
Any operation (confirm, reversal or refund) with amount less or equal to 200 will be successful. Any operation with amount greater than 400 will be declined.