1 General procedures and security settings
   1.1 API user
   1.2 Request form
   1.3 Security
      1.3.1 Encryption
      1.3.2 IP address
      1.3.3 SHA signature
   1.4 Response parsing
2 Request a new order
   2.1 Request URL
   2.2 Test page
   2.3 Excluding specific payment methods
   2.4 Split credit/debit cards
3 Order response
   3.1 Duplicate request
4 Direct Maintenance
   4.1 Maintenance request
      4.1.1 Request URL
      4.1.2 Request parameters
      4.1.3 Test page
   4.2 Maintenance response
   4.3 Duplicate request
5 Direct Query
   5.1 Query request
      5.1.1 Request URL
      5.1.2 Request parameters
      5.1.3 Test page
   5.2 Query response
      5.2.1 Transactions processed with e-Commerce (hosted payment page)
   5.3 Possible response statuses
   5.4 Direct Query as fallback
6 Data Controller privacy policy request
   6.1 Query request
      6.1.1 Request URL
      6.1.2 Request-parameters
      6.1.3 Test-page
   6.2 Query response
7 3-D Secure v1.0
   7.1 Introduction
   7.2 3-D transaction flow via DirectLink
      7.2.1 Extra request parameters
      7.2.2 Additional return fields
      7.2.3 Comments

1 General procedures and security settings

The following general procedures and security controls are valid for all DirectLink requests: new order requests, maintenance requests and direct queries.

1.1 API user

An API (Application Program Interface) user is needed to make DirectLink requests.

In general it's a user specifically designed to be used by an application to make automatic requests to the payment platform.

You can create an API user in your Paypage account via "Configuration" > "Users". Select "New user" and fill the required fields.

To make the new user an API user, make sure to enable the "Special user for API (no access to admin.)" box.

Creation of an API user

Even though various user profiles are available for an API user, we strongly recommend you to configure this user with the "Admin" profile.
If you want to limit the rights for maintenance of transactions (refunds, cancellations etc.), you can still change the user profile to e.g. "Encoder".

If you are not sure, we recommend you to choose the "Admin" profile, otherwise go to User profiles (User Manager) for more information.

The password for an API user does not have to be changed regularly. This is more convenient when the password has to be hard-coded into your application. However, we recommend you to change the password from time to time.

For more information about User types and how to change the API user's password, go to User types (User Manager).

1.2 Request form

For new order requests, maintenance requests and direct queries, you must send requests with certain parameters to specific URLs. The new order/maintenance/query parameters must be sent in a POST request as follows:

PSPID=value1&USERID=value2&PSWD=value3&…

The type/subtype indicating the Media Type in the Content-Type entity-header field in the POST request needs to be "application/x-www-form-urlencoded".

DirectLink works in “one request-one reply” mode; each payment is processed individually. Our system handles individual transaction requests via DirectLink and can work synchronously (where this option is technically supported), i.e. we wait for the bank’s reply before returning an XML response to the request.

1.3 Security

When we receive a request on our servers, we check the level of encryption and the IP address which the request was sent from.

1.3.1 Encryption

DirectLink is built on a robust, secure communication protocol. The API is a set of instructions submitted with standard HTTPS POST requests. We only allow the merchant to connect to us in secure HTTPS mode.
There is no need for a client TLS certificate.

1.3.2 IP address

For each request, our system checks the IP address from which the request originates to ensure the requests are being sent from your (the merchant’s) server. In the IP address field in the "Checks for DirectLink" section of the "Data and origin verification" tab in your account's Technical Information page, you must enter the IP address(es) or IP address range(s) of the servers that send your requests.

If the originating IP address has not been declared in the given IP address field, you will receive the error message “unknown order/1/i/”. The IP address the request was sent from will also be displayed in the error message.

1.3.3 SHA signature

The SHA signature is based on the principle of your (the merchant’s) server generating a unique character string for each order, hashed with the SHA-1, SHA-256 or SHA-512 algorithms. The result of this hash is then sent to us in your order request. Our system reconstructs this signature to check the integrity of the order data sent to us in the request.

Go to SHA-IN Signature (Paypage e-Commerce documentation) - the principle is the same in e-Commerce and DirectLink mode.

