Nvia API Specification For DCB.v3.0.10
Nvia API Specification For DCB.v3.0.10
for DCB
Version 3.0.10
26/09/2017
Legal Information
The information supplied in this document is Nvia Gestion de Datos S.L. sole property and copyright.
It is intended for strictly informational use. It is not binding and might be subject to changes without notice.
Any unauthorized disclosure shall be considered as unlawful.
NVIA GESTION DE DATOS S.L
Calle la Oliva 18, Las Rozas- Madrid, Spain.
www.nviasms.com
C ONTROL DE V ERSIONES
S2S (Sever to Server): Calls will be made to the interfaces directly made from the client
software without the user acting.
Redirections: The client will only redirect the user's navigation to the URLs necessary
for the identification of the device or for the interaction with the user.
Interaction: In these requests, the user's browser will directly perform the operations
required for approval, cancellation, etc.
In all cases in which the control of navigation is controlled by Nvia, this control will be returned
to the client at the end of the process. Good to report the acceptance or decline of the user's
actions.
Each registration, cancellation and payment event will be notified to the client via http with
GET method to a series of URLs that the client can provide. It's not mandatory. See section
notifications.
This type of flow can only be made in the mobile networks of the operators. If the device can
not be identified through the navigation network, the interface will return an error to inform
that this type of registration can not be used.
Step Description
1 User accesses the client's landing
2 Client uses transaction_request.php interface to get the URL to which he
must redirect the user
3 Nvia returns an XML with the redirect URL (redirUrl)
4 Client redirects the user to redirUrl
5 Nvia carries out the tasks of identification, provisioning and billing of the
service with the operator.
* Depending on the country and operator, the user will have to carry out
a series of operations to accept the product or service (payment and / or
subscription)
** Only the networks detected as mobile will be able to perform this
operation otherwise it will have to proceed with the registration via WEB
/ OTP using the interfaces otp_request.php and otp_validate.php.
6 The operation is confirmed by sending a welcome message to the user.
7 Nvia redirects the user to callbackUrl configured for the product.
8 Nvia notifies, asynchronously, the subscription and billing events.
5* If during the process, the user does not accept the operation, it will be
redirected to errorCallbackUrl with action = error
5** If during the identification process it is detected that the network does
not allow the subscription operation, the client will be redirected to
not3GCallbackUrl. If the otp_request.php and otp_validate.php
interfaces are available, they may have to be used.
This API will allow requesting a transaction start of a subscription or purchase process
(depending on the product) when the client is browsing through his mobile operator's network
(WAP / 2G / 3G). The use of the API will be through an S2S call (Server to Server). The return
will be an XML that will contain a parameter called redirUrl with the URL where the user
should be redirected. In case of error the XML will contain an error code and a description of it.
The parameters that must be used to use this interface are the following:
Respuesta Formato
XML <?xml version="1.0" encoding="UTF-8" ?>
<data>
<code>Código de Operación</code>
<description>Operation Description </description>
<redirUrl>
<![CDATA[URL where the user should be redirected]]>
</redirUrl>
<transaction_id> Transaction identifier</transaction_id>
</data>
Request/Response Example
S2S Request Transaction general mode:
http://test.panelwap.com/development/transaction_request.php?clientI
Begin Transaction d=2192&countryId=351&user=user01&password=Efows2102&productId=351221
Once captured redirUrl, the client must redirect the user's navigation said URL to continue
with the purchase or subscription process. An example, with redirUrl from the previous
example is the following:
http://test.panelwap.com/development/redir.php?clientId=2799&tId=1121286&subid=53171
518c5509
In addition, the registration action may also be notified to the address specified by the client.
* See section notificaciones.
Step Description
1 User accesses the Web Portal of the client and requests the withdrawal.
2 A customer manager wants to cancel a service.
3 Nvia requires requesting the withdrawal of a customer service. This process is
not usual but due to legal issues this capacity must exist.
4 For cases 1 and 2 the client will use the unsubscription_request.php interface
5 Nvia will manage the cancellation of the service with the operator.
6 A confirmation SMS will be sent to the user to inform him / her of the
withdrawal process.
7 Through the notification URL of withdrawal, Nvia will inform the customer of the
event.
Total unsubscription: In this modality, all the products associated with the MSISDN will
be canceled.
Discharge of a product: The MSISDN will be discharged only in the selected product.
The response format will be an XML that will have the following format:
Response Format
XML <?xml version="1.0" encoding="UTF-8" ?>
<status>
<code>Operation Code</code>
<description>Operation Description</description>
</status>
The operation, description and detail codes for this interface are the following:
Product unsubscription:
unsubscription_request.php?
countryId=51&productId=5139824&clientId=2799&user=smsuser&password=s
mspassword&subscriptionId=121104273200428814&msisdn=898246565
The notifications will be made through HTTP interfaces using the GET method to the URLs
provided by the client.
Notifications Description
Subscription URL where the client will receive a notification each time a user subscribes or
purchases a product.
Unsubscription URL where the customer will receive a notification when the user cancels a
subscription.
Billing URL where the user will receive a notification each time a billing operation is
performed
CODE ACK
o 0: Charged
NACK
o 1: No balance
o 10:MSISDN does not belong to the operator
o 11:MSISDN user blocked by operator
o 12:MSISDN is not registered in the operator
o 13:Full mailbox of the MSISDN
o 14:Incorrect technology or protocol
o 15:MSISDN does not belong to the list in the DB
o 16:Session not active for the MSISDN
o 20:Service temporarily unavailable
o 21:Service not available
o 30:Daily limit exceeded
o 31:Weekly limit exceeded
o 32:Monthly limit exceeded
o 33:Limit operator exceeded
o 40:Syntax error
o 50:Unknown error
In all cases, the client must return "OK" in plain text to confirm that the notification was
received. If this confirmation is not received, the notification will try to be sent in 4 other
occasions (at the minute, 2, 4 and 5 minutes later).
Response Example
Sucessfully OK
* The user has received the notification
Response
Failed Response KO
ERROR
ERR
* The system will evaluate as negative any response other than "OK"
** The shipment will be made again for 4 more occasions.
Email sent in case of NVIA error notification service
not responding at Date: DD / MM / YYYY Time: HH24: II: SS
any time Nvia error The following url has not responded to any of our access attempts:
notification service http://url.notificacion.del.cliente?productId=45225&countryId=45&ts=&host=9
99999&msisdn=123456789&op=WI&alias=MYSERVICEKEYWORD&serviceId=225
&&id_mensaje=WI0
Please check that the URL is correct and that you are answering correctly.
For the development and integration phase, Nvia will provide credentials that can be used in
the development environment. Once the development phase is completed, it will be necessary
for the client to facilitate the landing to obtain the pertinent approvals according to the
current legislation in each country.
Nvia side
Nvia will provide the following data that should be used for the use of the interfaces.
Parameter description
clientId Client identifier
countryId Country code where the product will be marketed
user Login Identification credential in the system.
password Password. Identification card.
productId Unique product identifier.
The domains where the interfaces are hosted are the following:
In each country Nvia will deliver an annex to this document, explaining the exceptions or
customizations associated with the location of the service. In the same way, a guide of good
praxis will be delivered for the accomplishment of the landing pages with the purpose that the
client can build his page according to the effective legislation in each country.
Client side
The following parameters must be provided by the client:
Parámetro Descripción
callbackUrl URL where the user will be redirected in case of success. If this
parameter does not exist, the user will be redirected to the URL
configured by default
not3GCallbackUrl URL where the user will be redirected if they can not be processed via
WAP. If this parameter does not exist, the user will be redirected to the
URL configured by default
errorCallbackUrl URL where the user will be redirected in case of failure. If this
parameter does not exist, the user will be redirected to the URL
configured by default
Subscription Notify URL Client URL where you will receive notifications of subscription events.
Unsubscription Notify Client URL where you will receive notifications of unsubscription events.
URL
Billing Notify URL Client URL where you will receive notifications of billing events.
Contact email Email account where the customer will be alerted of possible incidents
in the service.
Service IP P from where the interfaces will be used. Nvia will need to control that
only from those IPs can services be accessed.