After each operation mentioned in the Flow Outline, the merchant receives a response message from Netaxept containing either response code "OK" or some error code. Response codes are returned to the merchant through API, can be fetched by using the Query call, and can be seen in a web-based Netaxept Admin.
Make your implementation so that it doesn't rely on the timestamps of different operations but interprets the content of the response message received. Also, we recommend you to make your payment implementation in such a manner that after a successful, failed or cancelled payment, the customer is redirected to a separate page informing of the outcome of the payment process. Therefore, the redirectURL parameter cannot contain the URL of the "select payment method" page or any other page that is in the middle of the order process. If the customer wants to return directly to the order process after successful, failed or cancelled payment, the webshop must generate a new order for them.
Response code "OK"
There are two places in the payment flow when Netaxept may respond with the response code OK. Be mindful that these two responses should not be confused.
Terminal phase is completed successfully
After the customer has entered their payment method information in the payment window and passed the possible 3D Secure authentication successfully, they are redirected to the redirectURL specified by the merchant in the Register call. At the end of this URL you will find a responseCode parameter which includes either "OK", "Cancel" or some error code. This specifies whether the terminal process has been completed successfully. It doesn't contain information about the completeness of the actual payment.
Example of a URL for a completed terminal phase: http://localhost/Test/?transactionId=6c5e402a4ee445ba9f19411f55c75b91&responseCode=OK
Example of a URL for a payment where the customer clicked “Cancel” button on the payment window: http://localhost/Test/?transactionId=6c5e402a4ee445ba9f19411f55c75b91&responseCode=Cancel
Payment is processed successfully
The response code OK is also returned to the merchant when the transaction has been processed (for example authorized, captured or credited) successfully without errors by using the Process call. In that case, OK parameter can be found in the ResponseCode parameter in the ProcessResponse.
Despite of the successfully authorized and captured transaction, it is recommended to make the Query call before sending goods to the customer to verify that the money has actually been captured. This is due to the response times Netaxept from time to time see from third-party payment methods, such as direct bank payments.
Example of a response for a successfully processed payment:
<ProcessResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <AuthorizationId>258460</AuthorizationId> <BatchNumber>642</BatchNumber> <ExecutionTime>2017-01-24T07:47:28.1900126+01:00</ExecutionTime> <MerchantId>[MERCHANTID]</MerchantId> <Operation>AUTH</Operation> <ResponseCode>OK</ResponseCode> <TransactionId>6c5e402a4ee445ba9f19411f55c75b91</TransactionId> </ProcessResponse>
If something goes wrong when communicating between your system and Netaxept or in the middle of the payment process, Netaxept declines the transaction and returns an exception. All exceptions are wrapped in the outer Exception tag, with an Error tag inside. The type (xsi:type) of the Error tag indicates which exception it is. Read more about exceptions
All exceptions include the message that provides a textual description of what failed. Besides the message, one commonly used exception "BBSException" includes also error code, error source and error message which are available in English.
Example of an error response for a payment that is already processed:
<Exception xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <Error xsi:type="BBSException"> <Message>Unable to sale</Message> <Result> <IssuerId>3</IssuerId> <ResponseCode>98</ResponseCode> <ResponseText>Transaction already processed</ResponseText> <ResponseSource>Netaxept</ResponseSource> <TransactionId>6c5e402a4ee445ba9f19411f55c75b91</TransactionId> <ExecutionTime>2017-01-24T09:56:24.8329041+01:00</ExecutionTime> <MerchantId>[MERCHANTID]</MerchantId> <MaskedPan/> <MessageId>8ba8ccadbffa4f2ba7c6f286bbcada68</MessageId> </Result> </Error> </Exception>
The error codes are divided into groups according to the source. The source is a textual description of which part of the system generated the error code. The source should not be used to drive code; instead, it should only be logged and used as a diagnostic tool if it is unclear why a transaction failed.
- "Netaxept" or "NTS" (or "01" in the old Netaxept; version 1), if the error occurred in the Netaxept solution.
- "Issuer" (or "02" in the old Netaxept; version 1), if the error came from the card Issuer or other payment method service provider.
- "Module" (or "03" in the old Netaxept; version 1)) or "Transport" (or "04" in the old Netaxept; version 1), if the error occurred internally at Nets.
- "Terminal" (or "05" in the old Netaxept; version 1), if the error occurred as a result of the customer input in the payment window.
Note! Occasionally, you can see other sources as well, for example the name of a Netaxept’s integration partner, like "Klarna"
Error codes from Netaxept (Source: Netaxept or 01)
|14||Invalid card number|
|25||Transaction not found|
|30||“KID invalid” or “Field missing PAN”|
|84||Original transaction rejected|
|86||Transaction already reversed|
|98||Transaction already processed|
|99||Several errors can result in this error code. Refer to the Response text for details|
|MZ||Denied by 3D Secure authentication|
|T1||Transaction reached merchant timeout value of xx:xx:xx|
|CF||The compliance check failed for the initial transaction. Subsequent transactions are not permitted.|
Error codes from Issuer (Source: Issuer or 02)
|01||Refused by Issuer. You can advise the consumer to contact their Issuer for more information.|
|02||Refused by Issuer. You can advise the consumer to contact their Issuer for more information.|
|03||Refused by Issuer because of the invalid merchant.|
|04||Refused by Issuer.|
|05||Refused by Issuer.|
|06||Refused by Issuer.|
|07||Refused by Issuer.|
|08||Refused by Issuer.|
|10||Refused by Issuer.|
Error codes / messages originating from Netaxept's payment window (Source: Terminal or 05)
Netaxept displays error messages to the customer in the payment window, to guide the customer in cases where error situations can be resolved by fixing errors for example in data fields. These error messages will be translated to the language specified by the merchant in the Register call. The error messages may also specify the data field where the error is happening, to direct the customer to resolve the error. The following are the most common error messages shown in the payment window for card payments.
- Too few digits
- Expired card
- Missing bank agreement
- Too many digits
- The cardnumber belongs to another card company
- Contains illegal characters
- Wrong cardnumber
- Format error
- Illegal value
- Is missing and required
- Not legal length
- Refused by Issuer (Several payment methods may return this error message. In these cases, the Issuer bank or payment method service provider has refused the payment, and the customer can be advised to contact their card Issuer or payment method service provider to resolve the issue).
- 17: Cancelled by customer
- 30: Missing customer input
Error messages without error codes
- Pan Hash not in file: panHash (token) used in subsequent payment has been deleted due to retention criteria described on the tokenization page.
Error codes originated from Netaxept ’s integration partners
Error messages from Netaxept’s integration partners are documented at their own developer site.