For DirectLink, the SHA-IN passphrase needs to be configured in the "Checks for DirectLink" section of the "Data and origin verification" tab in your Technical information page.

1.4 Response parsing

We will return an XML response to your request. Please ensure that your systems parse this XML response as tolerantly as possible to avoid issues in the future, e.g. avoid case-sensitive attribute names, do not prescribe a specific order for the attributes returned in responses, ensure that new attributes in the response will not cause issues, etc.

2 Request a new order

2.1 Request URL

  • The request URL in the TEST environment is https://secure.paypage.be/ncol/test/orderdirect.asp.
  • The request URL in the PRODUCTION environment is https://secure.paypage.be/ncol/prod/orderdirect.asp.

Change "test" to "prod"

Replace “test” with “prod” in the request URL when you switch to your production account. If you forget to change the request URL, once you start in production with real orders, your transactions will be sent to the test environment and will not be processed by the acquirers/banks.

2.2 Test page

Our test page to send order requests in DirectLink can be found here: https://secure.paypage.be/ncol/test/testodl.asp.

2.3 Excluding specific payment methods

If there are payment methods you don't want a customer to be able to pay with, you can use a parameter to do so.
This is particularly useful for sub-brands, when you want to accept a brand (e.g. MasterCard) but not one of its sub-brands (e.g. Maestro).

The parameter is the following:

Field Usage
EXCLPMLIST
List of payment methods and/or credit card brands that should NOT be used.
Values must be separated by a “;” (semicolon).

If a customer tries paying with a card linked to a payment method and/or (sub)brand thT you've excluded BY using the EXCLPMLIST parameter, the error message “Card number incorrect or incompatible” will be returned with the NCERRORPLUS return field.

2.4 Split credit/debit cards

The functionality to split VISA and MasterCard into a debit and a credit payment method allows you to offer them to your customers as two different payment methods (e.g. VISA Debit and VISA Credit), or you can decide only to accept one of both split brands.

To use the split of credit and debit cards via DirectLink, you need to include the CREDITDEBIT parameter in the fields that you send to the orderdirect.asp page (and therefore also include in the SHA-IN calculation!).

Field Format
CREDITDEBIT "C": credit card
"D": debit card

Related error: When the buyer selects the debit card method but next enters a credit card number, an error code will be returned: ‘Wrong brand/Payment method was chosen’.

If the payment is successfully processed with the CREDITDEBIT parameter, the same parameter will also be returned in the XML response, and/or can be requested with a Direct Query. However, whereas the submitted values are C or D, the return values are "CREDIT" or "DEBIT".

You will also find these return values in transaction overview via "View transactions" and "Financial history", and in reports you may download afterwards.

Configuration in your account

The "split" functionality can also be activated and configured per payment method, in your Paypage account. Go to Split Credit/Debit Cards for more information.

3 Order response

Our server returns an XML response to a request:

Example of an XML response to an order request

<?xml version=”1.0”?>
<ncresponse orderID=”99999” PAYID=”1111111” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS=”5” ECI=”7” amount="125" currency="EUR" PM="CreditCard" BRAND="VISA"/>

The following table contains a list of the ncresponse tag attributes:

Field Description
ACCEPTANCE Acceptance code returned by acquirer.
amount Order amount (not multiplied by 100).
BRAND Card brand or similar information for other payment methods.
currency Order currency.
ECI Electronic Commerce Indicator.
NCERROR Error code.
NCERRORPLUS Explanation of the error code.
NCSTATUS First digit of NCERROR.
orderID Your order reference.
PAYID Payment reference in our system.
PM Payment method.
STATUS Transaction status. (Possible statuses)

The attribute list may be longer for merchants who have activated certain options (e.g. the Fraud Detection) in their accounts. Please refer to the respective option documentation for further information about additional response attributes linked to the option.

3.1 Duplicate request

If you request processing for an already existing (and correctly processed) orderID, our XML response will contain the PAYID corresponding to the existing orderID, the ACCEPTANCE given by the acquirer in the previous processing, STATUS “0” and NCERROR “50001113”.

4 Direct Maintenance

