Hosted Page Secure Token Feature
This feature enables you to register a Secure Token using the Hosted Page method.
For more details on Secure Tokens, please visit the Products page.
Use the Request URL and the Request Body Fields to perform a request for this feature, then put in place your Secure Token URL so the Gateway can use the Response Body Fields to send the registration's response.
Secure Token Registration and Update
- REQUEST URL: https://testpayments.worldnettps.com/merchant/securecardpage
Request Body Fields
Filter:
| FIELD | REQUIRED | DESCRIPTION |
|---|---|---|
| ACTION | Y | Values can be: register or update. |
| TERMINALID | Y | A TerminalID provided by Worldnet. |
| MERCHANTREF | Y | Unique reference assigned by the Merchant site/ solution to identify the stored card details. The length is limited to 48 characters. |
| N | Cardholder e-mail, which is going to be used, if sent, to provide the cardholder with receipt notifications when the transactions is processed. See note ND0003 - E-mail field behavior and settings. | |
| DATETIME | Y | Date and time of the request. Format: DD-MM-YYYY:HH:MM:SS:SSS. |
| HASH | Y | A HASH code formed by part of the request fields. The formation rule is given at the ND001 - Hash Formation, in the next section. |
| STOREDCREDENTIALUSE | N | Values can be: UNSCHEDULED, INSTALLMENT or RECURRING. See note ND0004 - Stored Credential use field behaviour and settings |
Notes and Details About the Request
ND001 - Hash Formation
The gerenal rule to build HASH field is given at the Special Fields and Parameters page. For this specific feature, you should use the following formats:
TERMINALID:MERCHANTREF:DATETIME:ACTION:SECRET
ND002 - Valid Secure Token Update
To initiate card details updating, the value of the ACTION parameter should be changed to “update”. Also, in case you want to update a Secure Token of MERCHANTREF 1234321, a Secure Token should already exist with this same MERCHANTREF, or the updated won't preoceed.
ND0003 - E-mail field behavior and settings
This field is available for all terminal, but depending on configuration (Token Hosted Page email field setup), it might have one of the following behaviors when the customer gets to the hosted payment page:
Hidden - the gateway accepts the field, if sent, and adds it to the transaction, but does not show it for the customer);
Visible - the gateway accepts the field, if sent, and adds it to the transaction, also shows the field on the hosted payment page, and the user can changed it or not. In this last case, the field can be made optional or mandatory.
ND0004 - Stored Credential use field behaviour and settings
This feature is currently available to TSYS Saratoga terminals and is configurable by customer support. This field will have the following behaviour: Hidden - the gateway accepts the field, if sent, and adds it to the transaction, but does not show it for the customer.
Note: STOREDCREDENTIALTXTYPE set as FIRST_TXN by default
Examples for a Request
- Scenario: Minimum request, with only mandatory data.
- Terminal Secret: x4n35c32RT.
<html> <body> <form action="https://testpayments.worldnettps.com/merchant/paymentpage" method="post"> <input type="hidden" name="ACTION" value="register" /> <input type="hidden" name="TERMINALID" value="6491002" /> <input type="hidden" name="MERCHANTREF" value="1234321" /> <input type="hidden" name="DATETIME" value="15-3-2006:10:43:01:673" /> <input type="hidden" name="HASH" value="c3ce23e5e27d2863d116a6f9c8d63f5e" /> <input type="submit" value="Register" /> </form> </body> </html>
REMEMBER to change the Terminal Id and Terminal Secret for valid values. Verify the Integration Docs for viable examples or contact our support team.
Response Body Fields
Assuming valid details were sent, the Hosted Registration or Update page will be displayed, clicking on “Register” or “Update” will save the card details, result GET parameters will be forwarded to the Secure Token URL that is configured on the Terminal Setup page. The response body field will be:
Filter:
| FIELD | DESCRIPTION |
|---|---|
| RESPONSECODE | A: Approval. Error Code: Verify the ND002 for more details on possible values. |
| RESPONSETEXT | The text of the response. |
| MASKEDCARDNUMBER | The registered/ updated card number (obfuscated). |
| MERCHANTREF | Original SECURECARDMERCHANTREF provided by the Merchant on request. |
| CARDREFERENCE | Generated card reference. |
| CARDTYPE | Card Type used for the transaction. For more details on this, visit Special Fields and Parameters - Card Types. |
| CARDEXPIRY | Expiry date of the card. |
| DATETIME | The time of the registration. Format: DD-MM-YYYY:HH:MM:SS:SSS. |
| HASH | A HASH code formed by part of the response fields. The formation rule is given at the ND001 - Hash Formation, in the next section. |
| STOREDCREDENTIALUSE | Same as informed at the transaction's request. Returned if informed on request |
| STOREDCREDENTIALTXTYPE | set as FIRST_TXN by default |
| BRANDTXIDENTIFIER | If STOREDCREDENTIALUSE is sent in request and Secure Token is validated - then returned by acquirer |
Notes and Details on the Response
ND001 - Hash Formation
The gerenal rule to build HASH field is given at the Special Fields and Parameters page, under the Special Fields and Parameters section.
For this specific feature, you should consider the following formats:
TERMINALID:RESPONSECODE:RESPONSETEXT:MERCHANTREF:CARDREFERENCE:DATETIME:SECRET
ND002 - Response Codes - Errors
| Error Code | Description |
|---|---|
| E01 | SYSTEM ERROR – TRY AGAIN |
| E03 | OPERATION NOT ALLOWED |
| E04 | INVALID REFERENCE DETAILS |
| E05 | INVALID CARD TYPE |
| E06 | INVALID TERMINALID |
| E07 | METHOD NOT SUPPORTED |
| E08 | INVALID MERCHANTREF |
| E09 | INVALID DATETIME |
| E10 | INVALID CARDNUMBER |
| E11 | INVALID CARDEXPIRY |
| E12 | INVALID CARDHOLDERNAME |
| E13 | INVALID HASH |
| E14 | CVV VALIDATION FAILED |
General Constraints and Rules Related to the Feature
Filter:
| CONSTRAINT | DESCRIPTION |
|---|---|
| C001 | If invalid parameter values are sent, an Error Page will appear and the web browser will not be redirected to the Secure Token Receipt Page. This should not happen in a production environment after integration is completed. |