Terminal
Description
After the successful Register call, you need to direct the customer’s web browser to the payment window in order for the customer to choose the payment method and enter payment method information. It doesn’t matter whether you are using Netaxept or merchant hosted payment window, in both cases you need to execute the Terminal call to send the customer to the desired payment window. If you are processing call centre transaction, you don't need to implement the Terminal phase at all.
Create a web form that POST's or GET's the customer to the payment window. Example of the Terminal call and the corresponding response can be found in the "Sample code" section.
API call
- Test: https://test.epayment.nets.eu/Terminal/default.aspx
- Test (for mobile): https://test.epayment.nets.eu/terminal/mobile/default.aspx
- Production: https://epayment.nets.eu/Terminal/default.aspx
- Production (for mobile): https://epayment.nets.eu/terminal/mobile/default.aspx
Please note that Server Name Indication (SNI) is required when connecting to Netaxept test environment URL https://test.epayment.nets.eu
Input parameters
Available input parameters in the Terminal are listed below. Please see proper validation rules at the “Validation” section.
Merchant ID | REST: merchantId | WebServices: N/A |
Required | Validation: Numeric | MaxLength: 8 |
Unique ID generated by Nets for identifying each merchant in Netaxept. You need to send this ID to Netaxept along all API calls. Test accounts may have a maximum length of 8 digits, while production accounts has a maximum length of 6 digits. |
Transaction ID | REST: transactionId | WebServices: N/A |
Required | Validation: Reference | MaxLength: 32 |
Unique ID identifying each transaction within the Merchant ID in Netaxept at any point. Transaction ID used in the Terminal call needs to match the Transaction ID used with the Register call. |
If you used Service type=M (Merchant hosted payment window) in the Register call, besides the above mentioned, you need to include the following parameters into the Terminal call.
PAN | REST: pan | WebServices: N/A |
Optional | Validation: Numeric | MaxLength: 20 |
Card number to be used for this transaction. |
Expiry date | REST: expiryDate | WebServices: N/A |
Optional | Validation: Numeric | MaxLength: 4 |
Expiry date for the card to be used for this transaction, on the format MMYY. |
Security code | REST: securityCode | WebServices: N/A |
Optional | Validation: Numeric | MaxLength: 4 |
Security code for the card to be used for this transaction. |
Output parameters
After the Terminal phase, the customer will be redirected to the URL address defined in the redirectURL parameter in the Register call. The following parameters will be added at the end of the URL address.
Transaction ID | REST: transactionId | WebServices: N/A |
Required | Validation: Reference | MaxLength: 32 |
Echoed from the Terminal call. |
Response code | REST: responseCode | WebServices: N/A |
Required | Validation: AlphaNumeric | MaxLength: N/A |
Response code will be set to the string "OK" if the Terminal phase was completed successfully. Please note that it doesn't contain information about the completeness of the actual payment. Any other response is an error. Read more about response codes |
Next step
Continue to financial operation
If the Response code is "OK", you can make the financial operation, like authorization (AUTH), authorization & capture (SALE) or account verification (VERIFY), to the transaction. All financial operations are encapsulated by the Process call and must for most payment methods be done within 24 hours of the customer being redirected back from the payment window. We recommend doing the further action as soon as possible. Read more about the Process calls
Investigate the reason for the failure
If the Response code is something else than "OK", use the Query call to find out the error description (ResponseText) and the source of the error (ResponseSource) for further investigation. Read more about the Query call and Response codes