A direct maintenance request from your application allows you to:

  • Perform a data capture (payment) of an authorised order automatically (as opposed to manually in the back office);
  • Cancel an authorisation of an order;
  • Renew an authorisation of an order;
  • Refund a paid order.

Data captures, authorisation cancellations and authorisation renewals are specifically for merchants who have configured their account/requests to perform the authorisation and the data capture in two steps.

4.1 Maintenance request

4.1.1 Request URL

  • The request URL in the TEST environment is https://secure.paypage.be/ncol/test/maintenancedirect.asp.
  • The request URL in the PRODUCTION environment is https://secure.paypage.be/ncol/prod/maintenancedirect.asp.

Change "test" to "prod"

Replace “test” with “prod” in the request URL when you switch to your production account. If you forget to change the request URL, once you start working with real orders, your maintenance transactions will be sent to the test environment and will not be sent to the acquirers/banks.

4.1.2 Request parameters

The following table contains the mandatory request parameters for performing a maintenance operation:

FieldDescription
AMOUNT Order amount multiplied by 100.

This is only required when the amount of the maintenance differs from the amount of the original authorisation. However, we recommend its use in all cases.

Our system will check that the maintenance transaction amount is not higher than the authorisation/payment amount.
OPERATION

Possible values:

  • REN: renewal of authorisation, if the original authorisation is no longer valid.
  • DEL: delete authorisation, leaving the transaction open for further potential maintenance operations.
  • DES: delete authorisation, closing the transaction after this operation.
  • SAL: partial data capture (payment), leaving the transaction open for another potential data capture.
  • SAS: (last) partial or full data capture (payment), closing the transaction (for further data captures) after this data capture.
  • RFD: partial refund (on a paid order), leaving the transaction open for another potential refund.
  • RFS: (last) partial or full refund (on a paid order), closing the transaction after this refund.

Please note that with DEL and DES that not all acquirers support the deletion of an authorisation. If your acquirer does not support DEL/DES, we will nevertheless simulate the deletion of the authorisation in the back office.

ORDERID You can send the PAYID or the orderID to identify the original order. We recommend the use of the PAYID.
PAYID
PSPID Your account's PSPID
PSWD Password of your API-user
SHASIGN Signature (hashed string) to authenticate the data (see SHA-IN-signature)
USERID Your API-user

4.1.3 Test page

You can test direct maintenance requests here: https://secure.paypage.be/ncol/test/testdm.asp

4.2 Maintenance response

Our server returns an XML response to the maintenance request:

Example of an XML response to a direct maintenance request
<?xml version=”1.0”?>
<ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="91" amount="125" currency="EUR"/>

The following table contains a list of the ncresponse tag attributes:

Field Description
ACCEPTANCE Acceptance code returned by acquirer
AMOUNT Order amount (not multiplied by 100)
CURRENCY Order currency
NCERROR Error code
NCERRORPLUS Explanation of the error code
NCSTATUS First digit of NCERROR
ORDERID Your order reference
PAYID Payment reference in our system
PAYIDSUB The history level ID of the maintenance operation on the PAYID
STATUS Transaction status (Possible statuses)

The standard ncresponse tag attributes are the same as those for the XML reply to a new order, except for the extra attribute PAYIDSUB.

4.3 Duplicate request

If maintenance is requested twice for the same order, the second request will theoretically be declined with an error “50001127” (This order is not authorised), because the initial successful transaction will have changed the order status.

5 Direct Query

A direct query request from your application allows you to query the status of an order automatically (as opposed to manually in the back office). You can only query one payment at a time, and you will only receive a limited amount of information about the order.

If you need more details about the order, you can look up the transaction in the back office or perform a manual or automatic file download (see Consult your transactions and Batch).

5.1 Query request

5.1.1 Request URL

  • The request URL in the TEST environment is https://secure.paypage.be/ncol/test/querydirect.asp
  • The request URL in the PRODUCTION environment is https://secure.paypage.be/ncol/prod/querydirect.asp

Change "test" to "prod"

Replace “test” with “prod” in the request URL when you switch to your production account.

5.1.2 Request parameters

