HTMLs Manual 3.0
Contents
- 1 Blocks
- 1.1 HTMLs
- 1.2 HTML Types
- 1.2.1 Registration form top banner
- 1.2.2 Mandatory subscription pop-up
- 1.2.3 Purchase confirmation e-mail
- 1.2.4 Local legal conditions
- 1.2.5 Popup messages
- 1.2.6 Confirmation Autoregistration Email
- 1.2.7 Confirmation user provision email
- 1.2.8 Confirmation user with own password email (2.2)
- 1.2.9 Remember password email
- 1.2.10 Confirmation changed email (2.2)
- 1.2.11 Reactivation user notification
- 1.2.12 Reactivation User Notification IPTV (2.3)
- 1.2.13 Purchase webpay email
- 1.2.14 Webpay success page
- 1.2.15 Webpay failure page
- 1.2.16 Webpay missing information
- 1.2.17 Subscription cancellation notification
- 1.2.18 Subscription signature renewal
- 1.2.19 Welcome IPTV (2.3)
- 1.2.20 Email Changed IPTV (2.3)
- 1.2.21 Remember Password IPTV (2.3)
- 1.2.22 Password Changed IPTV (2.3)
- 1.2.23 Reset Purchase Pin (3.2)
- 1.2.24 Reset Purchase Pin IPTV (3.2)
- 1.2.25 Purchase SIA Email (4.0)
- 1.2.26 Subscription renewal SIA Email - Success (4.0)
- 1.2.27 Subscription renewal SIA Email - Failure (4.0)
- 1.2.28 Subscription renewal SIA Email - Failure and cancelation (4.0)
- 2 Actions
This section allows to manage the HTMLs, so they can be added to instances so they can be used in the Instance websites and for the email notifications. The HTMLs can also be managed from the Instance Page HTLMs block.
Blocks
HTMLs
Field | Description | Restrictions |
---|---|---|
Name | HTLM name, informative / internal. | - |
Language | Language for the HTML. Should match the Instance's language. | - |
Subject | Used for htmls emails only. Subject that will be used for the emails. | - |
Source | Controls the access and visibility of this html for other operators. Only operators with rights over this source or its children will be able to see it. | - |
HTML | HTML code/structure of the form. | - |
HTML Type | Type of email (Dropdown menu). Check the different HTML types in the following section | - |
HTML Types
Registration form top banner
The registration form top banner appears on top of the self-registration form for non-Telefónica users, thus enhancing the form layout itself.
This is a sample HTML template file for the registration form top banner.
Mandatory subscription pop-up
The mandatory subscription pop-up appears as a pop-up window reminder informing about a mandatory subscription.
This is a sample HTML template file for the mandatory subscription pop-up.
Purchase confirmation e-mail
The purchase confirmation e-mail is sent whenever an end-user purchases a product via Billing, e-wallet, PayPal or WorldPay, thus making sure the user is fully aware of what’s been just purchased.
Possible fields are:
{productName}: Name of the purchased product.
{userName}: email of the user. Username to access the service.
{price}: Cost of the product.
{paymentMethod}: Payment method.
From GVP4.1 onwards, if instance parameter HIDE_ADULT_PURCHASES is true, {productName} will be masked as it is explained at Purchase emails: different behavior for Adult contents.
Local legal conditions
The local legal conditions is a pop up window, informing about the legal conditions applicable to the OB providing the service, which are specific of the country where an OB runs the service, and so it must be customizable.
This is a sample HTML template file for the local legal conditions.
Popup messages
The Popup messages is a pop up window, shown at the top of PC Client as “Link Popup”, any information could be written inside.
Confirmation Autoregistration Email
This HTML is used in two scenarios related to (NON-TEF) self-register users:
- When a user completes the auto registration process: in order to confirm the validity of the user email and, in case the OB requires it, to send the activation link. The user will not be active until he /she clicks on the activation link.
- When the operator needs to resend the activation link. In this case, the platform generates a new password which is included in the email.
Possible fields are:
{name}: first name and last name.
{email}: username to access the OTT service
{link}: Activation link
{password}: Password to access the service.
{pin_purchase}: In case it is enabled by default, the purchase pin.
Confirmation user provision email
This HTML is used in two scenarios related to TEF users provisioned from OB side:
- When the OB requests to activate a user/account with a password generated by GVP. In case the OB does not allow login before confirmation, the user will not be active until he /she clicks on the activation link.
- When the operator needs to resend the activation link (for instance because it is detected that a user that has never confirmed his/her account) when the user is not active. In this case, the platform generates a new password which is included in the email.
Possible fields are:
{name}: first name and last name stored in the database (in this case is equal to the email).
{email}: username to access the OTT service
{link}: Activation link
{password}: Password to access the service.
{pin_purchase}: In case it is enabled by default, the purchase pin.
Note that depending on allow login before e-mail confirmation flag (at instance level), user will not be active until he /she clicks on the activation link. In case flag is set to false, activation link is optional, but could be used by OBs to allow an easy way to log into the service.
Confirmation user with own password email (2.2)
This HTML is used when the OB requests to activate a user/account with a password chosen by the user.
Possible fields are:
{name}: first name and last name stored in the database (in this case is equal to the email).
{email}: username to access the OTT service
{link}: Activation link
{password}: Password to access the service.
{pin_purchase}: In case it is enabled by default, the purchase pin.
Depending on allow login before e-mail confirmation flag (at instance level), user will not be active until he /she clicks on the activation link. In case flag is set to false, activation link is optional, but could be used by OBs to allow an easy way to log into the service.
Remember password email
This HTML type is used to send a new password to the end user by email whe an active user (TEF & non-TEF) requests a new password. There are three ways to issue this request:
o The user requests to renew the password through the “Remember password” in UNI-API. Then the user receives 2 emails:
- Containing a link to confirm that the user wants to renew the password (this info is currently defined inside gvp.api dictionaries).
- Then, a “Remember password email” containing the new password generated by the platform.
o The OB sends a rememberPassword request through UNICA API.
o The operator clicks on “GVP email resender” at the bottom of the user page in MiB.
Parameters to be used are:
{name}: first name and last name stored in the database (in this case is equal to the email).
{password}: Password to access the service.
GVP2.3: This e-mail is also sent for IPTV users requesting a new password from PC Client.
Confirmation changed email (2.2)
This HTML is used to confirm the user’s new email when an OTT user requests to change it. In that case, depending if instance’s flag “Allow Login before Email Confirmation” is set to true, it is necessary that the user confirms the new e-mail by clicking on the validation link.
Meanwhile the status of the user changes to “awaiting e-mail confirmation” regardless the configuration of the OB (but it will be changed to Active after its first login in case the flag “Allow Login before Email Confirmation” is set to true). The change of the email causes that the GVP generates a new password for the user, so it is also necessary to send this new password to the user.
Possible fields are:
{name}: first name and last name stored in the database (in this case is equal to the email).
{email}: username to access the OTT service
{link}: Activation link
{password}: Password to access the service.
Reactivation user notification
When a TEF user is deactivated and then activated again, GVP platform sends a “Reactivation User Notification” email in order to notify the user that has been reactivated and asking him/her to confirm it. This email also includes the new password to access the service.
Possible fields are:
{name}: first name and last name stored in the database (in this case is equal to the email).
{email}: username to access the OTT service
{link}: Activation link
{password}: Password to access the service.
{pin_purchase}: In case it is enabled by default, the purchase pin.
Depending on allow login before e-mail confirmation flag (at instance level), user will not be active until he /she clicks on the activation link. In case flag is set to false, activation link is optional, but could be used by OBs to allow an easy way to log into the service.
Reactivation User Notification IPTV (2.3)
When a user is deactivated and the activated again, GVP platform sends this mail in order to notify the user that has been reactivated. This email also includes the new password to access the service.
Possible fields are:
{name}: first name and last name stored in the database.
{email}: username to access the OTT service
{password}: Password to access the service.
{pin_purchase}: In case it is enabled by default, the purchase pin.
Purchase webpay email
This html type is used to confirm by e-mail a purchase done with Webpay, so it is specific for Chile.
Possible fields are:
{productName}: Name of the purchased product.
{userName}: email of the user. Username to access the service.
{tbkOrdencompra}: Order number.
{price}: Cost of the product.
{tbkTipoPago}: Payment type (debit/credit).
{tbkCodigoAutorizacion}: Authorization code.
{tbkFinalNumeroTarjeta}: Final numbers of credit card.
{paymentMethod}: Payment method.
{tbkFechaTransaccion}: Transaction date.
{tbkHoraTransaccion}: Transaction time.
{tbkNumeroCuotas}: Number of payments.
From GVP4.1 onwards, if instance parameter HIDE_ADULT_PURCHASES is true, {productName} will be masked as it is explained at Purchase emails: different behavior for Adult contents.
Webpay success page
This HTML is a popup showing the same information as “purchase webpay email”, when the purchase is successful.
Possible fields are:
{productName}: Name of the purchased product.
{userName}: email of the user. Username to access the service.
{tbkOrdencompra}: Order number.
{price}: Cost of the product.
{tbkTipoPago}: Payment type (debit/credit).
{tbkCodigoAutorizacion}: Authorization code.
{tbkFinalNumeroTarjeta}: Final numbers of credit card.
{paymentMethod}: Payment method.
{tbkFechaTransaccion}: Transaction date.
{tbkHoraTransaccion}: Transaction time.
{tbkNumeroCuotas}: Number of payments.
Webpay failure page
This simple HTML notifies about the order number that failed when trying to purchase a movie or credits with webpay.
Possible fields are:
{tbkOrdencompra}: Order number.
Webpay missing information
This HTML has no variables, just shows some text when the webpay transaction flow has been stopped.
Subscription cancellation notification
This HTML is used to notify by e-mail about the cancellation of a subscription. Possible fields are:
{userName}: Name of the user
{email}: user email
{productName}: Product title
{productDetails}: Product description
{paymentMethod}: Payment method title
{price}: Price to be charged
{cancelationReason}: Reason for the cancellation
For all the cancellation Reasons, you can include them as entries in the UNIAPI dictionary, to be translated by each OB. Right now, two entries should be configured:
<cancellationReason> <noCredits>No more credits</noCredits> <userCancelled>user cancelled it</userCancelled> </cancellationReason>
The message is sent when:
- The user cancels a subscription from the device (independently of paymentType).
- Subscriptions paid with worldpay or e-wallet cannot be renewed due to insufficient balance (signature renewer agent verifies regularly - each 30 minutes - all the user rights which are about 1 hour to expire in UTC time).
It is not sent when:
- Operator cancels subscription from Betools.
- Operator cancels subscription from OB systems.
From GVP4.1 onwards, if instance parameter HIDE_ADULT_PURCHASES is true, {productName} and {productDetails} will be masked as it is explained at Purchase emails: different behavior for Adult contents.
Subscription signature renewal
HTML type used when renewing a subscription to notify the user by e-mail about the recurrent payment.
{userName}: Name of the user.
{productName}: Product title.
{productDetails}: Product description.
{paymentMethod}: Payment method title.
{price}: Price to be charged.
From GVP4.1 onwards, if instance parameter HIDE_ADULT_PURCHASES is true, {productName} and {productDetails} will be masked as it is explained at Purchase emails: different behavior for Adult contents.
Welcome IPTV (2.3)
When an IPTV user is upgraded to access the Go service (having a valid e-mail), or is directly created with e-mail (and optionally password). This email may include the new password to access the service.
Possible fields are:
{name}: first name and last name stored in the database (in this case is equal to the email).
{email}: username to access the OTT service
{password}: Password to access the service.
{pin_purchase}: In case it is enabled by default, the purchase pin.
Email Changed IPTV (2.3)
When the email is changed through OSS/BSS APIs this email type is sent. This Use Case covers also the e-mail change including user generated password, but shouldn't be considered for final deployments.
Possible fields are:
{name}: first name and last name stored in the database (take care it may be equal to the old email, so it is not suggested including it).
{email}: new email to access the OTT service and for notifications
{password}: Password to access the service.
Remember Password IPTV (2.3)
This HTML type is used to send a new password to IPTV users when:
o The OB sends a rememberPassword request through UNICA API.
o The operator clicks on “GVP email resender” at the bottom of the user page in MiB.
Parameters to be used are:
{name}: first name and last name stored in the database (in this case is equal to the email).
{password}: Password to access the service.
Password Changed IPTV (2.3)
Not in use.
Sent when a new password is provisioned using ModifyUser for an IPTV user.
Possible fields are:
{name}: first name and last name stored in the database (in this case is equal to the email).
{email}: username to access the OTT service
{password}: Password to access the service.
Reset Purchase Pin (3.2)
Sent when purchase PIN is reset and it is enabled by default.
Possible fields are:
{pin_purchase}: purchase pin set to the user.
Reset Purchase Pin IPTV (3.2)
Sent when purchase PIN is reset and it is enabled by default for an IPTV user.
Possible fields are:
{pin_purchase}: purchase pin set to the user.
Purchase SIA Email (4.0)
When a user purchases a product with SIA credit card, the purchase SIA confirmation e-mail is sent, this making sure the user is fully aware of what has been just purchased.
These email must include info about purchased product and payment. Needed fields are:
- {name}: First and last names of the user.
- {email}: email of the user. Username to access the service.
- {productName}: product title.
- {productDetails}
- {price}: Cost of the product.
- {SIAorderId}: Order number. (PURXXXX where XXXX = GVP_PURCHASES.ID)
- {GVPPurchasesDateins}: Renewal transaction date (system date)
- {SIACreditCardPAN}: Maskedredit card number
- {SIACreditCardExpirationDate}: Credit Expiration Date.
Note that:
- if instance parameter HIDE_ADULT_PURCHASES is true, {productName} and {productDetails} will be masked as it is explained at Purchase emails: different behavior for Adult contents.
- if an instance has not HTML "Purchase SIA Email", purchases with SIA payment method MUST continue working.
Subscription renewal SIA Email - Success (4.0)
When SIA notifies to GVP that a subscription has been renewed and charged to user's credit card, the renewal SIA confirmation e-mail is sent.
These email must include info about renewed product and payment. Needed fields are:
- {name}: First and last names of the user.
- {email}: email of the user. Username to access the service.
- {productName}: product title.
- {productDetails}
- {price}: Cost of the product.
- {SIAorderId}: Order number. (PURXXXX where XXXX = GVP_PURCHASES.ID)
- {GVPPurchasesHistoryDateins}: Renewal transaction date (system date)
- {SIACreditCardPAN}: MaskedCredit card number
- {SIACreditCardExpirationDate}: Credit Expiration Date.
Note that:
- if instance parameter HIDE_ADULT_PURCHASES is true, {productName} and {productDetails} will be masked as it is explained at Purchase emails: different behavior for Adult contents.
- if an instance has not HTML "Subscription renewal SIA Email - Success ", gvp.sia MUST continue working.
Subscription renewal SIA Email - Failure (4.0)
When SIA notifies to GVP that was not possible to renew a subscription, a warning e-mail is sent to the user, inviting him to review credit card data.
These email must include info about renewed product and payment. Needed fields are:
- {name}: First and last names of the user.
- {email}: email of the user. Username to access the service.
- {productName}: product title.
- {productDetails}
- {price}: Cost of the product.
- {SIAorderId}: Order number. (PURXXXX where XXXX = GVP_PURCHASES.ID)
- {GVPPurchasesHistoryDateins}: Renewal transaction date (system date)
- {SIACreditCardPAN}: Masked credit card number
- {SIACreditCardExpirationDate}: Credit Expiration Date.
- {SIACreditCardStatusBank}: Sometimes provides info about the reason behind the failure. It comes from GVP_USERS_SIA_CARDS.STATUS_BANK.
- {SIANextDate}: Number of days before next retry (notification.numDiasSusc ). It serves to indicate to the user when SIA will retry to charge the subscription. For instance, "We will try to charge you this subscription in {SIANextDate} days"
Note that
- if instance parameter HIDE_ADULT_PURCHASES is true, {productName} and {productDetails} will be masked as it is explained at Purchase emails: different behavior for Adult contents.
- if an instance has not HTML "Subscription renewal SIA Email - Failure ", gvp.sia MUST continue working.
Subscription renewal SIA Email - Failure and cancelation (4.0)
When SIA notifies to GVP that a subscription has been canceled because it was not possible to renew it and SIA_RETRIES_MAX has been reached an e-mail is sent to the user indicating that subscription has been canceled and inviting him to review credit card info
These email must include info about renewed product and payment. Needed fields are:
- {name}: First and last names of the user.
- {email}: email of the user. Username to access the service.
- {productName}: product title.
- {productDetails}
- {price}: Cost of the product.
- {SIAorderId}: Order number. (PURXXXX where XXXX = GVP_PURCHASES.ID)
- {GVPPurchasesHistoryDateins}:Renewal transaction date (system date)
- {SIACreditCardPAN}: Masked credit card number
- {SIACreditCardExpirationDate}: Credit Expiration Date.
- {SIACreditCardStatusBank}: Sometimes provides info about the reason behind the failure. It comes from GVP_USERS_SIA_CARDS.STATUS_BANK.
Note that:
- if instance parameter HIDE_ADULT_PURCHASES is true, {productName} and {productDetails} will be masked as it is explained at Purchase emails: different behavior for Adult contents.
- if an instance has not HTML "Subscription renewal SIA Email - Failure and cancelation ", gvp.sia MUST continue working.
Actions
Create | Edit | Edit in List | Bulk Edit | Copy | Copy with Relateds | Delete |
---|---|---|---|---|---|---|
Create
Administrators and OB administrators can create new HTMLs on demand.
- Use the button to create an empty HTML.
- Fill all the required information.
- Once finished, save changes by using the button.
Edit
HTML edition is enabled for operators. It can be used to modify some existing HTML information. Once finished modifying the HTML information, save changes by using the button in the link edit page.
Edit in List
Edit in list is not enabled for this page.
Bulk Edit
Bulk Edit is enabled in this page, allowing you to modify several items at the same time. However, not all the relateds blocks will be available for performing a bulk edit operation. The blocks available are:
- Basic HTML information
Copy
Copy is enabled in this page. Using the button, you will be able to clone the basic information from the HTML into a new HTML.
Once the link is copied, review that all the fields have been copied properly and press Save button.
Copy is enabled for this page and has the same behavior as Copy button.
Delete
HMLTs can be deleted by the operator using the button. A confirmation popup will be shown before excluding it.