The following table contains the mandatory request parameters to perform a direct query:

Field
Description
ORDERID

You can send the PAYID or the ORDERID to identify the original order. We recommend the use of the PAYID.

PAYID
PAYIDSUB
You can indicate the history level ID if you use the PAYID to identify the original order (optional).
PSPID
Your account's PSPID
PSWD
Password of your API-user
USERID
Your API-user

5.1.3 Test page

You can test direct query requests here: https://secure.paypage.be/ncol/test/testdq.asp.

5.2 Query response

Our server returns an XML response to the request:

Example of an XML response to a direct query

<?xml version=”1.0”?>
<ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" ECI=”7” amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55"/>

The following table contains a list of the ncresponse tag attributes:

Field
Usage
ACCEPTANCE Acceptance code returned by acquirer
amount Order amount (not multiplied by 100)
BRAND Card brand or similar information for other payment methods
CARDNO The masked credit card number
currency Order currency
ECI Electronic Commerce Indicator
IP Customer’s IP address, as detected by our system in a 3-tier integration, or sent to us by the merchant in a 2-tier integration
NCERROR Error code
NCERRORPLUS Explanation of the error code
NCSTATUS First digit of NCERROR
orderID Your order reference
PAYID Payment reference in our system
PAYIDSUB The history level ID of the maintenance operation on the PAYID
PM Payment method
STATUS Transaction status

The standard ncresponse tag attributes are identical to those for the XML reply to a new order, except for the additional attributes PAYIDSUB, CARDNO and IP.

The attribute list may be longer for merchants who have activated certain options (e.g. the Fraud Detection) in their accounts. Please refer to the respective option documentation for more information on extra response attributes linked to the option.

5.2.1 Transactions processed with e-Commerce (hosted payment page)

If the transaction whose status you want to check was processed with e-Commerce (hosted payment page), you may also receive the following additional attributes (providing you sent these fields with the original e-Commerce transaction).

Field
Description
complus*
A value you wanted to have returned
(paramplus content)*
The parameters and their values you wanted to have returned

*Please check the Variable feedback parameters (e-Commerce documentation).

Example of an XML response to a direct query for an e-Commerce transaction

<ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55" COMPLUS="123456789123456789123456789" SessionID="126548354" ShopperID="73541312"/>

5.3 Possible response statuses

The STATUS field will contain the status of the transaction (see Possible statuses).

Only the following status is specifically related to the query itself:

StatusNCERRORNCSTATUS Description
88 The query on querydirect.asp failed

5.4 Direct Query as fallback

The response times for a DirectLink transaction request are generally a few seconds; however, some acquirers may have longer response times.

If you haven't received a response from our system after 30 seconds, you can send a request to querydirect.asp, asking for the status of your most recent transaction sent to orderdirect.asp. If you receive an immediate reply containing a non-final status for the transaction, there might be issues on the acquirer's end.

If you haven't received an answer to this direct query request after 10 seconds, there might be issues on our end. You can repeat this request to querydirect.asp every 30 seconds until you see you receive a response within 10 seconds.

Note
  • This check system will only be able to pinpoint issues at our end if there is also a check at your end to verify that requests are leaving your servers correctly.
  • An issue at our end will not always necessarily be caused by downtime, but could also be as a result of slow response times due to database issues for example.
  • Please use these checks judiciously to avoid bombarding our servers with requests, otherwise we might have to restrict your access to the querydirect.asp page.

Important

To protect our system from unnecessary overloads, we prohibit system-up checks which involve sending fake transactions or systematic queries, as well as systematic queries to obtain transaction feedback for each transaction.

6 Data Controller privacy policy request

Based on GDPR article 12, 13 & 14, a Data Controller has the obligation to inform its end-customers about the future processing of their personal data. Such information should be made specific based on the type of personal data to be filled-in for a specific transaction (e.g.: selected payment method, controller/processor, acquirer, fraud). The result should be available and visible at the moment of the data collection and the cardholder should be offered with a printable and downloadable version of it.

Per the GDPR policy, you need to display the information to your customer before they validate their transaction. This information should ideally be displayed on the same page as where your customer fills in their card/account credentials.

The below privacy policy request allows you to retrieve all the information you need to display to your customer about our services in order to be compliant with the GDPR regulation.

6.1 Query request

6.1.1 Request URL

• The request URL in the TEST environment is https://secure.paypage.be/ncol/test/privacy-policy.asp

• The request URL in the PRODUCTION environment is https://secure.paypage.be/ncol/prod/privacy-policy.asp
Change "test" to "prod"
Replace “test” with “prod” in the request URL when you switch to your production account.

6.1.2 Request-parameters

The following table contains the mandatory request parameters to be sent to your customer regarding the usage of their privacy information:

Field Format
Description
USERID String Your API-user
PSWD String Your API-user password
PSPID
String Your account’s PSPID
BRAND String (e.g. Visa) Optional: Payment method brand
You can send this field multiple times to get the result of several brands at once.
• Sending no brand is the same as sending all your active brands.
• Empty/wrong formatted brands are ignored.
LANGUAGE ISO 639-1: Two-letter codes (e.g. FR) Optional: The language in which you want to retrieve the text.
If not provided, the text will be returned into the merchant configured language.

6.1.3 Test-page

You can test direct query requests here: https://secure.paypage.be/ncol/test/privacy-policy.asp

6.2 Query response

The following is a list of XML elements and the returned XML responses examples for different outcomes.

Name Format Description
Response
Complex Root node, always present
Response.Status
String, possible values : Success, SuccessWithWarnings, Error
Always present
Response.Body
Complex
Present only when Response.Status = Success or SuccessWithWarnings
Response.Body.Html
String / html
Empty if Response.Status = SuccessWithWarnings & Response.Warnings.Warning.Code = NoContent
Response.Errors
Complex
Present only when Response.Status = Error
Response.Errors.Error
Complex
Can occur multiple times inside an <Errors> node
Response.Warnings
Complex
Present only when Response.Status = SuccessWithWarnings or Error
Response.Warnings.Warning Complex
Occurs multiple times inside a <Warnings> node
Response.Errors.Error.Code
Response.Warnings.Warning.Code
String, possible values :
•Inside an <Error> node : Unauthorized, InternalServerError
•Inside a <Warning> node : NoContent

Always present in an <Error> or <Warning> node
Response.Errors.Error.Message
Response.Warnings.Warning.Message
String
Optional

If you face Response.Status=Error, please refer to the Response.Errors.Error to fix it.
The following are two successful examples:

1. Example of an XML response for success with warnings. This example displays if no privacy information needs to be disclosed to the customer.

<?xml version="1.0" encoding="utf-8"?>
<Response>
<Status>SuccessWithWarnings</Status>
<Warnings>
<Warning>
<Code>NoContent</Code>
</Warning>
</Warnings>
<Body>
<Html/>
</Body>
</Response>

2. Example of an XML response for success with content. The example shows a 2 section display.

<?xml version="1.0" encoding="utf-8"?>
<Response>
<Status>Success</Status>
<Body>
<Html><![CDATA[<ul><li><h2>Title 1</h2><p>Content 1</p></li><li><h2>Title 2 (VISA, American Express)</h2><p>Content 2</p></li></ul>]]></Html>
</Body>
</Response>

7 3-D Secure v1.0

7.1 Introduction

The 3-D Secure protocol enables the cardholder to be identified during the purchasing process. The cardholder needs to be connected to the Internet during the identification process. Thus 3-D Secure does not work for call centre or recurring payments.

Visa has implemented the 3-D Secure protocol under the name Verified By Visa, MasterCard under the name SecureCode, JCB under the name J-Secure and American Express under the name SafeKey.

The principle of the integration of DirectLink with 3-D Secure is to initiate a payment in DirectLink mode and end it in e-Commerce mode if a cardholder authentication is requested.

This document describes the integration of the 3-D Secure protocol in DirectLink. For further information on DirectLink or e-Commerce, go to DirectLink or e-Commerce documentation.

The transaction flow involves the following steps:

  1. You send us a DirectLink request for the transaction, containing a number of additional parameters (cf. Extra request parameters).
  2. Our system receives the card number in your request and checks online whether the card is registered in the VISA/MasterCard/JCB/AmEx directory (registered means that identification is possible for the card number, i.e. the card is a 3-D Secure card).
  3. If the cardholder is registered, the answer to the DirectLink request contains a specific payment status and html code that has to be returned to the customer to start the identification process (cf. Additional return fields). The block of html code will automatically start the identification process between the cardholder (customer) and his issuing bank.
  4. The cardholder identifies himself on the issuing bank’s page.
  5. Our system receives the identification response from the issuer.
  6. If the identification was successful, our system will submit the actual financial transaction to the acquirer.
  7. You receive the result of the global identification and online authorisation process via e-Commerce mode feedback channels.

Comments:

  • Whether the liability shift applies or not depends on your acquirer contract. Therefore, we recommend you to check the terms and conditions with your acquirer.
  • If the cardholder is not registered (in step 3), you will receive the standard DirectLink XML response containing the result of the online authorisation process.
  • To receive the exact payment status/error codes (in step 7), you need to implement the online or offline post-sale feedback as described in the e-Commerce documentation.

7.2.1 Extra request parameters

Apart from the standard DirectLink parameters, you also need to send the following information:

Field Description
FLAG3D

Fixed value: ‘Y’

Instructs our system to perform 3-D Secure identification if necessary.

HTTP_ACCEPT The Accept request header field in the cardholder browser, used to specify certain media types which are acceptable for the response. This value is used by the issuer to check if the cardholder browser is compatible with the issuer identification system. For example:
Accept: */*
HTTP_USER_AGENT The User-Agent request-header field in the cardholder browser, containing information about the user agent originating the request. This value is used by the issuer to check if the cardholder browser is compatible with the issuer identification system. For example: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
WIN3DS Way to show the identification page to the customer. Possible values:
  • MAINW: display the identification page in the main window (default value).
  • POPUP: display the identification page in a pop-up window and return to the main window at the end.
  • POPIX: display the identification page in a pop-up window and remain in the pop-up window.
ACCEPTURL URL of the webpage to show the customer when the payment is authorised. (or waiting to be authorised).
DECLINEURL URL to which the customer is redirected if the maximum number of failed authorisation attempts has been reached (10 by default, but which can be changed in the Technical Information page, "Global transaction parameters" tab, "Payment retry" section).
EXCEPTIONURL URL of the webpage to show the customer when the payment result is uncertain.
PARAMPLUS Field to submit the miscellaneous parameters and their values that you wish to be returned in the post-sale request or final redirection.
COMPLUS Field to submit a value you wish to be returned in the post-sale request or output.
LANGUAGE Customer’s language, for example: “en_US”
Optional
TP To change the layout of the "order_A3DS" page, you can send a template name/url with this parameter. (go to e-Commerce: Dynamic template).

For more information, go to Transaction Feedback.

7.2.2 Additional return fields

If the cardholder is not registered, the normal DirectLink response is returned. If the cardholder is registered, the following (additional) fields will be returned:

Field Description
STATUS
New value: “46” (waiting for identification)
HTML_ANSWER

BASE64 encoded html code to be added in the html page returned to the customer.

This tag is added as a child of the <ncresponse> global XML tag. The field HTML_Answer field contains HTML code that has to be added in the html page returned to the customer's browser.

This code will automatically load the issuer bank identification page in a pop-up in the main window, depending on the WIN3DS parameter value.

To avoid any interference between the html tags included in the content of the HTML_ANSWER XML tag, with the rest of the XML returned as a response to the DirectLink request, the HTML_ANSWER content is BASE64 encoded by our system before returning the response. Consequently, this must be BASE64 DEcoded before it is included in the html page sent to the cardholder.

7.2.3 Comments

Test Cards

You can use the following test cards to simulate a 3-D Secure registered card in our test environment:

Brand Card number Expiry date Password
VISA 4000000000000002 Any date in the future 11111
MasterCard 5300000000000006 Any date in the future 11111
American Express 371449635311004 Any date in the future 11111
Incorrect identification

If a transaction is blocked due to incorrect identification, the transaction result will be:

STATUS = 0

NCSTATUS = 5

NCERROR = 40001134