R28.1-LDAP Interface Specification

8620 SurePay® 27.7/28.
1
LDAP Interface Specification
270-735-079R27.7
Issue 3
May 2010
Legal Notice
This material is protected by the copyright and trade secret laws of the United States and other
countries. It may not be reproduced, distributed, or altered in any fashion by any entity (either
internal or external to Alcatel-Lucent), except in accordance with applicable agreements,
contracts or licensing, without the express written consent of Alcatel-Lucent and the business
management owner of the material.
Product Development Manager 1-630-224-0378
Notice
This document also applies to SP28.1, which is simply SP27.7 rebuilt on MAS platform R28SU2.
All descriptions apply to both MAS R27SU8 and MAS R28SU2 platforms unless specifically
stated otherwise.
Every effort was made to ensure that the information in this Information Product (IP) was
complete and accurate at the time of printing. However, information is subject to change.
Mandatory customer information
Security Statement
In rare instances, unauthorized individuals make connections to the telecommunications network
through the use of access features.
Trademarks
All trademarks and service marks specified herein are owned by their respective companies.
SurePay is a Registered Trademark of Alcatel-Lucent.
Ordering information
To order this document in the United States, call 1-888-582-3688. In other countries call your
Alcatel-Lucent Technologies Market Manager.
Support
Technical support
For technical support on this product in the United States and Canada, call 1-800-WE2CARE. In
other countries, contact your Lucent Technologies customer helpdesk.
Information product support
Alcatel-Lucent - Proprietary
Document History
Issue Version Date Change Description
Issue 1 January 1, 2010 First Issue
Issue 2 February 4, 2010 Second Issue
Issue 3 May 5, 2010 Third Issue
Contents
1 Introduction 1
1.1 External References 1
2 LDAP Interface for Surepay 2

2.1 LDAP DataView Method 2
2.1.1 Compliance to LDAP Standard 2
2.1.2 General Requirements 2
2.1.3 Client Requirements 3
2.1.4 Server Requirements 3
2.1.5 Enhancements 3
2.1.6 LDAP Initialisation Requirements 5
2.1.6.1 LDAP Initialisation with SurePay as Server 5
2.1.6.2 LDAP Initialisation with SurePay as Client 5
2.1.7 LDAP Request Definitions with SurePay as Server 6
2.1.7.1 e-Commerce LDAP Requests 6
2.1.7.1.1 General Requirements for e-Commerce 6
2.1.7.1.1.1 Common Input Parameters 6
2.1.7.1.1.2 Platform Result Codes 8
2.1.7.1.1.3 Application Result Codes 8
2.1.7.1.2 Authenticate Subscriber 13
2.1.7.1.2.1 Interface Requirements 13
2.1.7.1.3 Request Balance 14
2.1.7.1.3.2 Dataview Definition 16
2.1.7.1.4 Request Credit (Credit Card) 17
2.1.7.1.5 Request Credit (Scratch Card) 20
2.1.7.1.6 Request Credit 22
2.1.7.1.7 Request Debit (Service Delivery) 23
2.1.7.1.8 Request Debit 28
2.1.7.1.9 Credit Reservation 30
2.1.7.2 eCGS LDAP Interface 33
2.1.7.2.1 Request Top Up 33
2.1.7.2.2 Request Automatic Top Up Parameter Setting 35
2.1.7.2.3 Request Feature Package 36
2.1.7.2.4 Request Bundle Subscription 43
2.1.7.2.5 Request Voicemail Retrieval Charge 50
2.1.7.3 Misc. LDAP interface 51
2.1.7.3.1 Generic LDAP interface 51
2.1.7.3.1.1 Application Result Code 51
2.1.7.3.1.2.1 LDAP Query RTDB data 54
2.1.7.3.1.2.2 Authenticate 3rd party user 60
2.1.7.3.1.2.3 Modification 3rd party PIN 61
2.1.7.3.1.2.4 Authenticate Balance transfer 62
2.1.7.3.1.2.5 Balance transfer 64
2.1.7.3.1.2.6 Execute IMOM command 65
2.1.7.3.1.2.7 Update RTDB data 65
2.1.7.3.1.2.8 Request Notification 66
2.1.7.3.1.3 Dataview definition 68
2.1.8 LDAP Request Definitions with SurePay as Client 68
2.1.8.1 Digit Mapping Request 68
2.1.8.1.1 Interface Requirements 68
2.1.8.1.2 Dataview Definition 69
2.1.8.2 Family Group Releation Request 69
2.1.8.2.2 Dataview Definition 70
2.2 LDAP Standard Method 70
2.2.1 LDAP Initialisation Requirements 70
2.2.1.1 LDAP Initialisation with SurePay as Client 70
2.2.2 LDAP Request Definitions with SurePay as Client 71
2.2.2.1 General Requirement 71
2.2.2.2 MNP Query Request 71
2.2.2.3 Community Tariff Query Request 72
1 Introduction
This document describes the LDAP (Lightweight Directory Access Protocol) Interface to the Lucent Technologies Surepay
service first added in Version 7 implemented on the Enhanced Control Server (eCS) platform (the eCS was formerly known as
the Service Control Point, or SCP. Any reference to SCP in this document shall be taken to mean eCS).
The LDAP interface on the eCS is identical to that on the MiLife (R) Application Server (MAS) for the equivalent release. For
example, the LDAP interface for V10SU5 on the eCS is identical to the interface for R25SU1 on the MAS. Additionally, the
interface is identical between equivalent releases in R25 and R26. For example the interface for R25SU4 is identical to the
interface for R26SU0. The interface is identical between equivalent releases in R26 and R27. For example the interface for
R26SU8 is identical to the interface for R27SU3.
Support for the LDAP e-Commerce interface was first added over two Surepay releases, V7.0 and V7.1 and subsequently
enhanced in Version 8. The interface for V10SU2 is functionally identical to V8SU6.
For all eCommerce request types the SurePay service is acting as the server.
This eCommerce LDAP interface allows a back-office system to query certain subscriber information and to apply a variety of
charges or recharges to the subscriber's account. The types of charges and recharges that can be applied are described in
detail in this document.
The SurePay service also includes support for a different type of LDAP interface for digit mapping. This interface allows
SurePay to send an LDAP request to an external system in order to map a digit string to another digit string (e.g. for number
portability). For the Digit Mapping LDAP requests SurePay is acting as the client and the external Digit Mapping system shall
act as the server. This document also includes a specification of the LDAP interface required to be supported by the server
system.
SurePay is a registered trademark of Lucent Technologies. The LDAP interface to SurePay is related to the SurePay Online
Charging Service (OCS). Any reference to SurePay throughout this material shall be taken to mean 8620 SurePay ® OCS
unless there is a specific note to the contrary.
Prior to V10SU7 all e-Commerce LDAP requests could be handled by an Interface SPA which in turn interacted as necessary
with the main Surepay SPA which handles call processing and subscriber account management. From V10SU7 all e-
Commerce interfaces and functionality is migrated to the main SurePay SPA and this Interface SPA is no longer necessary.
When describing the contents of LDAP messages the ASN.1 labels from the message syntax definitions in [RFC1777] are
used. Note, however, that the ASN.1 message definitions are not duplicated in this document.
1.1 External References

References
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol", Internet Engineering Task Force, RFC 1777, March 1995.
http://www.ietf.org/rfc/rfc1777.txt
[RFC2251] M. Wahl, T. Howes, S. Kille,
"Lightweight Directory Access Protocol", RFC 2251, December 1997.
http://www.ietf.org/rfc/rfc2251.txt
Page 1 of 73 Alcatel-Lucent - Proprietary

2 LDAP Interface for Surepay
This section defines the LDAP requests supported by the Lucent Technologies Surepay service. All requests and responses
are described in terms of the definitions in [RFC1777].
2.1 LDAP DataView Method

2.1.1 Compliance to LDAP Standard
This section describes how LDAP as used for Surepay (from Version 7) differs from the LDAP Version 2 standard defined in
[RFC1777]. More detailed information relating to LDAP operation usage and the required settings for individual parameters can
be found in subsequent sections of this document.
1. In the case of Surepay e-Commerce, the LDAP interface is not being used to provide a client access to data stored in an
X.500 directory on the server. Instead the LDAP interface is used to provide a set of pre-defined commands that allow a client
to access a discrete set of Surepay functions specifically relating to e-Commerce. This will not allow, for example, read or write
access to any Surepay data other than that described in this document. In addition, Surepay applies some checks on the
information provided in the e-Commerce request according to its own constraints and/or provisioned data. Because the data
on the server is not stored in an X.500 directory, some LDAP parameters and options defined in the standard do not apply.
2. Surepay supports only a subset of the LDAP operations supported by the Lucent Technologies MAS platform. Surepay
supports ONLY the following LDAP operations :
- BindRequest
- BindResponse
- SearchRequest
- SearchResponse
Note that the LDAP UnbindRequest is purposely not supported. The MAS expects an LDAP connection to remain permanently
bound for performance reasons.
3. In the BindRequest operation, a proprietary format for the "name" parameter is required and only the "simple" setting of the
"authentication" parameter is supported.
4. In the SearchRequest operation, a proprietary format for the "baseObject" parameter is required and a proprietary
"extension" is used to encode multiple input fields into a single key defined in the AttributeValueAssertion for the "filter"
parameter.
5. Surepay eCommerce will not return application-specific errors in an unsuccessful SearchResponse. Instead a ResultCode
field will be populated in a successful SearchResponse operation. This is because the LDAP standard does not define
sufficient error codes for the purposes of eCommerce.
2.1.2 General Requirements

In most cases the LDAP operations described in this document need to both write multiple data fields and return multiple data
fields. The LDAP implementation on the MAS platform requires that an LDAP Modify request cannot return multiple data fields
and LDAP Search cannot write multiple data fields. The solution is to apply an "extension" to the LDAP standard by using an
LDAP Search message “encoding” the attributes that need to be written in the key field using “:” as a separator. Only the
attribute values are “encoded” in this way, not their names.
Example:
For the e-Commerce Request Debit (Service Delivery) LDAP request (see later for more information), the key value
“123456789::777::::MT_SMS:Weather:1:0” means«
Subscriber ID = 123456789
Provider ID = omitted
Transaction ID = 777
Requesting System = omitted
Merchant ID = omitted
Reference = omitted
Service Type = MT_SMS
Content Type = Weather
Number of Items = 1
Balance Indicator = 0 (Default Balance)
To reduce the number of dataviews in SurePay, and make the interface more flexible, some LDAP operations require the key
field to be encoded in a different schema instead of simple join using ':'. For example, name/value pairs will be used in the key
field ("OP=Q;Tbl_name=SIMRTDB;Tbl_key=xxx;Field_name=F1,F2,F3"). Other than ':', ',',';' and '#' may be used for delimiter
of different purpose.
SurePay will perform content sensitive parsing of the key string in these cases.

2.1.3 Client Requirements
This section defines the requirements for client systems using LDAP requests to access SurePay acting as a server for LDAP
purposes.
The SurePay service is configured to run on one or more Mated Pairs of MAS's and each subscriber is assigned one MAS of
the pair to be primary (under normal call processing circumstances calls for a subscriber will be sent to the MAS that is primary
for that subscriber. Only if that MAS is down will the call be sent to the alternate MAS). This means that there are two possible
destination server MAS's for LDAP requests for any given subscriber. If the first LDAP Request from the client fails (time out)
then the client should attempt to resend the request to the other MAS. This requires that a mechanism should be defined on
the client (e.g. data table) to map each subscriber to a primary and alternate MAS. The client should always send the first
request to the primary MAS for a subscriber.
From V10SU7 the e-Commerce Interface SPA is no longer necessary as all e-Commerce functionality is supported in the main
SurePay SPA. If the Interface SPA is not used then an LDAP Request must be sent to the Primary MAS. If the first LDAP
Request from the client fails (time out) then the client should attempt to resend the request to the Secondary MAS.
The MAS server requires that a unique dataview name (dview) is defined in order to allow the client to address data stored
across multiple physical databases with a single request (all dataview names (dviews) are also defined on the MAS platform
using RCV forms 9.*). The dataview name (dview) comprises the physical dataview table name on the server plus an MAS-
specific identifier, as follows:
Dataview Name (dview) = Server MAS Id + “_” + Physical Dataview Table Name
e.g. dview = “MAS01_sub_debit” will be the dataview name for the sub_debit dataview table on server MAS “MAS01”
The requirement for the client is to bind to the defined dataview names using an LDAP Bind Request for each dataview for
each server MAS. (i.e. there could be multiple BIND requests sent to each server MAS, one for each dataview required to be
used). This implies that a mechanism should be defined on the client to store the server MAS Ids (e.g. data table) so that
additional servers can be added without any need to modify the client code. This table should also include the server host
name (could be the same as the MAS Id above) and port number. These are required for TCP/IP link setup.
Note that the maximum length of a dataview name (including the MAS Id) is 30 characters. This limit is imposed by the MAS
platform.
The client needs to store the LDAP password for each dataview to be provided in the BIND Request.
IMPORTANT: The dataview and field names used in the LDAP requests sent from the client must exactly match the names
specified in this document (including upper/lower case and underscore characters) in order for the request to be correctly
processed.
2.1.4 Server Requirements

This section defines the requirements for server systems which receive LDAP requests sent by SurePay acting as an LDAP
client.
Internally the SurePay client defines a dataview name (dview) which is configured on the MAS platform using RCV forms 9.* to
map to physical host/port Ids for TCP/IP. The name used comprises the dataview name on the client plus an identifier of the
server Id, as follows:
Dataview Name (dview) = Server Id + “_” + Dataview Name
e.g. dview = “serv01_test” will be the dataview name for the test dataview on server “serv01”.
The server Id is only included to allow the client to direct requests to specific servers (in case multiple servers are present).
The dview name appears in both BIND and SEARCH requests sent by the SurePay client. The server is not required to do
anything special based on the dview name or server Id except to recognise that this is a valid LDAP request. The dataview
concept is only meaningful on the client.
Note that the maximum length of a dataview name (including the MAS Id) is 30 characters. This limit is imposed by the MAS
platform.
2.1.5 Enhancements
This section is added to describe enhancements in subsequent releases.
In V10SU4 the handling of Credit Reservation requests is enhanced. In the event that the subsequent Debit request requires
an additional amount to be debited but the account has insufficient balance to cover the extra amount and Outstanding
Charges are not allowed then the following options are available, based on a configuration parameter in SurePay data:

• Allow the request and set the balance to zero - that is, deduct as much balance as possible. This is the default
behaviour. This matches the behaviour of SurePay before the enhancement was added.
• Allow the request and set balance to zero, but also send back the amount of "lost" credit in a new parameter in the
LDAP debit response.
• Fail the debit request with "Insufficient Funds". This leaves the original reservation still outstanding. The client system
can send a subsequent debit, a reservation cancel or just let the reservation expire.
From V10SU5 the maximum number of characters supported in the Reference field is increased from 14 to 40 and the valid
characters changed from digits to character string. A new field is also added to the AMA record to contain the enlarged field
contents called "Enhanced Reference". The service will populate both new Enhanced Reference and existing Recharge
Reference fields. When the logic populates the Recharge Reference field, only the most significant 15 digits will be populated
into the field. Any remaining digits will be dropped. This method can make sure the usage of the existing Recharge Reference
field is backward compatible. The Enhanced Reference field will contain the entire content of the Reference in the incoming
request.
From V10SU6 the following enhancements are included:
• An additional request type "Request Bundle Subscription" is added.

• For failed Credit Card & Scratch Card Recharge requests an additional response parameter is added to inform the client
how many subsequent failed attempts will be allowed by SurePay before the SIM is put into a barred state. The inclusion
of this field is controlled by separate data configuration parameter.
• For successful Scratch Card Recharge requests the amount of the Scratch Card used is included in the response. The
inclusion of this field is controlled by separate data configuration parameter.
• SurePay allows LDAP Request Debit Service Delivery requests to be specifically treated by SurePay as real-time
SMS/MMS requests, determined by the Service Type. In these cases the requests will be handled by the SurePay real-
time SMS logic, rather than the generic eCommerce logic. This allows SMS/MMS-specific rating, screening and other
functionality to be applied.
• For Request Debit Service Delivery two additional input parameters are supported; Location Information and Location
Information Type. These parameters can be used, for example, in charging for real-time SMS via eCommerce. These
parameters can be used to allow the client to specify that the charge is differentiated according to the subscriber location.
• For Request Credit, one additional output parameter is supported, Additional Message. This parameter can be used to
provide to the client an additional message returned by the recharge DG. For example, a code can be returned after either
DG is traversed successfully or DG indicates the recharge amount is invalid.
From V10.7 the following enhancements are included:
• All e-Commerce functionality is supported in the main SurePay SPA. Therefore the e-Commerce Interface SPA is no
longer necessary.
• For Request Credit (Credit Card), Request Credit (Scratch Card) and Request Credit, a new optional parameter "Credit
Validity Period" is supported.
• For "Request Bundle Subscription" up to 15 Friends&Family numbers are added in the response.
From V10SU8 the following enhancements are included:
• The Authenticate Subscriber request supports returning the Class of Service (COSP) ID for the subscriber as an option.
• The Request Credit request supports returning a Class of Service code as an option.
From V10 SU9, the following enhancements are included:
• IPv6 support is included.
• Location Information field in Debit request (service delivery) is extended to contain IPv6 address.
• SurePay supports to reverse last recharge by the Debit Amount (Direct) request if each recharge is recorded in RE
RTDB.
• A general purpose LDAP interface of SurePay provides the functionality of subscriber profile (in SIM RTDB) query.
• There are 4 additional optional fields added for below dataviews for CDR purpose only:
• Request Credit (including direct credit, credit card, scratch card)
• Request Debit (including direct debit, service delivery)
• Reserve Credit
• New Parameter International Indicator and Connected DNlist are added into Query Balance, Request Debit
(including direct debit , service delivery)
• The Generic LDAP interface is enhanced to support actions such as Authenticate 3rd Party User and 3rd Party PIN Update.
• A new result code is added specifically for LDAP requests used for SMS charging
• Enhancements to the Generic LDAP interface to support extra functions
• Parameter "Account Data Group ID" added to some eCommerce LDAP request types
From R26SU7,
• New Request "Token Operation" is added for the token information query.

From R26.8,
• New Parameter AddressList is added into Query Balance, Request Debit (including direct debit , service delivery).
• New parameter Counter Information is added into Query Balance interface.
2.1.6 LDAP Initialisation Requirements

2.1.6.1 LDAP Initialisation with SurePay as Server
The LDAP protocol is defined to run on a standard TCP/IP interface. The client therefore shall initially set up a TCP/IP
connection to the server using the server host name and port number.
The LDAP client must send a Bind Request to establish an LDAP connection for each different type of LDAP operation
(dataview) for each server MAS.
LDAP Bind Request

LDAP Parameter Population Rules Comments
version 2 The MAS platform supports LDAP
Protocol Version 2
name OCTET STRING, populated as From the client's point of view, the
"dview=<MAS Id>_<dataview> e.g. "dataview" is the table name
"dview=MAS01_auth_sub"
authentication Choice = simple, containing the OCTET The password must match that defined on
STRING "<password>" e.g. "pass01" MAS platform RCV Form 9.4
LDAP Bind Response

resultCode result code assigned by the server. Possible values are:
success(0):
The "dataview" and password were
validated and the LDAP connection to the
server is now set up.
invalidCredentials(49):
Either the "dataview" or password were
invalid
unwillingToPerform(53):
The "dataview" and password were valid,
but an error has occurred on the server
that makes it unable to setup the LDAP
connection.
matchedDN zero length OCTET STRING Not set to any meaningful value by MAS
platform. Client should ignore any value in
this field.
errorMessage zero length OCTET STRING Not set to any meaningful value by MAS
platform. Client should ignore any value in
this field.
The MAS platform expects that all LDAP connections to the client are permanently bound. The UNBIND Request message is
not supported by the server and shall be ignored if received.
If after sending a BIND Request and successfully setting up the LDAP connection the client receives an LDAP Response
failure message containing a resultCode set to one of the following:
inappropriateAuthentication (48)
invalidCredentials (49)
unwillingToPerform (53)
then this indicates the server is unable to process the request. The client will have to rebind by sending another BindRequest
message to the server.
It is the responsibility of the client to detect the loss or failure of the TCP/IP connection to the server. This will require the client
to reconnect and rebind. Note that the method used to indicate the failure of the TCP/IP connection is not explicitly defined in
[RFC1777] and will depend on the LDAP library used by the client.
2.1.6.2 LDAP Initialisation with SurePay as Client

The LDAP protocol is defined to run on a standard TCP/IP interface. SurePay therefore shall initially set up a TCP/IP
connection to the server using the server host name and port number as defined on platform RC screens.

The SurePay client must send a Bind Request to establish an LDAP connection for each different type of LDAP operation
(dataview) for each server.
LDAP Bind Request

version 2 The MAS platform supports LDAP
Protocol Version 2
name OCTET STRING, populated as From the client's point of view, the
"dview=<server Id>_<dataview> e.g. "dataview" is the table name
"dview=serv01_test"
authentication Choice = simple, containing the OCTET The password is defined on MAS platform
STRING "<password>" e.g. "pass01" RCV Form 9.4
LDAP Bind Response

success(0):
invalid
connection.
matchedDN zero length OCTET STRING
errorMessage zero length OCTET STRING
The MAS platform expects that all LDAP connections to the server are permanently bound. The UNBIND Request message is
not supported and shall never be sent by the client.
If after sending a BIND Request and successfully setting up the LDAP connection the server requires the client to reBIND it
shall send an LDAP Response failure message containing a resultCode set to one of the following:
inappropriateAuthentication (48)
invalidCredentials (49)
unwillingToPerform (53)
This indicates the server is unable to process the request and the client will have to rebind by sending another BindRequest
message to the server.
It is the responsibility of the client to detect the loss or failure of the TCP/IP connection to the server. This will require the client
to reconnect and rebind.
2.1.7 LDAP Request Definitions with SurePay as Server

This section provides a detailed description of the complete set of external LDAP requests supported by the Surepay service.
2.1.7.1 e-Commerce LDAP Requests

The Surepay service supports a set of LDAP requests which provide a comprehensive set of options for external applications
to validate and pay for E-Commerce transactions.
The transactions include subscriber authentication, request balance, request credit through point of sale, banks, credit card
and scratch cards, debit requests and credit reservation. The service provides a mechanism for charging for different content
such as weather or football scores over various services such as SMS, WAP, GPRS. The server also allows providers to
group services together and simply charge for the number of messages or packets sent/received over a number of services.
2.1.7.1.1 General Requirements for e-Commerce

2.1.7.1.1.1 Common Input Parameters
The following table describes those input parameters common to more than one e-Commerce LDAP Request.
Input Parameter Meaning Comments

Subscriber ID Identifies the Surepay subscriber (e.g. This parameter must match a key entry in
MSISDN) the Surepay SIM Table, or the User
Access (UA) Table.
This parameter is required to be in

International format (i.e. including country
code) if this is the way the Surepay SIM
table has been provisioned.
Provider ID Identifies the Surepay subscriber Provider The Provider ID was formerly called
ID. If present, this must match the Provider "Account ID" in V8.
ID populated in the subscriber's data.
Transaction ID An digit string that identifies the If present, this parameter shall be
transaction. included in any AMA record created by e-
Commerce Requests.
This string may be used for the
Transaction Logging feature. This parameter is also used to correlate
Balance modification AMAs generated in
the Surepay SPA to the e-Commerce
Request AMA.
If the Transaction Logging feature is

enabled then this field is treated as
Mandatory.
Requesting System A digit string that identifies the system If present, this parameter shall be included
requesting the eCommerce service. in any AMA record created by e-
Commerce Requests.
This string may be used for the
Transaction Logging feature. SurePay may regard this as a mandatory
field if Transaction Logging is active and
the Transaction ID alone is not guaranteed
to be unique across all clients. If this is the
case and this parameter is missing then
the request will fail and SurePay will return
the error "Invalid or Missing Parameter".
Merchant ID Identifies the Merchant providing the If present, this parameter shall be included
service. If present, must match an entry in in any AMA record created by e-
the Surepay e-Commerce Merchant (EM) Commerce Requests.
Table
If no match is found in the EM table the
request fails and SurePay returns the error
"Invalid Merchant ID".
Transaction Amount Indicates an amount to be credited to or May include a decimal point "." and up to 4
debited from the subscriber's balance. digits after the decimal point.
Reference A character string. This content of this If present, this parameter shall be included
string is of no significance to Surepay. in any AMA record created by e-
Commerce Requests.
This field will contain the value of the

Additional Info parameter in the eCGS
XML interface, if this is used.
Balance Indicator An indication of which balance to use for

debit/credit requests.
Currency Label An indication of which currency to use if an Up to 24 digits are supported, but the
amount of money was specified. upstream system can send the standard
ISO-4217 3 digit currency label if required.
All possible values to be sent must be
provisioned in the Surepay International
Currency (IC) Table.
Credit Validity Period For recharges, indicates the recharge If populated, indicates the number of days,
credit validity period, as defined by the from 1 to 9999.
external system.
Service Specific Data 1~4 4 additional optional parameters of 100 If present, these parameter shall be
character string. included in any AMA record created by e-
Commerce Requests.
Note that all input parameters present in the Search key will be included in the response encoded in the objectName LDAP
Search response parameter, encoded with ":" separator characters in the same format as received in the Search request.

The Balance Indicator used in the following LDAP requests is of the following format:
0 - Default Balance (default)
1 - Primary Balance
2 - Secondary Balance
3 - Balance determined by Balance Selection logic. This value is only valid for request credit reservation, request debit and
request debit service delivery. (V10.9)
SurePay shall perform the following validation for all parameters unless there are specific requirements for special handling:
- If the parameter exceeds the maximum allowed length or if the value contains any invalid characters then the request shall
be rejected with the result code "Invalid or Missing Parameters".
Parameters that are defined as type "Chars" can generally speaking support any character that can be typed on a standard
computer keyboard. Note, however, that in many cases values provided must match SurePay data provisioned via the eSM
and therefore the set of valid characters is restricted. It is therefore recommended that to avoid unexpected results the
following are not provided in an LDAP character field for eCommerce:
- The double-quote character (")

- Any control character
- Any alt character
- Tab
- Enter/Return
In addition the colon character ":" must never be included as this is used as a field separator.
For Request Credit (Credit Card), Request Credit (Scratch Card) and Request Credit, the Credit Validity Period will only
change SIM Credit Expiry Date if the Current Date + Credit Validity Period is later than the current SIM Credit Expiry Date (if
not NULL).
2.1.7.1.1.2 Platform Result Codes

The MAS platform will return one of the following LDAP result codes for unsuccessful eCommerce requests that fail at the
platform level. Note that the MAS platform does not populate the LDAP matchedDN and errorMessage parameters with any
specific values. The client should ignore the settings of these parameters. Requests that fail at the MAS platform will generally
never reach the SurePay service. Explanations of what the error indicates is also included below:
21 = invalidAttributeSyntax
This error code indicates the LDAP SearchRequest message contains a text string for the key name that does NOT match the
key name for the Dataview in Surepay.
49 = invalidCredentials
This error code indicates the hostname associated with the SearchRequest is NOT the same hostname as was verified by the
initial BindRequest.
51 = busy
This error code indicates the TCPIPSCH process is running out of memory processing LDAP SearchRequests. This indicates
the MAS is heavily loaded. If applicable the client may retry this request later.
53 = unwillingToPerform
This error code indicates the IMODULE SPA that handles eCommerce requests is not running. The client may be able to send
the request to the secondary MAS in a mated MAS configuration.
80 = other
This error code indicates the TCPIPSCH process encountered an LDAP decode problem while processing the SearchRequest.
2.1.7.1.1.3 Application Result Codes

For all the e-Commerce requests the following result codes are used. Explanations of what the error indicates is also included:
00 = Success
This result code indicates the request was successfully processed.

01 = Invalid or missing parameters
This result code indicates the request failed because mandatory data was missing or data was present but in the wrong format
(e.g. included invalid characters).
Possible reasons include (but are not limited to):

* A Credit Card recharge request has "Requires Processing" set to 0, but no Auth Code is present.
* A Credit Card recharge request has "Requires Processing" set to 1, but no Card Type or Expiration is present.
* A Credit Card Type was provided, but did not match an entry in the SurePay CCRT table.
* A Scratch Card ID was provided, but the length was found to be incorrect according to SurePay data requirements.
* Transaction Logging is active and SurePay did not receive sufficient information to derive a unique key (one or both of
Transaction ID or Requesting System ID was missing).
* An invalid Content Value Type was provided in a Credit Reservation or Debit Service Delivery request.
* One of Content Value Type and Content Value was provided, but not both, in a Credit Reservation or Debit Service Delivery
request.
02 = Invalid subscriber details
This error code indicates the request failed because the provided subscriber ID could not be found by SurePay in either then
SIM or UA tables or the subscriber has an eCommerce package provisioned in the SIM table, but no such package was found
in the eCommerce Package table (eCP).
03 = e-Commerce disabled
This result code indicates the request failed because subscriber has eCommerce disabled, or the subscriber is a postpaid
account and the subscriber's COSP data eCommerce Requests Allowed for Postpaid subscriber is set to false.
04 = Invalid merchant ID
This result code indicates the request failed because the Merchant ID in the request did not match a valid entry in the e-
Commerce Merchant data.
05 = Subscriber activity barred
This result code indicates the request failed because:
* All activity is barred in the subscriber's current lifecycle state
* eCommerce activity is barred in the subscriber's current lifecycle state.
* eCommerce activity is barred because the subscriber's account is not yet activated.
* The subscriber's account has expired or not valid yet.
* The subscriber's account is in error because the Account data Error Indicator is set to a value other than "Normal".
* For token charging, execute time for eCommerce credit reservation request is invalid for the reserved token start time and
end time.
* No balance of this account is selected out for this call for charge. (V10.9)
06 = Barred Call in Progress
This error code indicates the request failed because a call is in progress and the service has been configured to reject
eCommerce requests in this case.
07 = Invalid currency label
This result code indicates the request failed because the Currency Label in the request does not match a valid entry in the
International Currency data.
08 = Maximum balance limitation
This result code indicates a recharge request failed because the Recharge Amount would cause the subscriber's balance to
exceed a provisioned maximum limit.maximum.
09 = Minimum balance limitation
This result code indicates:
* A credit card recharge request fails, because the Recharge Amount was less than the minimum amount allowed for such a
recharge.
* A credit reservation request fails, because there is insufficient balance in the subscriber's account, and the reservation would
cause the balance to drop below the threshold defined by the COSP data e-Commerce Minimum Credit for Reservation.
10 = Credit card request declined
This error code indicates a Credit Card Recharge request failed because the external credit card system refused the
transaction.
11 = Credit card daemon not in service
This error code indicates a Credit Card Recharge request failed because no external credit card system was available.
12 This result code is not used.
13 = Invalid or missing PIN

This result code indicates a credit card recharge request fails, because the provided PIN was invalid.
14 = Credit card number unknown
This error code indicates a Credit Card Recharge request failed because the provided card number was invalid.

15 = Maximum recharges reached
This error code indicates a Credit Card Recharge request failed because the request would cause the cumulative number of
credit card recharges to exceed the maximum allowed.
16 = Maximum recharge value exceeded
This error code indicates a Credit Card Recharge request failed because the recharge amount exceeded the maximum
allowed for a single credit card recharge.
17 = Not supported by subscriber
This result code indicates :
* A Credit Card Recharge request failed because the subscriber's class of service indicates that credit card recharges are not
allowed.
* A Credit Reservation request failed because the subscriber's class of service indicates credit reservations are not allowed.
18 = Wrong type/missing balance
This result code indicates a request fails, because the request included a balance indicator that was invalid:
* Secondary balance was indicated, but the subscriber was not mixed credit and had no such balance
* The request was a recharge or a credit reservation and the subscriber was Postpaid.
* The request was a debit for a Postpaid subscriber and SurePay data indicates this subscriber does not support Postpaid
debits.
19 = Subscriber suspended
This code is Not Used.
19=Transaction Amount Invalid

From R27.9, this result code used for Credit Request to indicates that the transaction amount is invalid.
20 = No such card
This error code indicates a Scratch Card Recharge request failed because the external system returned a "No such card" error
or a Credit Card Recharge request failed because the external system indicated the supplied credit card was invalid.
21 = Card invalid by previous use
This error code indicates a Scratch Card Recharge request failed because the external system indicated the scratch card had
been used already.
22 = Scratch card not active
This error code indicates a Scratch Card Recharge request failed because the external system indicated the scratch card was
not yet active and could not be used yet.
23 = Scratch card expired
This error code indicates a Scratch Card Recharge request failed because the external system indicated the scratch card had
expired.
24 = Invalid account for card
This error code indicates a Scratch Card Recharge request failed because the external system indicated the account provided
was invalid.
25 = Scratch card database internal error
This error code indicates a Scratch Card Recharge request failed because the external system indicated an internal error
occurred.
26 = Scratch card database system fault
This error code indicates a Scratch Card Recharge request failed because the external system indicated a database error
occurred.
27 = Fault when sending request
This error code indicates a Scratch Card Recharge request failed because the external system indicated there was a fault
sending the request.
28 = Scratch card daemon not replying
This error code indicates a Scratch Card Recharge request failed because there was no response from the external recharge.
29 = Parameter error with request
This error code indicates a Scratch Card Recharge request failed because the external system indicated the scratch card
request included a parameter error.
31 = Unexpected response from daemon
This error code indicates a Scratch Card Recharge request failed because the external system returned an expected
response.
32 = Invalid scratch card PIN
This error code indicates a Scratch Card Recharge request using the internal SurePay database failed because the provided
PIN did not match the PIN for that card in the database.

33 = Inactive scratch card batch
This error code indicates a Scratch Card Recharge request using the internal SurePay database failed because the card batch
was not yet active (as defined in the SurePay Scratch Card Batch table).
34 = Unsubscribed service
This error code indicates a request failed because:
* No match could be found in the eCommerce Rating Parameters table for the provided Merchant ID. This table is searched
for all types of recharge requests and for all debit requests where SurePay calculates the transaction amount (Request Debit -
Service Delivery or Credit Reservation).
* No match could be found in the Subscriber Usage Count (SUC) table for the provided combination of Merchant ID, Service
Type and Content Type. This table is searched for all debit requests where SurePay calculates the transaction amount
(Request Debit - Service Delivery or Credit Reservation). However, note that it is possible for the SUC table to be optionally
omitted, even if Request Debit - Service Delivery or Credit Reservation requests are used. In this case it is never possible for
this error to be returned due to missing SUC table records.
35 = Insufficent funds
This error code indicates a request failed because the subscriber's account had insufficient balance for the amount indicated to
be debited.
36 = Maximum cumulative recharges reached
This error code indicates a Credit Card Recharge request failed because the request would cause the cumulative amount of
credit card recharges to exceed the maximum allowed.
37 = Failed - Transaction ID Used
This result code means the provided Transaction ID has been previously used by a different request type, or for a different
subscriber. This will be an indication of non-unique transaction IDs being sent from a requesting application.
38 = Failed - Transaction ID Committed
This result code means the requested Transaction ID has already been received and successfully processed by SurePay. This
will be an indication that a successful response to the original transaction was lost, causing a re-send from the requesting
system. This error return can therefore actually be regarded as a success case.
39 = Failed - Maximum Reservations Exceeded
This result code indicates that a Credit Reservation request fails, because the request would cause the maximum number of
simultaneous reservations for this subscriber to be exceeded. The limit is defined by the SurePay COSP data e-Commerce
Maximum Number of Reservations.
This error can also be returned because the reservation period exceeded the maximum allowed.
40 = Failed - Transaction ID Unknown
This result code means that a Transaction ID that should exist in the SurePay Transaction ID data can not be found. Currently
this can only occur for execution of a Debit or a Cancel for a previous Credit Reservation request.
41 = Failed - Transaction in Progress
This result code means that a request with this Transaction ID has already been received, and the processing is in progress.
This could be caused by a delay in responding to the original request and a re-send timer in the requesting system being set to
too small a value.
42 = Failed - Maximum Reservation Amount Exceeded
This result code indicates that a Credit Reservation request fails, because the amount to be reserved exceeds the maximum
allowed (as defined by the SurePay COSP data e-Commerce Maximum Reservation Amount).
43 = Failed - Cannot find last Recharge Event Record
This result code indicates that SurePay cannot find the last recharge Event Record in RERTDB when client sends Request
Debit (reverse last recharge) request to SurePay. This request shall be rejected with the result in this case.
44 = Failed - Exceed the validity period for recharge reversal
This result code indicates that time period has exceeded the provisioned valid period between the time of last recharge and the
time when Request Debit (reverse last recharge) request is sent to SurePay. This reversing last recharge request shall be
rejected with the result in this case.
45 = Account Data Truncated
This result code indicates that Account Data field in response of Request Balance has been truncated, since the total size of fields defined in
Account Query table for this request exceeded the size limit of Account Data field.
From V10SU11, this result code also be used in the Request Credit , Debit Amount and Debit Service Delivery.
68 = Failed - Chargeable Event Happened before Recharge Reversal

This result code indicates that one or more chargeable event happened between the time of last recharge and the time when
Request Debit (reverse last recharge) request is sent to SurePay. This reversing last recharge request shall be rejected with
the result in this case.
LDAP triggered SMS/MMS result codes
From V10SU6 SurePay allows LDAP Request Debit Service Delivery requests to be specifically treated by SurePay as real-

time SMS/MMS requests, determined by the Service Type. In these cases the requests will be handled by the SurePay real-
time SMS logic, rather than the generic eCommerce logic. Certain errors from the real-time SMS logic result in specific LDAP
result codes being returned, as defined below :
Realtime SMS release cause LDAP result code

Not Supported SMS Call 70
Maximum Simultaneous Calls Exceeded 71
SMS Screening Barred 72
Account Expired 73
Account Invalid 74
Account In Error 75
Account Not Found 02
Usage Limit Exceeded 57
Balance Too Low 35
Unmigrated Subscriber 76
Message Error 01
System Fail 99
From V10SU10 onwards, one release cause is added and result code is added.
Realtime SMS release cause LDAP result code
Out of Home Zone 77
80 = Invalid Token ID
This error code indicates the request failed because the provided Token Id could not be fund by Surepay in Token RTDB.
82 = Reject Call Due to Suspended Bundle
This error cord indicates the transaction is rejected because there is no available bucket applied for the call since such kinds
bucket is removed from SIM because of the suspended bundle.
83 = Reject Call Due to No Subscribed Bucket
This error cord indicates the transaction is rejected because there is not available bucket applied for the call due to such
bucket is not subscribed at all.
98 = Failure
This result code indicates the request is failed during applying the recharge amount to the subscriber's account.
99 = Internal Error
This error means that a request has failed because of an error internal to the SurePay service not fitting any of the other more
specific error types described above. For example, a failure encountered when reading an internal system database table.
Bundle Purchase Query result codes
From R27SU4, SurePay allows LDAP Request Balance requests to query a bundle purchase is allowed or not. Some specific
result codes will be returned as defined below:
Bundle Purchase Disallowed Reason LDAP result code

Bundle renewal of same group in progress 70 (Purchase not allowed)
Invalid bundle ID 61 (Invalid bundle ID)
Invalid Start Date 70 (Purchase not allowed)
Purchase not allowed for the COSP 70 (Purchase not allowed)
Subscriber activity barred for missing parent bundle ID 5 (Subscriber activity barred)
Insufficient balance for bundle purchase fee 35 (Insufficient funds)
Purchase not allowed for existing bundle 70 (Purchase not allowed)
No space for new bundle 70 (Purchase not allowed)
Purchse not allowed for discount mutually exclusive 70 (Purchase not allowed)
Purchase not allowed for neare expiry 70 (Purchase not allowed)
The following table defines which types of request can return which result codes:

(Serv ice Deliv ery)
Token O peration
Request Balance
Request Bundle
R equest Credit
R equest Credit
R equest Credit
R eserv e Credit
(Scratch Card)
Request Debit
Request Debit
Authen ticate
(Cr edit Card)
Subscription
Result Code
Subscriber
00 x x x x x x X x x x
03 x x x x x x X x x
06 x x x x x X x
07 x x x x X x x
08 x x x
09 x x
10 x
11 x
12 X
13 x
14 x
15 x
16 x
17 x x
18 x x x x x X x
19 x
20 x
21 x
22 x
23 x
24 x
25 x
26 x
27 x
28 x
29 x
31 x
32 x
33 x
34 x x x x x
35 x x X x
36 x
37 x x x x X x
38 x x x x X x
39 x
40 x
41 x x x x X x
42 x
43 X
44 X
45 x
46 x X
57 x
61 X
68 X
69 x
70 X
71~ 77 x
78 x x x
80 x
81 X
82 X X X
83 x X X
98 x x x
Note that for e-Commerce responses all errors from the Surepay application will be returned to the client in a successful
Search Response. The only unsuccessful Search Responses (which will include the LDAP resultCode parameter) shall come
from the MAS Platform directly (if any), not from Surepay. This is because the set of resultCode values defined by the LDAP
standard provides insufficient flexibility for the number of different application error types that are required for Surepay e-
Commerce.
Unless stated otherwise in this document, the client can assume that in the event that SurePay returns an application error
then all response parameters other than the resultCode shall be set to a null string.
2.1.7.1.2 Authenticate Subscriber

This request is used to check whether a particular subscriber id is a valid subscriber within the Surepay service and whether
they have e-Commerce enabled.
2.1.7.1.2.1 Interface Requirements

LDAP Search Request
The parameters sent in the LDAP Search Request shall be as follows:

baseObject "dview=<scp_id>_auth_sub" See General Requirements section

scope SingleLevel (1)
derefAliases neverDerefAliases (0) parameter not applicable
sizeLimit 0 (No size limit restrictions) MAS will only return 1 result
timeLimit 0 (No timelimit restrictions) MAS will respond within 4 seconds
attrsOnly 0 (FALSE) (attribute types and values) MAS will always return both names &
values
filter Choice equalityMatch[3] Must populate AttributeValueAssertion
attributes Empty, OR Empty = retrieve all attributes
Sequence of attribute names Seq = retrieve only a subset of attributes
AttributeValueAssertion AttributeType = "sid" sid = OCTET STRING(SIZE(100))
AttributeValue = <key attribute value> This is the table key field which shall be
composed of a concatenated string of
input parameters
The input information shall be "encoded" in the LDAP SEARCH request key as follows:
Subscriber ID (16 digits) Mandatory 0..9, A..F only

Provider ID (10 digits) Optional 0..9 only
Transaction ID (20 digits) Optional 0..9 only
Requesting System (14 digits) Optional 0..9 only
Merchant ID (16 chars) Optional Chars
Reference (40 chars) Optional Chars
COSReturn (3 chars)Optional Chars (V10SU8)
Each field shall be separated by the ":" character (colon). No padding characters are required and therefore no justification is
necessary. The parameter sizes above are maximums and fewer digits may be provided. If a parameter is optional then it may
be omitted, but the ":" separator is still required.
Notes: Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference supports 40 character string
If COSReturn is set to "YES" then the response shall include the COSP ID from the SIM RTDB.
LDAP Search Response
The parameters returned in the LDAP Search Response shall be as follows:

objectName "sid=<key attribute value>" All input parameters concatenated in the
original Search Request key will be
returned. See General Requirements for
e-Commerce section.
attributes: sequence of see below
AttributeType
AttributeValue
resultCode Failure code assigned by platform See [RFC1777]
A successful request shall cause two responses to be returned. The first Search Response shall include the objectName and
attributes parameters. The attributes parameter shall be a sequence of pairs of AttributeType and AttributeValue. The second
Search Response shall include only the resultCode set to "Success" (0).
An unsuccessful request shall cause a single Search Response including the resultCode containing the LDAP failure reason
assigned by the MAS platform.
The attributes returned in a successful LDAP Search Response shall be as follows:

Attribute Type Type Comments
res OCTET STRING(SIZE(2)) Application result code. As defined in
General Requirements for e-Commerce
section
cospid OCTET STRING(SIZE(15)) COSP ID from the SIM RTDB
2.1.7.1.3 Request Balance

This message is used to query a subscriber's balance. For mixed balance accounts both balances shall be returned. The
request includes the currency that the balance(s) must be returned in. For Postpaid subscribers the balance returned shall
always be zero. (This option is included for future expansion).
V10.9 onwards, This request is changed to include a new input field to indicate that the requesting system requires additional
subscriber data, and the response of the request will include the requested data.
R27SU4 onwards, this request is enhanced to include new input parameters to support rating logic and bundle purchase
query, and the response of the request may include the bundle purchase fee.

LDAP Search Request

baseObject "dview=<scp_id>_request_bal" See General Requirements section
values
input parameters

Transaction ID (20 digit) Optional 0..9 only
Currency Label (24 chars) Optional Chars
Balance Requested (1 digit) Optional 0..3 only
Balance Category (1 digit) Optional 0..1 only
International Indicator (1 digit) Optional 0..9 only
Connected DNList (330 chars) Optional 0..9, "#", "*", "," only
AccountDataGrpID (14 chars) Optional Chars
CounterInformation (1 char) Optional "Y" only
AddressList (490 chars) Optional Chars
Service Type (16 chars) Optional Chars
Content Type (16 chars) Optional Chars
Content Type List (170 chars) Optional Chars
Bundle ID (15 chars) Optional Chars
be omitted, but the ":" separator is still required (except for Balance Requested and Balance Category where the ":" may also
be omitted to maintain backward compatibility).
Notes: Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference supports 40 character string.
The valid values for the "Balance Requested" parameter are as follows:
0 = Default Balance
1 = Primary Balance
2 = Secondary Balance
3 = Both Balances (default)
If this parameter is not present then both balances shall be returned (if two balances are defined for this subscriber). Otherwise
just the single balance indicated shall be returned in bal1 result field.

The valid values for the "Balance Category" parameter are as follows:
0 = Actual Balance
1 = Balance Unallocated
If this parameter is not present then "0" is assumed. Normally these two values return the same amount. However, if there is a
call in progress at the SurePay SPA then it is possible that some credit has been allocated to the call in progress, but not used
yet. These settings have the following meaning:
"Actual Balance" is the actual amount of credit in the subscriber's account at the time the request is received. This is defined
as the Balance minus any credit already used by a call.
"Balance Unallocated" is the amount of credit in the subscriber's account minus any credit allocated to a call, but not used yet.
If a call is in progress this is the amount available for eCommerce debits. If a client system is using the Balance Request to
determine if the subscriber has sufficient funds for a subsequent debit then "Balance Unallocated" is the best option.
Note that in either case the Balance returned shall not include any credit that has been reserved.
The International Indicator defined in the interface is used to indicate if any number in the Connected DNList/AddressList is an
international number.
The Connected DNList/AddressList parameter is used to define the numbers/addresses to which the SMS/MMS will be sent.
Connected DNList parameter only can contain the up to 10 numeric phone numbers, the AddressList parameter can include up
to 10 email addresses or phone numbers.
These three parameters are used to check if any "IN message buckets" or "Non-International Buckets" are available for this
subscriber. If there is any IN message buckets available for this subscriber, beside the normal balance information, the return
message will contain indicator to indicate that.
If input parameter Counter Information is provisioned with "Y", then LDAP response shall include the UBD information and the
"distance" information in parameter CounterData in response, i.e. value between the UBD counters and the next threshold if
has.
If input parameter Counter Information is NULL, then no need to set information to output parameter CounterData in response.
If any of input parameters Service Type, Content Type, Content Type List is populated, rating logic can be applied to query
balance request for sufficient or insufficient balance check.
If input parameters Service Type, Content Type, Content Type List are populated, they will be used as the request service
type, content type for relevant logic handling, such as eCommerece rating control parameter retrieval, messaging bucket
selection, ect. Before this feature, 'ALL' is used as the content type, service type for query balance request.
Content Type List shall be made up of one to 10 Content Type values, each one corresponding to an element in the
Connected DNList / AddressList parameter, in sequential order. The valid values for Content Type List parameter are as
following:
- The ContentTypeList shall be a string of 1 to 170 characters, containing up to 10 separate Content Type values, each
separated by a comma.
- Each Content Type shall have up to 16 characters;
- Leading commas shall not be permitted;
- Training commas (at the end of the full list) shall not be permitted.
- Two consecutive commas (without a value between them) shall not be permitted.
If input parameter Bundle ID is not empty, the request balance will be used for bundle purchase validation query.
2.1.7.1.3.2 Dataview Definition


e-Commerce section.
AttributeType
AttributeValue
A successful request shall cause two responses to be returned. The first Search Response shall include the objectName and attributes
parameters. The attributes parameter shall be a sequence of pairs of AttributeType and AttributeValue. The second Search Response shall
include only the resultCode set to "Success" (0).
An unsuccessful request shall cause a single Search Response including the resultCode containing the LDAP failure reason assigned by the
MAS platform.

res OCTET STRING(SIZE(2)) Application result code. As defined in the General
Requirements for e-Commerce section
bal1 OCTET STRING(SIZE(15)) Subscriber's Primary Balance, presented as a string. May
include "." and up to 4 digits after the decimal point. May be
negative (prepended by "-").
bt1 OCTET STRING(SIZE(1)) Subscriber's Primary Balance Type.
0 = Prepaid, 1 = Postpaid
bal2 OCTET STRING(SIZE(15)) Subscriber's Secondary Balance (if supported), presented
as a string. May include "." and up to 4 digits after the
decimal point. May be negative (prepended by "-").
bt2 OCTET STRING(SIZE(1)) Subscriber's Secondary Balance Type.
cur OCTET STRING(SIZE(24)) Indicates the currency in which the subscriber's balance is
presented. This shall be the same as that present in the
original request. If no currency label was provided in the
original request then this shall be the currency label defined
for the subscriber in the Surepay SIM Table.
inov OCTET STRING(SIZE(1)) Indicates if this subscriber has IN Message Bucket or Non-
International Message Buckets.
Notes: "IN message Buckets" is a concept within a carrier.
When a subscriber who belongs to a specific carrier sends
an SMS to another subscriber who belongs to the same
carrier this kind of SMS can be called an "IN" message.
The "IN message buckets" feature is used to provide a
bucket capability for subscribers who send an "IN"
message.
ad OCTET STRING(SIZE Subscriber's additional data indentified by the
1600) AccountDataGrpID in the request.
cd OCTET STRING(SIZE Subscriber's all UBD counter information and "distance" for
1000) counter value to next threshold.
The field AccountData(ad) in response is encoded as "tag1=value1;tag2=value2«" where the tags are the abbreviated field tags of the
account date, and the values are the field values.
The tags are provisioned in Account Query(AQ) table.
* If the tag of a field is not provisioned, the AccountData field shall only include its value, e.g. if the 2nd field's tag is not provisioned,
the AccountData in the response of query is "tag1=value1;value1;..."
* If the value of a field is NULL and the tag of this field is provisioned, the encoding shall be, for example, "tag1=value1;tag2=;..."
* If the value of a field is NULL and the tag of this field is not provisioned, the encoding shall be, for example, "tag1=value1;;..."
* if neither the field name/variable nor the tag is provisioned, i.e. a NULL slot in AQ table, the Account Data field in response shall skip
this field, e.g. "tag1=value1;tag3=value3;..." in which the second slot is skipped
In case the value includes semicolon ";" or equal mark "=" or backslash "\", then it should be replaced with "'\;"' or "\=" or "\\" in the response,
e.g. "fieldname1=a;b" is encoded as "fieldname1=a\;b;...".
In case the concatenated query result exceeds the size limit of Account Data field, the result shall be truncated by only including the number
of query result fields not exceeding it in the response, e.g. if the total size of 1st 12 fields is 516 bytes while the total size of 1st 11 fields is 508
bytes, and the size limit of AccountData field is 512 bytes, then the result shall only include 1st 11 fields "...tag11=value11", and the result
code shall be set to 45 to indicate this
From V10SU11, the AccountData is extended to contain 1600 byte. When the query result exceeds the size limit, the above similar rule about
how to truncate need to be followed.
If the total length for the contents padding in Counter Data is exceed the max length, then service shall truncate the contents by only including
the complete query result not exceeding the size in the response, and the result code shall be set to 45 = Account Data Truncated to indicate
this.
If both PI and COSP data Allow Emergency Topup are True, then SIM Emergency Topup State shall be returned in LDAP query.
In this case, if subscriber's Emergency Topup State is '2'- Active or '3'- Opt-Out, then service shall also returned following field in response
message; otherwise, keep them NULL in response.
* Used Loan
* Remaining Loan
* Pending Service Fee
To calculate these value, the Original ETS Service Fee, Original ETS Loan Amount and Pending Service Fee need to be retrieved from
Counter RTDB with Counter Type “3 - ETS Loan Info”.
If the record cannot be found or Counter RTDB is not attached, LDAP requirement will return LDAP failure reason of 02 = Invalid subscriber
details.
2.1.7.1.4 Request Credit (Credit Card)

This message is used to request a recharge to a subscriber's balance using a credit card. The request may be sent from the
Service Gateway which has the eCash module or another back-office system which will have already processed the

transaction through the appropriate financial institution. If the Service Gateway or other client has not processed the credit
card transaction then Surepay will optionally make use of one of the credit card daemons. There are currently two options
supported within Surepay; BMI and Commercial. Surepay will use the subscriber's Class Of Service or the Default Credit Card
System to determine which system to use.
The request includes an indication of which balance is to be recharged. These requests can only be applied to PrePaid
balances. The transaction amount is always supplied.

LDAP Search Request

baseObject "dview=<scp_id>_cc_recharge" See General Requirements section
values
input parameters

Credit Card Number (16 digits) Mandatory 0..9 only
Credit Card Expiration (4 digits) Optional 0..9 only
Credit Card Issue No (1 digit) Optional 0..9 only
Credit Card Type (2 digits) Mandatory 0..9 only
Credit Card Auth Code (16 digits) Optional 0..9 only
Requires Processing (1 digit) Optional 0..1 only
Transaction Amount (15 chars) Mandatory 0..9, "." only
Balance Indicator (1 digit) Optional 0..2 only
PIN (18 digits) Optional 0..9 only
Credit Validity Period (4 digits) Optional 0..9 only (V10.7)
Notes :Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference support 40 character string.
Service Specific Data 1~4 (100 chars) Optional Chars (except for the listed four chars: " : ", " ' ", " \ ", and " $ ")
(V10.9)
The following table describes those input parameters not already described in the General Requirements for e-Commerce
section:
Credit Card Number Identifies the Surepay subscriber Credit Depending on a provisioned option, as an
Card number additional security measure Surepay can
reject the card number if it does not match
the credit card number defined in the
Surepay subscriber's SIM Table record.

If Requires Processing is 1 then the
number must be present in full. If
Requires Processing is 0 then a minimum
of 4 digits is required (the last 4 digits)
Credit Card Expiration Identifies the Surepay subscriber Credit If Requires Processing is 1 then the
Card Expiry Date. See below for the Expiration Date must be present. If
required format. Requires Processing is 0 then this
parameter may be omitted.
Credit Card Issue No Identifies the Credit Card Issue Number. Only some types of Credit Card require an
Issue Number. This field is currently not
used by Surepay and is present for future
expansion.
Credit Card Type Identifies the Credit Card Type. Surepay has the following card types:
01 = American Express
02 = Diners Club
03 = Eurocard
04 = Visa Card
05 = JCB
06 = Eurocheque
07 = Mastercard
08 = Discover
Values 09-99 may also be used, but are

not associated with a specific card type in
Surepay. May be set to "00" as a default.
Surepay uses this parameter to check for

the maximum recharge amount and
maximum cumulative recharge amount.
Credit Card Auth Code Identifies the Credit Card Authorization If Requires Processing is 1 then the Auth
Code. Code may be omitted. If Requires
Processing is 0 then this parameter must
be present.
Requires Processing Indicates if this transaction has already
been validated, or if the validation must be
done by Surepay. See below for more
information.
PIN Identifies the Credit Card PIN If present, must match the Credit Card PIN
stored in the subscriber's Surepay SIM
Table record.
Whether the PIN is mandatory is defined

within Surepay via data provisioned on a
Class of Servce basis.
The Credit Expiration Date is four digits in the format MMYY where MM must be in the range '1' to '12' and the YY must be in
the range '00' to '99'.
The 'Requires Processing' parameter indicates whether the credit card transaction has already been processed with a financial
institution. The values must be one of the following:
1 - Surepay must validate transaction. Card has not already been processed
0 - Card has already been processed, no validation required by Surepay
The default value is 1.


e-Commerce section.
AttributeType
AttributeValue

MAS platform.
Requirements for e-Commerce section.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the recharge was applied,
presented as a string. May include "." and up to 4 digits
after the decimal point. May be negative (prepended by "-").
presented. This shall be the currency label defined for the
subscriber in the Surepay SIM Table which may not be the
same as the currency label in the original request.
ava OCTET STRING(SIZE(3)) Indicates the number of available Recharge attempts for
the Subscriber before the subscriber's account becomes
barred. This parameter is only present for failed recharge
attampts.
This Optional parameter will only be populated in V10SU6

and later. SurePay must be correctly provisioned in order
for this parameter to be sent in order to maintain backwards
compatibility with earlier versions.
2.1.7.1.5 Request Credit (Scratch Card)

This message is used to request a recharge to a subscriber's balance using a scratch card (voucher). The request includes an
indication of which balance is to be recharged.

LDAP Search Request
The parameters to be sent in theLDAP Search Request shall be as follows:

baseObject "dview=<scp_id>_sc_recharge" See General Requirements section
values
input parameters

Scratch Card Number (16 digits) Mandatory 0..9 only
Scratch Card PIN (8 digits) Mandatory 0..9 only

Notes:Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference support 40 character string.
(V10.9)
section:
Scratch Card Number Identifies the Scratch Card Number Surepay determines from the scratch card
number whether the scratch card
database is internal to Surepay or
external, according to provisioned data.
The database shall be used to retrieve the

recharge amount and the PIN for
validation purposes.
Scratch Card PIN Identifies the Scratch Card PIN


e-Commerce section.
AttributeType
AttributeValue
MAS platform.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the recharge was applied,
presented as a string.
May include "." and up to 4 digits after the decimal point.
May be negative (prepended by "-").
ava OCTET STRING(SIZE(3)) Indicates the number of available Recharge attempts for
the Subscriber before the subscriber's account becomes
barred. This parameter is only present for failed recharge
attempts.


rec OCTET STRING(SIZE(15)) Scratch card value, presented as a string. May include "."
and up to 4 digits after the decimal point. This parameter is
included only if the recharge request was successful.

2.1.7.1.6 Request Credit

This message is used to request a credit of a given sum to a subscriber's balance. Examples would be returning goods
purchased through a store via POS or WAP. The request includes an indication of which balance is to be credited.
From R27.7, this messaged is used to credit the recipient when transfer funds between two subscribers.

LDAP Search Request
The parameters to be sent in the LDAP Search Request shall be as follows:

baseObject "dview=<scp_id>_sub_credit" See General Requirements section
values
input parameters

Transaction Amount (15 chars) Mandatory 0..9, '.' only
Credit Type (3 digits) Optional 0..9 only
Notes:Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference support 40 character strings
(V10.9)
The following settings of the Credit Type parameter are supported (if not present or set to any other value then no specific
meaning is defined and the request shall be treated as a generic credit request):

"100" = This is a request to reverse a previous debit request (e.g. a refund of a charge for a service that was unable to be
delivered to the subscriber). The only difference between this and a generic credit request is a different AMA event label is
used and SurePay will not treat a Reverse Transaction as a recharge, only a simple balance adjustent.
Credit Validity Period is only valid when Credit Type is not "100". (from V10.7)
From R27.7, the value "400" is added to indicate this request is to credit the recipient when transfer funds between two
subscribers
If the Credit Typ is "400", Reference can be used to carry the MDN of the donor. It may be a number or string like "DONOR=908-559-7549",
will be populated in AMA field "Enhanced Reference" directly.
AccountDataGrpID is an optional parameter. If this parameter is carried in the command, service needs to use this parameter
to access the Account Query data and return the data accordingly.


e-Commerce section.
AttributeType
AttributeValue
MAS platform.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the credit is applied, presented
subscriber in the Surepay SIM Table.
amg OCTET STRING(SIZE(32)) Indicates additional message returned by the Recharge
DG. May be presented as a currency amount (may include
"." as a decimal point) or set to "0".

cospc OCTET STRING(SIZE(5)) Indicates additional COSP Code returned by SurePay (note
this is different to the COSP ID).
This parameter will only be populated in V10SU8 and later.

SurePay must be correctly provisioned in order for this
parameter to be sent in order to maintain backwards
1600) AccountDataGrpID in the request.
2.1.7.1.7 Request Debit (Service Delivery)

This message is used to request a charge to be applied to a subscriber's balance. This request allows providers/merchants to
charge for services delivered to subscribers. The request can make use of one of the individual charging elements below or
combination of a number of them to determine the charge.

1. Merchant responsible for the service delivered.
2. Delivery services include GPRS, WAP ,SMSC or MMSC Incoming and Outgoing messages. Service type of Messages and
Packets are available to allow the charging of total messages/packets delivered across multiple delivery mediums such as
GPRS, WAP,SMSC or MMSC.
3. Content type such as weather info or football scores.
4. SMS and MMS (MO & MT) support.(V10SU6)
Surepay has no in built information regarding merchants, service types or contents types. This information is provided in the e-
Commerce request as identifiers which the service uses to access charging tables.
The charges can be defined as flat charge which is applied per message or packet, or a number of charge rates according to
previous usage. The usage is tracked per subscriber for individual merchant/service/content types. The provider can setup
charging grace periods allowing subscribers to receive free service for a given number of messages or time from when they
initially subscribe to a given service.
From R27SU4, new input parameter Content Type List is added to support per-content type rating.

LDAP Search Request

baseObject "dview=<scp_id>_sub_debit" See General Requirements section
values
input parameters

Number Of Items (6 digits) Mandatory 0..9 only
Balance Indicator (1 digit) Optional 0..2 only. From V10.9, "3" is also valid input.
Debit Type (3 digits) Optional 0..9 only
Dest Address (16 digits) Optional 0..9, A..F only
Content Value Type (16 chars) Optional Chars
Content Value (9 digits) Optional 0..9 only
Location Information Type (1 char) Optional Char
Location Information (41 chars) Optional Chars
Connected DNlist (330 chars) Optional 0..9, "#","*", "," only

be omitted, but the ":" separator is still required (except for the parameters Debit Type, Dest Address, Content Value Type,
Content Value, Location Information Type and Location Information, where the ":" may also be omitted if none of these fields is
provided to maintain backward compatibility).
From V10 SU9, the Location Information field can contain an IPv6 address, where ":" character is part of the IPv6 address
field. Service shall do some content sensitive parsing. If the filed is an IPv6 address, the format should like
"[FEBC:ABCD:0008:4567:FE98:0800:200C:417C]". The IPv6 address should be enclosed in "[" and "]", and the address
format must be "xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx", where 'x' is hexadecimal characters.
Notes:
1.Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference support 40 character strings
2.For LDAP SMS/MMS request, Number Of Items is not applicable, it will be ignored.
3. For LDAP SMS/MMS request, SurePay does not support Mixed Credit accounts, so the Balance Indicator field only supports
0 or 1.
(V10.9)

Content Type List (170 chars) Optional Chars
These three parameters are used to check if any "IN message buckets" or "Non-International Buckets" are available for this
subscriber.
Content Type List shall be made up of one to 10 Content Type values, each one corresponding to an element in the
Connected DNList / AddressList parameter, in sequential order. The valid values for Content Type List parameter are as
following:
- The ContentTypeList shall be a string of 1 to 170 characters, containing up to 10 separate Content Type values, each
separated by a comma.
- Each Content Type shall have up to 16 characters;
- Leading commas shall not be permitted;
- Training commas (at the end of the full list) shall not be permitted.
- Two consecutive commas (without a value between them) shall not be permitted.
The following settings of the Debit Type parameter are supported (if not present or set to any other value then no specific
handling is defined and the request shall be treated as a normal debit request).
"100" = This is a request for which the SurePay service shall calculate the charge for the requested service and return result codes as before,
but not debit the amount from the subscriber's account. The client can use this option to determine if there is sufficient balance to cover a
charge, but without knowing the actual amount to charge.
"200" = This is a request to charge interim multi-recipient MMS. This is handled exactly the same as other debits, but there will be no SIM
History entry created.
"201" = This is a request to charge final multi-recipient MMS. The only action taken for a request of this type is to generate a SIM History entry.
“300” = This is a request for which SurePay shall do the Green Zone check only and skip rating and debit for the late delivered SMS-MT.
section:

Service Type Identifies the Service Type for the The combination of Merchant ID, Service
delivered service Type and Content Type is used to define
the per item charge, via Surepay Rating
tables.
The Service Type is checked in the

SurePay eCommerce Service Type table
(EST). If no match is found SurePay does
not indicate an error. Processing will
continue.
From V10SU6 the Service Type may be

used to specify (via the EST table) that the
request is to handled as LDAP-triggered
SMS/MMS.
Content Type Identifies the Content Type for the The combination of Merchant ID, Service
tables.
The Content Type is checked in the

SurePay eCommerce Content Type table
(ECT). If no match is found SurePay does
continue.
Number of Items Identifies the number of items to be
delivered
Debit Type Identifies a particular type of debit. This The only valid value defined for Debit Type
allows special handling of this debit is "100","200","201". Any other value shall
request be ignored and the request treated as a
normal debit request.
Destination Address Destination Number (e.g. if charge being Required in E164 international format.
applied for short message). Allows
SurePay to vary charge based on the If present in the LDAP request, but no
Destination Zone. match is found in SurePay data then this
field shall be ignored.
Content Value Type Identifies the type of value defined by the If present, the Content Value Type and
Content Value parameter. Content Value can be used in combination
to vary the charge applied. For example,
this allows SurePay to support content
size or volume based charging.
If Content Value Type is present, but the

Content Value parameter is not present
then Surepay will return the error "Invalid
or Missing Parameters".
If the Content Value Type provided does

not match data provisioned at SurePay in
the Range Mapping (RM) table then
Surepay will return the error "Invalid or
Missing Parameters".
Content Value The meaning depends on the Content If Content Value is present, but Content
Value Type. Value Type parameter is not present then
Surepay will attempt to use a default
This can be used, for example, to define Content Value Type. If no default is
the size of the eCommerce service available then Surepay will return the error
provided (e.g. a Download in KBytes). "Invalid or Missing Parameters".
Location Information Type Identifies the type of value defined by the If present, the Location Information Type
location Information parameter. and Location Information can be used in
combination to vary the charge applied.
0 Location Number For example, this allows SurePay to
1 Geographic support location based charging.
2 VLR Number
3 Location Info Number If Location Information Type is present,
4 Cell ID LAI but the Location Information parameter is
5 SGSN Address (GT format) not present then Surepay will return the
6 SGSN IP Address error "Invalid or Missing Parameters".
Location Information type in BOLD shall if the Location Information Type is SGSN
be supported in V10SU6. In the initial IP Address. the Location Information shall
release only Location information based be usual notation format. e.g for IPv4
on VLR address shall be supported in address, it shall be dotted decimal
SurePay notation format. e.g 192.168.0.1,
otherwise, Surepay will return the error

service logic (Location Information Type = "Invalid or Missing Parameters". For IPv6
2, 5, 6). The LDAP interface supports the address, it should be enclosed in "[" and
other types indicated above for future "]", and the address format must be
expansion. The VLR address from "xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx",
external client shall be provided in E.164 where 'x' is hexadecimal characters.
format.
Location Information Location Information is defined by If Location Information is present, but

Location Infomation Type parameters. Location Information Type parameter is
not present then Surepay will return the
error "Invalid or Missing Parameters".
If present the Location Information will be

included in the AMA record.
International Indicator Indicate if any numbers in the Connected
DNlist/AddressList contain one
international number
Connected DNList Carry the numbers which the MMS/SMS
will be sent to.
AccountDataGrpID Carry the Account Query ID, which is used
to access the Account Query table to get
the subscriber's data.
AccountDataGrpID is an optional parameter. If this parameter is carried in the command, service needs to use this parameter to access the
Account Query data and return the data accordingly.


e-Commerce section.
AttributeType
AttributeValue
MAS platform.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the debit is applied, presented
amt OCTET STRING(SIZE(15)) Indicates the amount charged (or calculated only,
depending on the Debit Type parameter) in the currency
indicated by the "cur" attribute for the request presented as
a string. May include "." and up to 4 digits after the decimal
point. This parameter shall also be populated (together with
the currency) if the result code is "Insufficient Funds".
inov OCTET STRING(SIZE(1)) Indicate if this subscriber has IN Message Bucket or Non-
International Message Buckets

(1600)) AccountDataGrpID in the request.
2.1.7.1.8 Request Debit

This message is used to request a debit of a given sum from a subscribers balance. Examples would be purchasing goods
through a store via POS or WAP. The request includes an indication of which balance is to be debited.
From 27.7, this message will be used to debit the donor when transfer funds between two subscribers.

LDAP Search Request

baseObject "dview=<scp_id>_sub_debit_amt" See General Requirements section
values
input parameters

Transaction Amount (15 chars) Mandatory 0..9, "." only
Balance Indicator (1 digit) Optional 0..2 only. From V10.9, "3" is also valid input.
Connected DNList (330 chars) Optional 0..9, "#","*", "," only
Notes:Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference support 40 character strings
(V10.9)
Debit Type (3 digits) Optional 0..9 only
AccountDataGrpID (14 chars) Optional Chars (V10SU11)

These three parematers are used to check if any "IN message buckets" or "Non-International Buckets" are available for this
subscriber.
The following settings of the Debit Type parameter are supported (if not present or set to any other value then no specific
handling is defined and the request shall be treated as a normal direct debit request).
"300" = This is a request for which SurePay shall reverse the last recharge during the valid period. i.e. debit the last recharge amount and
remove the last recharge bonus (e.g. credit, buckets) recorded in the Recharge Event RTDB and SIM RTDB for the subscriber.
"400" = This is a request to debit the donor when transfer funds between two subscribers. International Indicator Connected
DNList/AddressList should be ignored(format check for these fields is needed) if the debit type is "400".
AccountDataGrpID is an optional parameter. If this parameter is carried in the command, service needs to use this parameter
to access the Account Query data and return the data accordingly.
section:
Debit Type Identifies a particular type of debit. The only valid value defined for Debit
This allows special handling of this Type is "300". Any other value shall
debit request be ignored and the request treated as
a normal debit request.
From R27.7, a new value "400" is
added to debit the donor when
transfer funds between two
subscribers.


e-Commerce section.
AttributeType
AttributeValue
MAS platform.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the debit is applied, presented
inov OCTET STRING(SIZE(1)) Indicate if this subscriber has IN Message Bucket or Non-
International Message Buckets

resamt OCTET STRING (SIZE(15)) The reversing amount from last recharge event after the
debit is applied (only for debit type is '300', presented as a
string. May include "." and up to 4 digits after the decimal
point.
(1600)) AccountDataGrpID in the request.
2.1.7.1.9 Credit Reservation

This message is used to request an amount to be reserved from a subscriber's balance. It allows the eCommerce client to do
the following:
1. Request an amount (determined by the client system) be reserved from the SurePay subscriber's balance.
2. Request the execution of an eCommerce debit request against a previously reserved amount (this might require the service
to debit or credit an amount from/to the balance depending on whether the reserved amount was sufficient or not).
3. Cancel a previously reserved amount and return the amount to the subscriber's balance.

LDAP Search Request

baseObject "dview=<scp_id>_res_credit" See General Requirements section
values
input parameters

Transaction ID (20 digit) Mandatory 0..9 only
Merchant ID (16 chars) Optional chars
Reference (40 Chars) Optional Chars
Number Of Items (6 digits) Optional 0..9 only
Balance Indicator** (1 digit) Optional 0..2 only. From V10.9, "3" is also valid input.
Reservation Request Type (1 digit) Mandatory 1..4 only
Amount (15 chars) Optional 0..9, "." only
Expiry Period (6 digits) Optional 0..9 only
Dest Address (16 digits) Optional 0..9, A..F only
Content Value Type (16 chars) Optional Chars
Content Value (9 digits) Optional 0..9 only
be omitted, but the ":" separator is still required (except for the fields Dest Address, Content Value Type and Content Value
where the ":" may also be omitted if none of the fields is provided to maintain backward compatibility).

** Note that the Balance Indicator is ignored if the Reservation Request Type is "Execute Debit Against Reserved Credit" or
"Cancel Reserved Credit". SurePay always uses the balance from which the reserved amount was originally deducted.
Notes:Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference supports 40 character string.
(V10.9)
section:
Service Type Identifies the Service Type for the The combination of Merchant ID, Service
tables.
The Service Type is checked in the

SurePay eCommerce Service Type table
(EST). If no match is found SurePay does
continue.
Content Type Identifies the Content Type for the The combination of Merchant ID, Service
tables.
The Content Type is checked in the

SurePay eCommerce Content Type table
(ECT). If no match is found SurePay does
continue.
Number of Items Identifies the number of items to be This is only used if SurePay needs to
delivered calculate the amount to charge.
If Surepay needs to use it, but it is omitted

then the value 1 is assumed.
Reservation Request Type Identifies the Request Type, as follows: For "Execute Debit", Surepay must be
1 = Reserve Credit - Fixed Amount able to determine the amount either from
2 = Execute Debit against Reserved the Amount parameter or the combination
Credit of Number of Items, Merchant ID, Service
3 = Cancel Reserved Credit Type and Content Type.
4 = Reserve Credit - Calculate Amount
For "Reserve Credit - Calculate Amount",
Surepay must be able to determine the
amount from the combination of of
Number of Items, Merchant ID, Service
Type, Content Type, Destination Address,
Service Content Type & Content Value.
Amount Identifies the amount of money to be Amount is specified in currency and may
reserved from or charged to the indicated include an optional "." and up to 4 decimal
balance. places after the ".". This parameter is
mandatory if the Request Type is 1
("Reserve Credit").
If the amount is present for "Execute

Debit" request type it will always be used,
i.e. SurePay shall not calculate the amount
to debit.
If Request Type is "Reserve Credit -

Calculate Amount" then any value
provided in this parameter shall be ignored
because SurePay always calculates the
amount to reserve in this case.
Expiry Period Identifies the period of time (in minutes) The credit will expire when the SurePay
when the reserved amount will expire, if audit first runs on or after this period has
not previously used. expired.
This parameter is mandatory if the

Request Type is 1 ("Reserve Credit").
This parameter is also mandatory if the

Request Type is 4 ("Reserve Credit -

Calculate Amount").
This parameter is ignored for other request

types.
Destination Address Destination Number (e.g. if charge being This is only used if SurePay calculates the
applied for short message). Allows amount to charge.
SurePay to vary charge based on the
Destination Zone. Required in E164 international format.
If present in the LDAP request, but no

match is found in SurePay data then this
field shall be ignored.
Content Value Type Identifies the type of value defined by the This is only used if SurePay calculates the
Content Value parameter. amount to charge.
If present, the Content Value Type and

Content Value can be used in combination
to vary the charge applied. For example,
this allows SurePay to support content
size or volume based charging.
If Content Value Type is present, but the

Content Value parameter is not present
then Surepay will return the error "Invalid
or Missing Parameters".
If the Content Value Type provided does

not match data provisioned at SurePay in
the Range Mapping (RM) table then
Surepay will return the error "Invalid or
Missing Parameters".
Content Value The meaning depends on the Content This is only used if SurePay calculates the
Value Type. amount to charge.
This can be used, for example, to define If the Content Value is present, but the
the size of the eCommerce service Content Value Type parameter is not
provided, in KBytes. present then Surepay will attempt to use a
default Content Value Type. If none is
available then Surepay will return the error
"Invalid or Missing Parameters".


e-Commerce section.
AttributeType
AttributeValue
MAS platform.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the credit reservation, execution
or cancellation is applied, presented as a string. May

amt OCTET STRING(SIZE(15)) Indicates the amount reserved, charged or cancelled (in the
currency indicated by the "cur" attribute) for the request
presented as a string. May include "." and up to 4 digits
after the decimal point.
diff OCTET STRING(SIZE(15)) This field only applies for execution of debits against a
reserved amount. This indicates the difference between the
amount reserved and the actual amount charged presented
as a string. May be prepended by "-" and include "." and up
to 4 digits after the decimal point.
A negative amount will indicate an amount refunded to the

subscriber's balance. Otherwise this will indicate the
additional amount charged to the subscriber's balance.
lost OCTET STRING(SIZE(15)) This field only applies for execution of debits against a
reserved amount. This field indicates an amount of credit
which was lost as a result of this transaction. This can
occur in the following circumstances :
• The debit amount was greater than the reserved amount
• There was insufficient balance to cover the whole of the
additional debit amount required
• SurePay is provisioned to not allow Outstanding Charges
The value shall be presented as a string and may include
"." and up to 4 digits after the decimal point.

Note. Ideally the client system should ensure that the

above scenario never occurs by using one of the following
methods:
1. Set the SurePay COSP Table parameter "Minimum

Balance for Credit Reservation" to ensure there is always
sufficient balance available to cover any additional debit
amount.
2. Have the client ensure reserved amounts are over rather
than under-estimates, so the execute debit will normally be
refunding credit, not deducting more.
3. Use Request Balance to query the subscriber's balance
before reserving credit.
4. Allow SurePay to create Outstanding Charges.
2.1.7.2 eCGS LDAP Interface

2.1.7.2.1 Request Top Up
The Request Top Up dataview is used for the external system to send the recharge request through eCGS. The dataview is
used in the following cases.
1. IVR Credit Card Recharge/Bank Account Recharge/Scratch Card Recharge by using Telus CCHS, Telus BACHS, or Telus
SCMS.
2. Automatic Recharge for Regular Interval, Low balance, including Audit Report recharge
3. WWW/WAP Credit Card Recharge/Bank Account Recharge/Scratch Card Recharge

Subscriber ID string(16), 0..9, A..F only Mandatory
Transaction ID string(20), 0~9 only Mandatory
Requesting System string(14), 0..9 only Optional Mandatory
Balance Indicator string(1), 0~2 only Optional
0 = Default
1 = Primary
2 = Secondary
Tariff Plan ID string(15) Optional
Validity Days string(5) , 0..9 only Optional
Bank Account Numbers string(16) Optional

Bank Routing Number/Bank Transit Number string(4) Optional
Bank Branch Number string(16) Optional
Card Type string(1), 0~2 only Mandatory
0 = Scratch Card
1 = Credit Card
2 = Bank Account
Recharge Amount string(15), 0-9, "." only Mandatory
Originated Type string(1), 0~ 4 5 only Mandatory
0 = IVR
1 = WWW/WAP
2 = Audit TCP/IP Top Up
3 = Audit Report
4 = Post Call Top Up
5 = Bundle Renewal Top Up
6 = Immediate Top Up
Reference (V10.5) string (40) Optional
(V10.9)
The following table describes those input parameters:
The output information shall be encoded as follows:
Result Code string(2) Mandatory
Current Rate string(10), 0-9 or "." only Optional
Current Expiration Date string(8),0~9 only Optional
Format is ddmmyyyy
Maximum Local Airtime Minutes string(10), 0-9 or ":" only Optional
Current Balance string(1016), 0..9 or "." only Optional
Next Scheduled Recharge Date string(8), 0~9 only Optional
Format is ddmmyyyy
The descriptions for the output parameters are shown as below:
Output Parameters Meaning Comments
Result Code LDAP response result from
SurePay
Current Rate The current call rate determined Current Rate is in Currency.
by the SurePay service logic The Input Convert Type use
Normal.
Current Expiration Date The credit expiry date for the

subscriber
Maximum Local Airtime The current local call length The format is HH:MM:SS. If
Minutes based on the current rate the call is free, the format shall
be 88:88:88
HH – the number of hours
MM – the number of minutes
SS – the number of seconds
Notes: if no second information,

the zero shall be filled. E.g. 3:5
should be filled as 3:5:0.
Current Balance The value of the current balance Current Balance is in Currency.
The Input Convert Type use
Normal.
Next Scheduled Recharge Date The next scheduled automatic
Top Up date for automatic Top
Up operation

The service shall define a dataview as follows:

req_top_up table {owner}
record {
subscriber_id_etc string(1000) {key, name=sid}
result_code string(2) {name=res}
current_rate string(10) {name=cur_rate}
current_expire_date string(8) {name=cur_expire}
maxi_local_airtime string(10) {name=maxi_time}
current_balance string(16) {name=cur_bal}
next_recharge_date string(8) {name=next_date}
}
2.1.7.2.2 Request Automatic Top Up Parameter Setting

The Request Automatic Top Up Parameter Setting dataview is used to set the automatic recharge parameter through WWW or
WAP.

Subscriber ID string(16), 0..9, A..F only Mandatory
Transaction ID string(20), 0-9 only Mandatory
Requesting System string(14), 0-9 only Mandatory
Funds Source string(1) , 0-9 only Mandatory
0 = Credit Card
1 = Bank Account
Recharge Amount string(15), 0~9, "." only Mandatory
Auto Top Up Threshold string(15), 0~9, "." only Mandatory
Low Balance Auto Top Up Status string(1), 0~1 only Mandatory
0 = Yes
1 = No
Interval Auto Top Up Status string(1), 0~1 only Mandatory
0 = Yes
1 = No
Reference(V10.5) string(40) Optional
Service Specific Data 1~4(R26SU7) string (100 chars) Optional Chars (except for the listed four
chars: " : ", "' ", " \ ", and " $ ")
Recharge Amount for Low Balance ATU(SP27.5) string(15), 0~9, "." only Optional
Regular ATU Alignment Option(SP27.5) string(1), 0~1 only Optional
0 = Immediate top-up.
1 = Aligned top-up
Bundle Renewal Auto Top Up Status string(1), 0~1 only Optional
0 = Yes
1 = No
For Service Specific Data 1~4, those value will be filled in AMA field Service Specific Dat 1~4 accordingly for the
corresponding AMA records.

Subscriber ID The unique value to identify It can be MSISDN
the subscriber.
Transaction ID The unique value to identify

the LDAP transaction
Requesting System It indicates the external

system.
Fund Source It indicates the source of

funds used for Automatic
Recharge.
Recharge Amount It indicates the recharge Recharge Amount is in
amount value Currency.

Auto Top Up Threshold It indicates the automatic Auto Top Up Threshold is
recharge threshold. in Currency
Low Balance Auto Top Up It indicates whether the end
Status user want the automatic
recharge for low balance.
Interval Auto Top Up Status It indicates whether the end
user want the automatic
recharge for regular
interval.
Reference An character string. This If present, this parameter
content shall be
of this string is of no included in AMA record.
significance to This field will contain the
Surepay. value of the
Additional Info parameter in
the
eCGS XML interface, if this
is used.
Service Specific Data 1~4 A character string, used to Those value will be stored
carry service specific data in AMA fields Servicde
sent from the client system. Specific Data 1~4
accordingly for each
corresponding AMA
records.
Recharge Amount For Low It indicates the recharge Recharge Amount For Low
Balance ATU amount value for low Balance ATU is in Currency
balance automatic top-up.
Regular ATU Alignment It indicates whether Recharge Amount shall be
Option immediately recharge, used for the immeidate
and/or align the regular recharge.
auto top-up with CED.
Bundle Renewal Auto Top It indicates whether the This is type of ATU is
Up Status bundle automatic renewal independent of Regulat
can trigger the automatic ATU and Low Balance
top up for the subscriber. ATU.
The output information shall be encodede as follows:

Next Scheduled Recharge Date string(8), 0~9 only Optional
Format is ddmmyyyy
The descriptions for the output parameters are shown as below:
Output Parameters Meaning Comments
Result Code LDAP response result from
SurePay
Next Scheduled Recharge Date The next scheduled automatic
Top Up date for automatic Top
Up operation

req_auto_top_up table {owner}

record {
next_recharge_date string(8) {name=next_date}
}
2.1.7.2.3 Request Feature Package

The purpose of this dataview is used for the external system to send the FEature Package related request through eCGS.
The dataview is used in the following cases: Feature_Package_By_Balance, Feature_Package_By_Card,
Activate_Feature, Renew_Subscription, Upgrade_Subscription, Toggle_Automatic_Renewal, Query_Account_Information.

Subscriber ID string(16) Mandatory
Requesting System string(14), 0..9 only Mandatory
Feature/Package ID string(15) Optional
Operation Type string(1), 0~9,A only Mandatory
0 = Feature_Package_By_Balance
1 = Feature_Package_By_Card
2 = Subscribe_Bundle
3 = Stop_Bundle_Auto_Renewal
4 = Renew_Subscription
5 = Upgrade_Subscription
6 = Toggle_Automatic_Renewal
7 = Query_Account_Information
8 = Remove_Bundle
9 = Toggle_Bundle_Renewal_ATU
A = Extend_Bundle_End_Time
Originated Type string(1), 0~1 only Mandatory
0 = IVR
1 = WWW/WAP
Automatic Renewal Flag string(1), 0~1 only Optional
0 = Not Allow
1 = Allow
Upgrade To Feature ID string(3) Optional
Reference(V10.5) string(40) Optional
Service Specific Data 1~4 string(100) Optional
Start Date(V10SU13) string(8) (yyyymmdd) Optional
End Date(V10SU13) string(8) (yyyymmdd) Optional
FF Number 1~3 (V10SU13) string(24) Optional
Discount Percentage(R26SU7) string(5), 0~100 only optional
Balance Indicator (R27.4) string(1),0~2 only optional
0 = Default
1 = P - Primary balance.
2 = S - Secondary balance.
Channel ID (R27.4) string(20), chars, optional
Allow Suspended Bundle (R27.4) string(1), 0~1 only optional
0 = Not Allow
1 = Allow
Merchant ID (R27.4) string(16), chars, optional
Allow Bundle Renewal ATU(R27.5) string(1), 0~1 only Optional
0 = Not Allow
1 = Allow
Old Bundle ID (R27.5) String(15) Optional
Start Time (R27.5) string(4) Optional
End Time (R27.5) string(4) Optional
Operation Parameter (R27.5) string(8) Optional
Special Note on field - Service Specific Data 1~4 (100 chars) , Optional Chars (except for the listed four chars: " : ", "
' ", " \ ", and " $ ") (V10.9)
For Discount Percentage, it is used to carry the number of percentage, the valid range is from 0 to 100, and could to have up
to two digits after the decimal point.
From R27.4, if the operation type is 2 = Subscribe_Bundle, 3 = Stop_Bundle_Auto_Renewal, 8 = Remove_Bundle or A =
Extend_Bundle_End_Time(from R27.5), then the value of Feature/Package ID must be carried, in case the value is not
carried, then the result code "01 = Invalid or missing parameters" will be returned.
Input Parameters Meaning Comments
Subscriber ID The unique value to identify It can be MSISDN
the subscriber.
Transaction ID The unique value to identify For IVR related operation,
the LDAP transaction the Transaction ID is the
same as the TCP/IP
Transaction ID

Requesting System It indicates the external
system.
Feature/Package ID It identify the Feature ID
(e.g. in Renew
Subscription, Upgrade
Subscription operation) or
the Feature Package ID
(e.g. purchase Feature
Package operation)
Operation Type There are several operation
type supported in this LDAP
data view.
Originated Type It indicate where the LDAP
transaction is originated.
Automatic Renewal Flag This flag indicate the user's
option on whether allow
automatic renewal.
Upgrade To Feature ID This field is used as the mandatory for Upgrade
Upgrade To when perform Subscription.
upgrade subscription
Reference An character string. This If present, this parameter
content shall be
of this string is of no included in AMA record.
significance to This field will contain the
Surepay. value of the
Additional Info parameter in
the
eCGS XML interface, if this
is used.
Start Date Indicate the subscription in format yyyymmdd

start date
End Date Indicate the subscription in format yyyymmdd

end date
FF Number 1~3 Indicate the FF number in

national format to be stored
in SIMFF RTDB
(promotional FF list)
Discount Percentage Indicate the discount value value from 0 to 100 only
that will be applied to the
bundle purchase fee.
Balance Indicator Used to indicate which
balance (i.e. default,
primary or secondary) to be
used for charge
Channel ID Used to indicate the This field can be used to
channel ID for this indicate the source of the
operation and have 20 request. This value is
Characters length. included in the “Enhanced
Reference” field in the AMA
record.
Allow Suspended Bundle Used to indicate whether
the bundle can be
purchased in suspend state
when balance is
insufficient.
Merchant ID Identifies the Merchant If present, this parameter
providing the service. shall be included in any
AMA record created by
Request Feature Package
request.
Allow Bundle Renewal ATU Identify whether the

purchased bundle can
trigger the automatic top up
for the bundle automatic
renewal.

Old Bundle ID Change bundle from old If this parameter is present
bundle id to new bundle. It when Operation Type is "2
is used to identify this is a = Subscribe_Bundle", this
change bundle operation. operation is to change
bundle from old bundle to
new bundle.
The output information shall be encodede as follows:

Subscription ID 1 string(3) Optional
Subscription ID 1 Expiration Date string(8), 0~9 only Optional
Format is yyyymmdd
Format is yyyymmdd
Format is yyyymmdd
Format is yyyymmdd
Format is yyyymmdd
Format is yyyymmdd
Format is yyyymmdd
Format is yyyymmdd
Format is yyyymmdd
Format is yyyymmdd
Subscription ID 1~10 Name string(20) Optional
Subscription ID 1 Status string(1), 0~5 only Optional
1 = Active
2 = Active_No_Renewal
3 = Inactive
4 = Inactive_No_Renewal
(0 and 5 currently reserved. IMR677441)
Current Balance string(16), 0-9, or "." only Optional
Current Rate (10 digits), 0..9 or "." only Optional
Maximum Local Airtime Minutes (10 digits), 0..9 or ":" only Optional

Feature ID 1 - 6 same as Subscription ID
Feature ID 1 - 6 Status string(1), 0~7 only (IMR677441) Optional
0 = No operation
1 = New purchase
2 = Renew
3 = Mutually Exclusive
4 = No Subscription Slot
5 = Renew not allowed
6 = New purchase No Auto Renew
7 = Feature Expiry
Feature ID 1 - 6 Expiration Date same as Subscription ID Expiration Date
Feature ID 1 - 6 Name string(20) Optional
Bundle ID string(15) Optional
Bundle Name string(20) Optional
Promotional Tariff Plan 1~5 string(15) Optional
Promotional Tariff Plan 1~5 Status string(1), 0-8 only Optional
0 - Pending
1 - Subscribed
2 - Expired
3 - Promotion Expired
4 - Active No Renewal
5 - Suspend
6 - Maintain
7 - Inactive No Renewal
8 - Initial
Promotional Tariff Plan 1~5 Expiration Date string(8), 0-9 only (yyyymmdd) Optional
Promotional Tariff Plan 1~5 Name string(20) Optional
Bundle Status sting(1), 0-8 only Optional
0 - Pending
1 - Subscribed
2 - Expired
5 - Suspend
6 - Maintain
8 - Initial
9 - Pre-Purchased
Bundle Renewal ATU Status string(1), 0-1 only Optional
0 - Not allowed
1 - Allowed
The following table describes those output parameters:
Output Parameter Meaning Comments
Result Code LDAP response result
Subscription ID 1~10 Existing subscription of a
subscriber.
Subscription ID 1~10 Name Existing subscription name Maybe used for notification
of a subscriber to end-user.
From SP27.8, if the

Operation Type is "8 =
Remove_Bundle", and the
result code is partial
success, the bundles which
is not removed will be filled
in these parameters.
Subscription ID 1~10 Existing subscription End
Expiration Date Date of a subscriber
Subscription ID 1~10 Existing subscription Status
Status of a subscriber
Current Balance Used to notify end-user Current Balance is in
current balance when Currency. The Input
operation completed. Convert Type use Normal.
Maximum Local Airtime Used to notify the end-user The format is HH:MM:SS. If
Minutes of the local voice call the call is free, the format
minutes in default rate. shall be 88:88:88

HH - the number of hours
MM - the number of
minutes
SS - the number of
seconds
Notes: if no second
information, the zero shall
be filled. E.g. 3:5 should be
filled as 3:5:0.
Current Rate Used to notify end-user of Current Rate is in Currency.
the default rate. The Input Convert Type use
Normal.
Feature ID 1- 6 The feature ids contained in
a Feature Package.
Feature ID 1 - 6 Status Used to notify the end-user
of the individual feature
situation contained in a
Feature Package.
Feature ID 1 - 6 Expiration Used to notify the end-user
Date of the individual feature
End Date contained in a
Feature Package.
Feature ID 1 - 6 Name Used to notify the end-user
of the individual feature
name contained in a
Feature Package.
Bundle ID The bundle ID, which is The input feature package
also the promotional tariff ID.
plan COSP ID that
contained in the bundle.
Bundle Name The bundle package name. Bundle package name
obtained from FP data
Promotional Tariff Plan 1~5 Existing promotional tariff
plan subscription.
Expiration Date plan subscription expiration
date.
Status plan subscription status.
Promotional Tariff Plan 1~5 Existing promotional tariff Tariff plan promotion name
Name plan subscription name obtained from TPD table.
Bundle Status The operated bundle
status.
Bundle Renewal ATU Used to indicate the bundle
Status status of Bundle Renewal
ATU whether it is allowed
or disallowed.

req_feature_package table {owner}

record {
subscription_ID1 string(3) {name=s1}
subscription_ID1_expire_date string(8) {name=d1}

subscription_ID1_status string(1) {name=t1}
subscription_ID1_name string(20) {name=n1}
Current_Balance string(16) {name=cb}
Current_Rate string(10) {name=cr}
Max_Airtime string(10) {name=mt}
feature_ID1 string(3) {name=f1}
feature_ID1_status string(1) {name=a1}
feature_ID1_expire_date string(8) {name=e1}
feature_ID1_name string(20) {name=m1}
bundle_ID string(15) {name=bi}
bundle_name string(20) {name=bn}
PTP_ID1 string(15) {name=p1}
PTP_ID1_status string(1) {name=u1}
PTP_ID1_expire_date string(8) {name=i1}

PTP_ID1_name string(20) {name=j1}
bundle_status string(1) {name=bs}
bundle_renewal_ATU_status string(1) {name=at}
}
2.1.7.2.4 Request Bundle Subscription

Starting from V10SU13, this dataview is moved into chapter "eCGS LDAP Interface" to enable the eCGS support.
This message is used to query subscriber details such as balance, credit expiry date, language, lifecycle state and bundle
subscription information. Bundle information includes details on promotional tariff plan(s), discounts, counters, etc.
This request is supported from Surepay V10SU6/R25SU2.
Note: The MAS platform supports LDAP requests up to a total size of 1024 bytes. In theory this limit can be exceeded for this
request type for subscribers with very extreme provisioning (the maximum number of bundles/discounts is used, parameters
are provisioned to maximum size, etc. The total request size can be calculated by adding the sizes for each attribute name
and value, including the key, and then add 10 bytes overhead for header information. Finally add 1 byte for every attribute
name and 2 bytes for every attribute value). In practise this extreme provisioning is not realistic and no problems are
anticipated. The LDAP message size limit will be increased in the near future.
From V10SU8 the LDAP message size limit is increased to 5K.

LDAP Search Request

baseObject "dview=<scp_id>_req_bundle" See General Requirements section
values
input parameters
The service shall be able to receive a request to query the subscriber balance with the following inputs.
Subscriber ID string (16) Mandatory 0..9, A..F only

Balance Requested string (1)Optional 0..3 only
Balance Category string (1)Optional 0..1 only
Request Type string(2) Optional digit string only
Request Index string(5) optional ('1'...'99999')
Query ID string(15) optional
be omitted.
The valid values for the "Balance Requested" parameter are as follows:
0 = Default Balance

1 = Primary Balance
2 = Secondary Balance
3 = Both Balances (default)
If this parameter is not present then both balances shall be returned (if two balances are defined for this subscriber). Otherwise
just the single balance indicated shall be returned in bal1 result field.
The valid values for the "Balance Category" parameter are as follows:
0 = Actual Balance
1 = Balance Unallocated
If this parameter is not present then "0" is assumed. Normally these two values return the same amount. However, if there is a
call in progress at the SurePay SPA then it is possible that some credit has been allocated to the call in progress, but not used
yet. These settings have the following meaning:
"Actual Balance" is the actual amount of credit in the subscriber's account at the time the request is received. This is defined
as the Balance minus any credit already used by a call.
"Balance Unallocated" is the amount of credit in the subscriber's account minus any credit allocated to a call, but not used yet.
If a call is in progress this is the amount available for eCommerce debits. If a client system is using the Balance Request to
determine if the subscriber has sufficient funds for a subsequent debit then "Balance Unallocated" is the best option.
Note that in either case the Balance returned shall not include any credit that has been reserved.
Note: For Actual Balance case, the return value shall deduct any corresponding Outstanding Charge amount if any is
applicable.
The valid values for "Request Type" is
0 = PTP/Bundle
1 = Discount
2 = Standard Discount
3 = Stepped Discount
4 = Usage Based Discount
5 = Recharge Bonus
6 = Bucket
7 = Class Bundle
If Request Type is 0 = PTP/Bundle, then service shall return the promotional tariff plan or bundle information in the response.
i.e. the bundle /Promotional Tariff Plan COSP ID, correspnding start/end date, start/end time if it has(from R27.5), status, FF
number. And discount information which included in each bundle.
If Request Type is 1 = Discount, then service shall return all the discount information in the response.
If Request Type is other value which is corresponding with the Discount Type in Discount Definition table, then service shall
only return all the discounts information for such specific discount type in the response.
From R27.9, if Request Type is 7= Class Bundle, both the bundles in the subscribers profile and the bundles in the Bundle List
RTDB could be queried.
By default, if the parameter is NULL, then service shall return the information as the previous behavior, i.e. only the SIM
information, SIM bundle 1~5 information, SIM Discount ID 1~10 information and corresponding FF numbers.
Note: When LDAP request bundle or discount information, there is other call or action which updates bundle or discount
information. Then the LDAP request results may miss some bundle/discount information or return redundent bundle/ discount
information.
The valid value for "Request Index" is counter value from 1 to 99999. The default value is “1” if the parameter is not present or
provisioned.
If the LDAP request is to request bundle information, then the value '1' indicate service shall only return the first bundle’
information. If subscriber has more bundles, then operator shall send LDAP request with Request Index as “2” to query the
second bundles, etc.
If the LDAP request is to request discount information, then the value '1' indicate service shall only return the first 10 discounts’
information. If subscriber has more discounts, then operator shall send the command with Request Index as “2” to query next
10 discounts, etc.
From R27.5, if the LDAP request is to request bundle information , the above requirement is applicable when Query ID is not
presented. If Query ID is presented, please refer to LDAP-6909, LDAP-6915, LDAP-6916.
From R27.9, if the LDAP request is to request Class Bundle, the above requirement is applicable when Query ID is not
presented. If there is a predefined Class ID for the bundle indicated by "Request Index" and COSP data Enable Bundle Pre-
Purchase is true, the service should return the bundles including both the one identified by the “Request Index” and the valid
ones (BL.Valid Flag is true) in the Bundle List RTDB which have the same Class ID. If the bundle identified by the “Query ID”
has no class id defined or COSP data Enable Bundle Pre-Purchase is false, the service should reject the request with result
code “59 = Invalid Bundle ID”. If Query ID is presented, please refer to LDAP-7229.

If the LDAP request is to request bundle information and "Query ID" is not null or "ALL", use "Query ID" as the bundle ID to
query all this bundle's related information of the subscriber.
If the LDAP request is to request bundle information and "Query ID" is provisioned as “ALL”, service will return selected
information for all bundles in the subscriber’s account.
The possible Result Code for this request should be with the following value (see Application Result Code section for all result
codes in e-Commerce LDAP Request):
00 = Success
This result code indicates the request was successfully processed.
01 = Invalid or missing parameters
This result code indicates the request failed because mandatory data was missing or data was present but in the wrong format
(e.g. included invalid characters).
02 = Invalid subscriber details
This error code indicates the request failed because the provided subscriber ID could not be found by SurePay in either then
SIM or UA tables.
52 = Success - More Records
This result code indicates the response is successfully returned, and also indicates that there is more information for the
request which is not included in this response message.
59 = Invalid Bundle ID
This result code indicates that can't find the specified bundle's information for the subscriber
99 = Internal Error
This error means that a request has failed because of an error internal to the SurePay service not fitting any of the other more
specific error types described above. For example, a failure encountered when reading an internal system database table.
From R26SU7, service supports more bundles or discounts per subscriber, so it is prossible that all the subscriber's bundle
information or discount information cannot be included in one response message.
1. Request Bundle Information with Subscriber ID, Request Index “1”, and Request Type “0” - bundle, then service shall return
1) Subscriber information, including Subscriber balance, balance type, SIM Expiration Date, Language Label, Currency Label,
Life cycle information, CED, Error Indicator, Home Zone etc
2) Return the first bundles’ information (could be kept in both SIM/Counter RTDB) (from R27.5, please refer to the note of
LDAP-6915 of how to set the start and end time of bundle.)
3) Return the PTP Tariff Plan COSP ID provisoined in FP table if has, FF numbers corresponding to the bundle if has, and 6
discounts’ information included in the bundle.
i.e. Discount ID 1~6 information in the response is for the bundle.
4) If subscriber has more bundles in following records, then service shall return with the new result code : Successful - More
Records; otherwise, if there is no bundle retrieved out in this query or no bundles in following records, then return with the
result 00- Successful.
5) If subscriber has more bundles, then operator can issue the LDAP request to get more bundle information with Subscriber
ID, Request Index “2”, and request Type “0” - bundle. Then service will return next one bundle, and so on.
Note: for Request Index is not “1”, the LDAP request will not include subscriber information in the response( specify in item (1)
above, i.e. only return bundle, FF number and discount information).
2. If only request Discounts information, then send LDAP request with subscriber ID, Request Index “1”, and request Type is
not '0', then service shall return
Life cycle information, CED, Error Indicator etc.
2) Return first 10 discounts’ information (all the subscriber level discount or all the discounts with specific discount type), kept
in SIM / Counter RTDB, including Discount 1~10 ID, status, start/end Date, Counter Value, Roll-over value, last usage
timestamp.
3) If subscriber has more Discounts besides first 10 discounts, then service shall return with the new result code: Successful -
More Records; otherwise, if there is no discounts retrieved out in this query or no discounts in following records, return with
the result 00- Successful.
4) If subscriber has more discounts, then operator can issue the LDAP request to get more discount information with
Subscriber ID, Request Index “2”, and request Type “1” - Discount, then service shall return next 10 discounts information and
so on.
Note: for Request Index is not “1", the LDAP request will not include subscriber information in the response, specify in item (1)
above and bundle information, i.e. only return Discount information.
From R27SU5, service supports to query bundle information by specified bundle id.
Request Bundle Information with Subscriber ID, Request Type “0” -bundle and Query ID(not "ALL"),
if the bundle id is found in the subscriber's account and there is an entry for it in FP table, the service shall return
Life cycle information, CED, Error Indicator, Home Zone etc

2) Return the specified bundles’ information (could be kept in both SIM/Counter RTDB), including Bundle ID, Bundle Start
Date, Bundle End Date, Bundle Status, Bundle Start Time(if has), Bundle End Time(if has), Cumulative Number of Renewal
etc.
3) Return the PTP Tariff Plan COSP ID provisoined in FP table if has, FF numbers corresponding to the bundle if has, and
discounts/buckets’ information included in the bundle.
i.e. Discount ID 1~6 information in the response is for the bundle.
4) service shall return with the result 00- Successful.
If the bundle id is not found in the subscriber's account or there is no according entry in Feature Package table, service should
return result code 59 - Invalid Bundle ID.
Note: the start time and end time of the bundle can be populated in Additional Info as HHMMHHMM, the first 4 characters are
for the start time of the bundle, left ones for the end time. And there are always 14 commas in the field to seperate it to 15
slots. Which slot can be populated should be sync with the other Bundle information's position.
From R27.5, service supports to query all bundles'(not including normal PTP) summary information.
Request Bundle Information with Subscriber ID, Request Type “0” -bundle, Request Index and Query ID with "ALL",
Up to 15 bundles from Request Index(default value is 1) can be returned in a single response, and only the following data
items shall be returned for each bundle:
Bundle ID
Bundle Status
Bundle Start Date
Bundle Start Time (null for non-24 hour bundles)
Bundle End Date
Bundle End Time (null for non-24 hour bundles)
Service should re-use some fields to support 15 sets of bundle information:

Dataview output real content
Promotional Tariff Plan COSP ID 1 ~ 5 bundle ID 1~5
Promotional Tariff Plan COSP ID 1 ~ 5 Start Date bundle 1~5 start date
Promotional Tariff Plan COSP ID 1 ~ 5 End Date bundle 1~5 end date
Promotional Tariff Plan COSP ID 1 ~ 5 Status bundle 1~5 status
FF Number 1~10 bundle ID 6~15
Discount ID 1 ~ 10 Start Date bundle 6~15 start date
Discount ID 1 ~ 10 End Date bundle 6~15 end date
Additional Info bundle 61~15 start& end time
Discount ID 1 ~ 10 Status bundle 6~15 status
Note: the format of Additional Info here is "HHMMHHMM,HHMMHHMM,...HHMMHHMM", the first 8 characters are for the start
and end time of the first bundle, followed by a comma. And then next bundle's start and end time plus comma, and so on. If
there is no start and end time for the bundle, just append a comma to seperate. There are always 14 commas in the field.
If subscriber has more bundles in following records, then service shall return with the result code : 52 - Successful - More
Records, and set Suggested Request Index as the start index of left bundles;
otherwise, if there is no bundles in following records, then return with the result 00- Successful and set Suggested Request
Index as "0".
If subscriber has more bundles, then operator can issue the LDAP request to get more bundles' information with Subscriber ID,
Request Index (can be set as "Suggested Request Index"), request Type “0” - bundle and Query ID with "ALL". Then service
will return next 15 bundles' information, and so on.
Note: for Request Index is not “1”, the LDAP request will not include subscriber information in the response.

req_bundle table {owner}
record {
PTP_ID1_start_date string(8) {name=ps1}
PTP_ID1_end_date string(8) {name=pe1}
PTP_ID1_status string(1) {name=pt1}

Discount_ID1 string(3) {name=d1}

Discount_ID1_start_date string(8) {name=ds1}
Discount_ID1_end_date string(8) {name=de1}
Discount_ID1_status string(1) {name=dt1}
Discount_ID1_counter string(19) {name=dc1}
Discount_ID1_unused string(19) {name=du1}

Bal_1 string(15) {name=b1}
Bal_1_type string(1) {name=bt1}
Bal_2 string(15) {name=b2}
Bal_2_type string(1) {name=bt2}
currency_label string(24) {name=cl}
expiry_date string(8) {name=ed}
tariff_plan string(15) {name=tp}
language_label string(24) {name=ll}
sim_state string(24) {name=ss}
life_expiry_1 string(8) {name=le1}
life_expiry_2 string(8) {name=le2}
credit_expiry_date string(8) {name=ced}
error_indi string(1){name=ei}
sim_froz string(1){name=sf}
FF_Number_1 string(24) {name=ff1}
......
FP_PTP_COSP_ID string(15){name=pt}
DIscount_ID_1_timestamp string(10){name=dtm1}
PTP_Renewal_ATU_1 string(1) {name=atu1}
Suggested_Request_Index string(5) {name=sri}
Additinal_Info string(140) {name=ai}
Cumulative_Number_Of_Renewal string(3) {name=crn}
Home_Zone string(15) {name=hz}
Pre_Purchased_Bundle_11 String(15) {name=pb11}
Pre_Purchased_Bundle_Date_11 String(8) {name=pbd11}
......
......
......
......
......
}


e-Commerce section.
AttributeType
AttributeValue
MAS platform.
Requirements for e-Commerce section
b1 OCTET STRING(SIZE(15)) Subscriber's Primary Balance, presented as a string. May
bt1 OCTET STRING(SIZE(1)) Subscriber's Primary Balance Type.
b2 OCTET STRING(SIZE(15)) Subscriber's Secondary Balance (if supported), presented
bt2 OCTET STRING(SIZE(1)) Subscriber's Secondary Balance Type.
cl OCTET STRING(SIZE(24)) Indicates the currency in which the subscriber's balance is
presented. This shall be the same as that present in the
original request. If no currency label was provided in the
original request then this shall be the currency label defined
for the subscriber in the Surepay SIM Table.
ed OCTET STRING(SIZE(8)) Indicates SIM expiry date. Format is DDMMYYYY
tp OCTET STRING(SIZE(15)) Indicates subscriber's default tariff plan.
ll OCTET STRING(SIZE(24)) Indicates subscriber's language.
ss OCTET STRING(SIZE(24)) Indicates current SIM life cycle state.
le1 OCTET STRING(SIZE(8)) Indicates life cycle expiration date for changing criteria as
"Life Cycle Expiry Date 1". Format is DDMMYYYY
le2 OCTET STRING(SIZE(8)) Indicates life cycle expiration date for changing criteria as
"Life Cycle Expiry Date 2". Format is DDMMYYYY
ced OCTET STRING(SIZE(8)) Indicates the date when credit is expired. Format is
DDMMYYYY
ei OCTET STRING(SIZE(1)) Indicates subscriber account status (SIM Error Indicator).
0 = Normal
1 = Inactive Usage Limit
2 = Inactive PIN Attempts
3 = Inactive Max Calls exceeded
4 = Inactive SMS Manual Action
5 = Balance Adjustments
6 = Deleted
7 = Inactive Consecutive calls
8 = Inactive Simultaneous Calls
9 = Suspended for PIN Attempts
A = Barred by HLR
sf OCTET STRING(SIZE(1)) Indicates whether subscriber is in frozen.
0 = False
1 = True

p1-p5 (5 OCTET STRING(SIZE(15)) Indicates promotional tariff plan 1 ~ 5 subscribed in
Attributes) subscriber profile.
ps1~ps5 (5 OCTET STRING(SIZE(8)) Indicates promotional tariff plan 1 ~ 5 Start Date in
Attributes) subscriber profile. Format is DDMMYYYY
pe1~pe5 (5 OCTET STRING(SIZE(8)) Indicates promotional tariff plan 1 ~ 5 End Date in
Attributes) subscriber profile. Format is DDMMYYYY
pt1~pt5 (5 OCTET STRING(SIZE(1)) Indicates promotional tariff plan 1 ~ 5 Status subscribed in
Attributes) subscriber profile.
0 - Pending
1 - Subscribed
2 - Expired
5 - Suspend
6 - Maintain
d1~d10 (10 OCTET STRING(SIZE(3)) Indicates discount 1 ~10 subscription.
Attributes)
ds1~ds10 (10 OCTET STRING(SIZE(8)) Indicates discount 1~10 subscription's Start Date. Format is
Attributes) DDMMYYYY
de1~de10 (10 OCTET STRING(SIZE(8)) Indicates discount 1~10 subscription's End Date. Format is
Attributes) DDMMYYYY
dt1~dt10 (10 OCTET STRING(SIZE(1)) Indicates discount 1~10 subscription's Status.
Attributes) 0=Preactive
1=Active
2=Active No Renewal (Active but not allow automatic
renewal)
3=Inactive
4=Inactive_P_Recharge
5=Inactive_P
6=Inactive No Renewal
dc1~dc10 (10 OCTET STRING(SIZE Indicates discount 1~10 subscription's current value e.g.
Attributes) (1019)) bucket value or UBD counter etc. Range 0..9999999999
0..9999999999999999999
du1~du10 (10 OCTET STRING(SIZE Indicates discount 1~10 subscription's carry-over value
Attributes) (1019)) (only applicable for bucket). Range 0..9999999999
0..9999999999999999999
ff1~ff15 (15 OCTET STRING(SIZE(24)) Indicates the 15 FF numbers asociated with the 5 bundles.
attributes) These parameters will only be populated in V10SU7 and
later.
pt OCTET STRING (SIZE(15)) Indicates the promotional tariff plan included in the bundle.
The data is only populated only when FC data Apply
Bundle Based on Feature Package is True.
dtm1~dtm10 (10 OCTET STRING (SIZE(10)) Included previous 10 discount ids' last usage timestamps.
attribute)
atu1~atu5 OCTET STRING (SIZE(1)) Indicates PTP subscription's status of bundle renewal ATU
is allowed or not:
0= not allowed
1=allowed
sri OCTET STRING(SIZE(5)) Indicate the index of left bundles
ai OCTET STRING(SIZE Indicate some additional information of the request
(140))
crn OCTET STRING(SIZE(3)) indicate the cumulative renewal times of “packaged” bundle
hz OCTET STRING(SIZE(15)) Indicate the subscriber’s home zone, if home zone is not
provisioned in subsriber's profile, Default Originating Zone
in GP table will be returned.
2.1.7.2.5 Request Voicemail Retrieval Charge

This message is used to notify SurePay to apply charge to a Voicemail Retrieval call requested from eCGS.

Subscriber ID string(16) Mandatory
Requesting System string(14), 0..9 only Mandatory
Status of Call string(1), 0..1 onlyMandatory

0 = Start of Call
1 = End of Call
Event Start Time string(10), Unix time Mandatory
Event End Time string(10), Unix Time Optional
Note: This filed is required when Status of Call is "End of Call"
Reference(V10.5) string (40) Optional
Service Specific Data 1~4(R26SU7) string (100), chars, Optional
Note: this field carry chars except for the listed four chars: " : ", "' ", " \ ",
and " $ ")
The output information shall be encoded as follows:
Result Code (string 2) Mandatory

req_vm_retr table {owner}

record {
}
2.1.7.3 Misc. LDAP interface

2.1.7.3.1 Generic LDAP interface
This interface is a general purpose LDAP interface of SurePay to provide following functionalities:
• In V10.9, Subscriber profile query; the requested subscriber profile could be any of the SIM RTDB fields (one or
more) as long as client follows the convention and with proper configuration on SPA. It may be extended for other
RTDB and SPA data query in later release.
• In V10.10, Action Execution, for example, authenticate 3rd party user and 3rd party PIN update.
• In V10.11, Execute an IMOM command.
• In V10.11, Retrieve subscriber's F&F number list from SSD RTDB, and SIM history from SH RTDB.
• In V10.11, Change subscriber's F&F number list, and apply charge if applicable.
• In V10.11, Provide announcement content according to the received notification event and other parameters.
• In V10.13, Query/Request/Update family group information accorss MAS, and family group heartbeat.
• In V10.15, Query contents of Counter RTDB
• In SP27.4, Query SIM RTDB+Counter RTDB, as well as active UBD/bucket name %DN, value %CV and the
distance to next threshold %NT.
• In SP27.5, Query SIMFF RTDB and VTX RTDB
2.1.7.3.1.1 Application Result Code

For all the generic LDAP NE query requests, the following result codes are used. Explanations of what the error indicates is
also included.
Note: The Platform Result code shall refer to the subsection Platform Result Code in section e-Commerce LDAP Requests.
00 - Success
This result code indicates the request/operation is successful.
01 - Invalid or missing parameter
This result code indicates that mandatory parameter is missing or data is present but in wrong format.
02 - Account Not Found/ Invalid subscriber details/ Record Not Found
This result code indicates that there is no account found with input parameter subscriptionID as account ID. If the operation is
query RTDB and the queried table is not the SIMRTDB, this result code indicates that there is no record in queried table with
the input key.

03 - Success - More Records Exist
This result code indicates the required data was successfully retrieved, but further records exist. The LDAP client can access
these by sending another LDAP query, incrementing the Sequence Number in the Tbl_Key parameter.
04- Record Not Found
This result code indicates that there is no record in queried table with the input key, which will be used for RTDB query except
for SIM RTDB.
05 - Not supported in Life Cycle state/ Subscriber activity barred
This result code indicates the request failed because:
* Activity is barred in the subscriber's current lifecycle state.
* Activity is barred because the subscriber's account is not yet activated.
* The subscriber's account has expired
06 - Card in use/ Barred Call in Progress
This result code indicates balance transfer is not allowed because of calls in progress.
08 - Balance limit Exceeded
This result code indicates a failure because the Recharge Amount would cause the subscriber's balance to exceed a
provisioned maximum limit.
13 - Invalid or missing PIN
This result code indicates that input parameter PIN doesn't match the account's 3rd party access PIN.
18 - Invalid balance
This result code indicates that the provided balance indicator is not allowed to do balance transfer. (This case is not support in
V10.10)
Also, this result code will be returned if there is no prepaid balance available for balance transfer.
35 - Insufficient balance
This result code indicates remaining balance of the account is not enough to fund the specified AMT.
too small a value.
45 = Account Data Truncated
This result code indicates that return data field in response of LDAP query RTDB data has been truncated, since the total size
of fields exceeds the size limit of return data field.
52 - Success - More Records Exist
This result code indicates the required data was successfully retrieved, but further records exist. The LDAP client can access
these by sending another LDAP query, incrementing the RecInd in the Tbl_Key parameter.
Note: this result code is used for Request Data for query Vortex RTDB.
71 - Maximum call exceeded for third party call
This result code indicates that maximum simultaneous call exceeded for the account.
72 - Parameters not Provisioned Correctly
This result code indicates that the parameters, e.g. fieldname in LDAP query RTDB data request, are not provisioned or the
coresponding paraemeter/variables are not provisioned correctly in SurePay rc table.
85 - Inactive PIN attempts
This result code indicates that the account's error indicator has been set to "Inactive PIN attempts" due to the Cumulative
Incorrect PIN Attempts exceeding the threshold.
86 - Third party access blocked
This result code indicates that 3rd party access is blocked for the account.
87 - Third Party Access Attempted From Incorrect Account
This result code indicates that the input parameter provider ID doesn't match the one in account data.

88 - Balance transfer Not allowed
This result code indicates that the account is not allowed to do balance transfer.
89 - System Error
This result code indicates that service was failed to debit/credit the account.
98 - Failure
This result code indicates the service was failed without a returned reason.
99 - Internal error
This result code indicates all the other errors which could happen. i.e. the request has failed because of an error internal to the
SurePay service not fitting any of the other more specific error types described above. For example, a failure
encountered when reading an internal system database table.
The following table defines which types of request can return which result codes:
Family Group Heartbeat

Request Family Group
Authenticate 3rd party
Authenticate Balance
LDAP Query RTDB data
Update Family Group

Query Family Group
Account Information
Account Information
Party P IN
Balance Transfer
Information
Result Code
Transfer
user
rd
Modify 3
00 x x x x x x x x x
02 x x x x X x x x
03 x
04 x
05 x X X
06 X X
08 X X
13 x x X X
18 X X
35 X X
37 X
38 X
41 x
45 x
52 x
71 X
72 x
85 X
86 X
87 X
88 x
89 x

The LDAP SEARCH key for this LDAP request will follow different pattern for different purpose. In general, the first name/value
pair appearing in the key shall always be "OP=x" to indicate the requested operation type. Here, 'x' can be one of the following:
• Q - Stands for query
• A - Stands for action
• U - Stands for update
• D - Stands for delete
For name=value pair (e.g, OP=A) in the key, name part is case insensitive. For example, both 'op=A' and 'Op=A' are legal. The
blank is ignored before or after the delimiter. e.g. 'op = A ;' is treated as 'op=A;'.
Without specification, variable part (input parameters after '#') in the LDAP SEARCH key shall be provided in name=value
format, and multiple values are joined with ','.
Parameter will be treated as not presented if there is no occurrence for the pair. If value is blank, service will think that the
parameter is presented with '' as the value.

For operation type A, U, without specification, following input parameters may appear after "OP=A(U)" and before '#' for
correlation and duplicate handling. Semicolon ';' is used as the delimiter.
• CREF - the call reference ID from requesting system, for example, Billing ID for IS826 call, call reference ID for CS1 call.
• PRTCL - the protocol used by the call on requesting system, not the protocol used by LDAP server.
• TID - Identification of the transaction.
• RID - Requesting system ID.
These parameters shall be used to replace parameters with the same name in variable part from V10 SU11.
Note: the parameter is still in name=value pair format. For example, OP=A;ACTION=BAL_TRANS;TID=<xx>;PRTCL=
<xx>;RID=<xx>;CREF=<xx>#...
1. There is no requirement on parameters' occurrence order, except that OP=x shall be first part of the request .
2. If the same name/label appear more than once in the LDAP request, then service shall reject the command by returning a
response with Result Code "01 - Invalid or missing parameters", generate an alarm with assert code 200 to describe the
situation/error.
3. If there are any unknown/undefined name/label in the LDAP requests, service shall ignore the unknown/undefined
name/label and value, and continue the processing.
LDAP Search Request
baseObject "dview=<scp_id> See General Requirements section
_request_data"
attrsOnly 0 (FALSE) (attribute types and MAS will always return both names & values
values)
AttributeValueAsserti AttributeType = "sid" sid = OCTET STRING(SIZE(1500))
on AttributeValue = <key attribute This is the table key field which shall be
value> composed of a concatenated
string of input parameters
2.1.7.3.1.2.1 LDAP Query RTDB data

LDAP Query Request
SurePay supports the LDAP NE query request to retrieve RTDB data, which has similar capability with the NE query in eSM.
The Query request shall have the following LDAP SEARCH key:
OP=Q;Tbl_Name=<RTDB Name>;Tbl_Key=<RTDB Key Value>;Field_Name=<Fieldname1,Fieldname2,.....,Fieldnamen>
From SP27.7, Last_Dial_Number_Flag will be added as LDAP SEARCH key. Only if Tbl_Name is SHRTDB, Last_Dial_Number_Flag is
meaningful.
The LDAP query request shall:
* Use semicolon " ; " as the delimiter for the different input parameters
* Use comma " , " as the delimiter for the different field name in the parameter "field_name". The blank is ignored before or after the delimiter.
* The key name (Label name) OP, Tbl_Name,Tbl_Key,Field_Name are case insensitive. e.g. both tbl_name and Tbl_Name are correct
when parsing. The value for each key shall be case sensitive.
* The total length of LDAP request is string(1500).
Example:
The LDAP request command could be
op=Q;tbl_name=SIMRTDB;tbl_key=7328631122;field_name=Class of Service ID,Currency Label,SCP Name,SIM State,Third Party Access
PIN,Error Indicator,Expiry Date,Language Label,SIM Credit Expiry Date
From V10SU15/R26SU7 SurePay supports the ability to retrieve data from the Counter RTDB. Note that there may be multiple records in this
RTDB. The response will indicate if this is the case and the client must send a separate request for each subsequent record.
The Query request shall have the following LDAP SEARCH key:
OP=Q;Tbl_Name=CTRTDB;Tbl_key=MSISDN:SubIndicator:CntType:ReservedKey:SeqNum;Field_name= <Fieldname1, Fieldname2, .....,

Fieldnamen>
Example 1:
op=Q;tbl_name=CTRTDB;tbl_key=
913305011:0:1:ALL:1;field_name=BundleID1,StartDate1,EndDate1,Status1,BundleID2,StartDate2,EndDate2,Status2,BundleID3,StartDate3,E
ndDate3,Status3
Example 2:
op=Q;tbl_name=CTRTDB;tbl_key=913305022:0:1:ALL:1;
From SP27.5, SurePay supports the ability to retrieve data from SIMFF RTDB, the Query request shall have the following LDAP SEARCH key:
OP=Q;Tbl_Name=SFFRTDB;Tbl_key=MSISDN:FF_type;Field_name= <Fieldname1, Fieldname2, ....., Fieldnamen>
Example 1:
op=Q;tbl_name=SFFRTDB;tbl_key=
913305011:0;field_name=FF1,MOC1,MTC1,MO_SMS1,MTC_SMS1,Home1,Roma1,FF2,MOC2,MTC2,MO_SMS2,MTC_SMS2,Home2,Roam
ing2
Example 2:
op=Q;tbl_name=SFFRTDB;tbl_key=913305022:0;
From SP27.5, SurePay supports the ability to retrieve data from VTX RTDB, the Query request shall have the following LDAP SEARCH key:
OP=Q;Tbl_Name=VTXRTDB;Tbl_key=DataSource:DataSourceType:RecInd;Field_name= <Fieldname1, Fieldname2, ....., Fieldnamen>
Example 1:
op=Q;tbl_name=VTXRTDB;tbl_key=913305011:1:;field_name=b1,b2,b3,b4,b5,b6,b7
Example 2:
op=Q;tbl_name=VTXRTDB;tbl_key=913305022:1:1;
Example 3:
op=Q;tbl_name=VTXRTDB;tbl_key=913305022:1:;
This table describes the input parameters of LDAP Query Account RTDB data request.
Input Require Type Meaning Comments

Parameter d
Tbl_Name Y String This parameter indicates The table name shall be
the RTDB name which is provisioned as one of the key
accessed in the LDAP fields in the rc table LDAP
request. Request Data Mapping.
From SP27.4,if the table name

is "PROFILE", then the service
need separately use
"SIMRTDB" and "CTRTDB" to
search RDM table.
Tbl_Key Y String This parameter indicates The key which is used to
the key which is used to access RTDB. From V10.9, for
access RTDB. SIM RTDB access the table key
shall be subscriber ID, i.e.
MSISDN.
For CTRTDB access, multiple

fields are required. See below
for details.
From SP27.4, if the table name

is "PROFILE", the Tbl_Key will
be the same as CT RTDB
access key.

Field_Name N String This parameter includes The field names (divided by
all the field names that comma) that need to be
needs to be retrieved from provisioned in the rc table
the RTDB. LDAP Request Data Mapping.
If Tbl_name is CTRTDB and

this parameter is not included
then all the information in the
CTRTDB record is returned.
From SP27.4, if the Tbl_name

is "PROFILE", then the Field
name can include the fields for
either SIM RTDB or CT RTDB.
Last_Dial_Nu N String This parameter whether Only if Tbl_Key is SHRTDB this

mber_Flag (1) the it needs output is last field is meaningful.
dialled number records in It indicates whether output
SHRTDB SHRTDB record should be last
dial number(entry type is 000,
direction is 1).
1- true
Others means false
The Tbl_key field shall support a combination of sub-fields used to specify the keys to the CTRTDB with “:” as delimiter, as follows:
* MSISDN: subscriber/account ID.

* SubIndicator: subscriber or account Indicator.
* CntType: define counting data type for this record
* ReservedKey: This is a reserved key.
* SeqNumber: sequence number. Valid value is from ‘1’ to ’9999’. The LDAP client shall start with sequence = 1 and increment by 1 for each
successive query used to read subsequent RTDB records.
(Please refer to the SurePay OA&M data definition guide for details of the supported values for each sub-field).
If the table name is "PROFILE", then SurePay can return subscriber's information in both SIM RTDB and CT RTDB with multiple records in
one response, the Tbl_Key has the same content/format as that for CT RTDB query and is shared for both SIM/CT RTDB searching, but the
query only supports SubIndicator as "0"(Subscriber) , CntType as "0" (Rating Counter) and "1"(PTP/Bundle) for CT RTDB searching.
otherwise, the query will be regarded as invalid and the service will response with result code as "02" or "04"(Refer req. LDAP-4145) without
any return data, to indicate that there is no record available.
Only MSISDN in the key is used for SIM RTDB searching.

The formal LDAP "PROFILE" query command format is
OP=Q;Tbl_Name=PROFILE;Tbl_key=MSISDN:SubIndicator:CntType:ReservedKey:SeqNum;Field_Name=<Fieldname1, Fieldname2, .....,
Fieldnamen>
There are different subkey value combination for the Tbl_key for query CT RTDB, which have following meaning.
If the SeqNum in the query command from client (e.g. UMF) is "1", then it is the origial query (compare with consequent query which maybe
needed in case there are too many records to be covered in one return message), in this case, the service logic should involve the SIM RTDB
searching. If the SeqNum is not "1", this query should be regarded as an consequent one, and only CT RTDB is searched.
If the command Tbl_key is provisioned as "MSISDN:0:0:All:1", the service logic should search all possible records of CT RTDB from the begin
record "MSISDN:0:0:ALL:1" to the record with the last sequence number "MSISDN:0:0:ALL:m"(Note1), then the service logic should continue
searching all possible records of CT RTDB from the record "MSISDN:0:1:ALL:1" to the record with the last sequence number
"MSISDN:0:1:ALL:n" (Note 2).
If the command Tbl_key is provisioned as "MSISDN:0:x:All:y"(x = 0/1; 1<= y <= n), then the service logic should search all possible records of
CT RTDB from the record "MSISDN:0:x:ALL:y" to the record with the last sequence number "MSISDN:0:1:ALL:n"(Note3).
For the first query, service can also accept a simplified command format with ONLY MSISDN provided (Use Case 1 is an example):
OP=Q;Tbl_Name=PROFILE;Tbl_key=MSISDN;Field_Name=<Fieldname1, Fieldname2, ....., Fieldnamen>
In this case, Surepay treats it the same as the complete format:
OP=Q;Tbl_Name=PROFILE;Tbl_key=MSISDN:0:0:All:1;Field_Name=<Fieldname1, Fieldname2, ....., Fieldnamen>
Note1: "m" indicates the last record for Rating Counter (Discount/Bucket) in Counter RTDB.
Note2: "n" indicates the last record for PTP/Bundle in Counter RTDB.
Note3: This command is used to query the rest records after which is defined by the Tbl_key.
If the table name is "PROFILE", the Field_Name in the command can cover any field in both SIM/CT RTDB, the service should use both
"SIMRTDB" and "CTRTDB" as a key to search related record in RDM data to find the Field Variable Name for a Fieldname, as well as the
owner RTDB of the Fieldname. If no Fieldname is from SIM RTDB, then the service will regard it as no field of SIM RTDB is requested and
SIM RTDEB will not be searched, on the contray, if no Fieldname is for CT RTDB, the service should regard it as all of the fields of CT RTDB
are requested, and CT RTDB should be searched.

Note for OAM: If the Provider want to return any Counter info in SIM, then at least one field name (e.g. MSISDN) should be presented for SIM
in Request Data Mapping.table.
In case any of FC data Keep More PTP/Bundles in Counter RTDB and Keep More Rating Counters in Counter RTDB is true, but the CT RTDB
is not attached, the service logic should return result code as 99 - Internal error,alarm message should be generated with assert code set to
305.
In case both FC data Keep More PTP/Bundles in Counter RTDB and Keep More Rating Counters in Counter RTDB are false, then the service
should only search SIM RTDB, no matter if the Tbl_key includes valid CT RTDB key or not.
If the table name is "SFFRTDB", Tbl_key field shall support a combination of sub-fields used to specify the keys with “:” as delimiter, as
follows:
* MSISDN: subscriber/account ID.
* FFtype: the number type, 0-normal, 1-promotional
If the table name is "VTXRTDB", Tbl_key field shall support a combination of sub-fields used to specify the keys with “:” as delimiter, as
follows:
* DataSource: the key value of the data required for Vortex, it can be one of the following:
- an Account ID
- a COSP ID
- a Tariff Plan ID
- a Provider ID
- the eCS/MAS ID
- Master Account ID
* DataSourceType: the type of the data source required for Vortex, it can only be with one of the following:
1 = Account ID
2 = COSP ID
3 = Tariff Plan ID
4 = Provider ID
5 = eCS/MAS ID
6 = Master Account ID
* RecInd: the first or second half record indicator for Vortex RTDB:
1 = The first half records of Vortex RTDB, i.e. the sequence number of 0~4 will be queried from VTX RTDB
2 = The second half records of Vortex RTD, i.e. the sequence number of 5~9 will be queried from VTX RTDB
Note for OAM: for UC application or CMI application, "Account ID" should be used query VTX RTDB.
LDAP Query Response

This table describes the returned result of LDAP Query Account RTDB data request.
Output Parameter Required Type Comments
Result Code (res) Y String (2) LDAP response result from
SurePay
Return Data (rd) N String (3000) The retrieved values for
corresponding fields in
LDAP query data request.
In V10.9, this LDAP query only supports to access SIM RTDB data. If the Tbl_Name is not "SIMRTDB", then SurePay shall only return result
code 01 - Invalid or missing parameters in the response and generate alarm message with assert code 200.
In V10 SU11, this operation supports query SSD RTDB data. Allowed Tbl_Name are "SIMRTDB", "SHRTDB" and "SSDRTDB".
From V10SU15/R26SU7, this operation supports the ability to query the Counter (CT) RTDB. Allowed Tbl_Name values are "SIMRTDB",
"SHRTDB", "SSDRTDB" and "CTRTDB".
From SP27.7, for SH RTDB query, if Last_Dial_Number_Flag is set to ture(1) then it should return last dial number(Entry Type is 000, direction
is 1).
From SP27.4, this operation supports query both SIM RTDB and CT RTDB, as well as related counter name, counter value and the distance
to next threshold, with Tbl_Name defined as "PROFILE".
From SP27.5, this operation supports query both SIMFF RTDB and Vortex RTDB with the Tbl_Name defiend as "SFFRTDB" and "VTXRTBD"
correspondingly.
SurePay shall access the RTDB with the input table Key to get the subscriber's record. If no record provisioned, the SurePay shall only return
error code 02 - Account Not Found/ Invalid subscriber details in the response.
From SP27.5, in case no record can be found for the input table key for RTDB query except for SIM RTDB, if the following FF record is
provisioned, then the service will return the result code "02" or "04" based on the value of Feature Status; otherwise, the result code "02" will
be returned:
Feature Identifier: "RTDB_Query_Result_Code_For__Record_Not_Found"
Feature Status: "02" or "04"
If the RTDB being queried is NOT the CTRTDB and the LDAP Request does not include the Field_Name parameter or no value for
Field_Name in the request, then SurePay only checks if the subscriber's record exists in RTDB with the input table key. If yes, then return the
result code 00- success without Return Data in the response; otherwise, return the error code "02" or "04"(Refer req. LDAP-4145) without
Return Data in the response.

From SP27.4,is requirement is changed to LDAP-6874 if Tbl_Name is "PROFILE".
From SP27.5, the requirement is changed to LDAP-6934 for Tbl_Name "SFFRTDB" or LDAP-6935 for Tbl_Name "VTXRTDB".
If the RTDB being queried is the CTRTDB and the LDAP Request does not include the Field_Name parameter or there is no value for
Field_Name in the request, then SurePay shall return all the data fields found. In this case, the Field Names used will be fixed, as follows:
Counter ID 1 ... Counter ID 6 = CID1 ... CID6
Counter Value 1 ... Counter Value 6 = CV1 ... CV6
Extra Counter Value 1 ... Extra Counter Value 6 = ECV1 ... ECV6
Time Value 1 ... Time Value 6 = TV1 ... TV6
Start Date 1 ... Start Date 6 = SD1 ... SD6
End Date 1 ... End Date 6 = ED1 ... ED6
Counter Status 1 ... Counter Status 6 = CS1 ... CS6
From SP27.4, this requirement is also valid for searching CT RTDB while Tbl_Name is "PROFILE".
From SP27.4, if the table name is "PROFILE", and the LDAP Request does not include the Field_Name parameter or no value for Field_Name
in the request, SurePay should only check CT RTDB and return all fields in CT CTRTDB. In case there is no any record exists in CR RTDB,
the service should continue to check SIM RTDB with MSISDN, if a record can be found, then return the result code 00- success, otherwise,
return the error code 02 - Account Not Found/ Invalid subscriber,without Return Data in the response.
From SP27.5, for the table name is "SFFRTDB", the SIMFF RTDB will be queried as following:
• If no record can be found with the input MSISDN and FFtype, then just return the result code "02" or "04"(Refer req. LDAP-4145) in the
response; From R27.8, if the COSP data Hold On FF Number Changes is true and no record can be found with both input (MSISDN and
FFtype) and (MSISDN and FFtype+2), just return the result code (IMR689298) "02" or "04"(Refer req. LDAP-4145) in the response.
• If <fieldnamenn> are carried in the Field_Name paramter, then the service will query the field from SIMFF RTDB following the req. LDAP-
4146. From R27.8, the FF Zone could also be queried. If the COSP data Hold On FF Number Changes is true, the service should also return
the value according to the <fieldnamen> in the potential record if the potential record exists. And “P” will be added ahead of the fields
corresponding to the potential FF numbers. For example, PFF1 means the potential FF1. PMOC1 means the MOC1 flag for potential FF1, etc.
The potential record should be retrieved with the input MSISDN and FFtype + 2. If the FF Zone is queried, only the value in the SIMFF with
FFtype indicated by the FFTYPE will be returned.
• If the LDAP request does not include the Field_Name parameter or no value for Field_Name in the request, then the service will return all the
correspodning data fields found in SIMFF RTDB for the corresponding FF number to be non-NULL. From R27.8, FF Zone should also be
returned if it's non-NULL. If the COSP data Hold On FF Number Changes is true, the service should also return all the corresponding data
fields found in the potential record for the corresponding FF number to be non-NULL. The potential record should be retrieved with the input
MSISDN and FFtype + 2. The field name in the response will be fixed as following order:
FF Number 1~20 = FF1~20
MOC Flag 1~20 = MO1~20
MTC Flag 1~20 = MT1~20
MO_SMS Flag 1~20 = MOS1~20
MT_SMS Flag 1~20 = MTS1~20
Home Flag 1~20 = H1~20
Roaming Flag 1~20 = R1~20
Prefix Match Flag 1~20 = P1~20
FF Home Zone = FFZONE(From R27.8)
Potential FF Number 1~20 = PFF1~20
Potential MOC Flag 1~20 = PMO1~20
Potential MTC Flag 1~20 = PMT1~20
Potential MO_SMS Flag 1~20 = PMOS1~20
Potential MT_SMS Flag 1~20 = PMTS1~20
Potential Home Flag 1~20 = PH1~20
Potential Roaming Flag 1~20 = PR1~20
Potential Prefix Match Flag 1~20 = PP1~20
The result code 00- success will be returned in case the queried field value can be found.
From SP27.5, for the table name "VTXRTDB", the Vortex RTDB will be queried as following:
• If no record can be found in Vortex RTDB with the input DataSource and DataSourceType, then just return the result code "02" or "04"(Refer
req. LDAP-4145) in the response.
• If <fieldnamenn> are carried in the Field_Name paramter, the value of RecInd will not be cared, and the field value will be quired from all
name-value paires of all available Vortex RTDB records with the key of DataSource and DataSourceType, the service will return the value of
Value n for those Name n exact match with the input <fieldnamenn> as the quired value for the input <fieldnamenn> ; NULL will be returned
for those input <fieldnamenn> which can not be exact match with Name n;
• If the LDAP request does not include the Field_Name parameter or no value for Field_Name in the request, the field name and the field
value in the response will be the corresponding value of Name n and Value n from VTX RTDB, and the service will return the name and value
pair found in VTX RTDB according to the value of RecInd as following:
• If RecInd is "1" or no value carried for RecInd, then all available name and value pairs from the Vortex RTDB record with the sequence
number to be 0~4 will be returned, the result code will be 00 - Success if no more name and value pairs in the record sequence number
5~9 or the the result code will be 52-Succes - More records exists if there are additional name and value pairs existed in the record
sequence number 5~9;
• If RecInd is "2", then all available name and value pairs from the Vortex RTDB record with the sequence number to be 5~9 will be
returned, and NULL will be returned in case no available name and value pairs, the result code will be 00 - Success;
• If RecInd has any other value, service shall reject the command by returning a response with Result Code "01 - Invalid or missing
parameters", generate an alarm with assert code 200 to describe the situation/error.
SurePay shall access SurePay Request Data Mapping table by input table name and each fieldname n (truncate 48 characters string from left
if the input fieldname n 's length exceeds string 48) to get the real Variable Field Name defined in SLL code, so as to return corresponding

value for each field.
If any record is not provisioned in the Request Data Mapping table, OR the corresponding Variable Field Name is not provisoned correctly (i.e.
not match the actual SLL variable name) then SurePay shall
*Send out alarm message with assert code 102 and including the table name and all the field names from LDAP request that are not
provisioned correctly
* Only include the valid field names if provisioned in Request Data Mapping table and corresponding values in the return_data according to the
format specified in following requirement LDAP-4140 in LDAP response.
* Return result code 72 - Parameters not Provisioned Correctly in the response.
If SurePay retrieves record from RTDB, then SurePay shall return the values for corresponding queried fields from RTDB directly.
The return data shall be in the format of
fieldname1=<val>;fieldname2=<val>;fieldname3=<val>;......fieldnamen=<val>
* "fieldname1~n" is the input field name in the LDAP request

* Use semicolon ";" as the delimiter for each name=value pair.
* If there are semicolon ";" or comma"," or equal mark "=" or slash "\" included in the value, then it should be replaced with '\;' or "\," or "\=" or
"\\" in the response, e.g. "fieldname1=a;b" is encoded as "fieldname1=a\;b;...".
* If the return_data exceeds the size limit (3000 characters), then the return_data shall be truncated by only including the number of query
result fields not exceeding the size in the response, and the result code shall be set to 45 to indicate this.(Note)
Note: From SP27.4, if the Tbl_Name is "PROFILE", the result code should set to 03 in this case.
Note: (feature 68832)when connection to eCGS, the configuration should ensure the comma"," and slash "\" is not included in the field value
as these are not allowed value at eCGS side.
* For the successful case, then return result code 00- Success and return data in response.
Example:
The return_data for querying the SIM RTDB could be:
Class of Service ID=FlatOne9000;Currency Label=dollar;SCP Name=scp1;SIM State=ACTIVE;Third Party Access PIN=;Error Indicator=
0;Expiry Date=20080801;Language Label=English;SIM Credit Expiry Date=20060530
From SP27.4, the return data format will have some enhancement specified for Tbl_Name is "PROFILE",
1. In Return Data, the RTDB name and searching Key should be provided in front of the set of fieldname for each record.
2. In each returned RTDB(SIMRTDB+ CTRTDB) record for rating counter (CntType = 0), with "Counter" acts as the Fieldname, all active
(Note) UBD/bucket name(%DN), value (%CV) and the distance to next threshod (%NT) should be provided with format "%DN,%CV,%NT", in
case any value for %DN,%CV,%NT is empty, "" should be used instead of the value. For
example,Counter="DN1,200,50";Counter="DN2,130,";Counter=",30,20";Counter=",160," are all possible content.
In case there is any call in progress, the counter value (as %CV) in CIPC should be returned.
Note:"active" here means the UBD/bucket status is "Preactive","Active" or "Active No Renewal".

In case the length of requested records doesn't exceed the size limit (3000 characters), all the information will be included in one response
(Return Data), and the Result Code shall be set to 00 - Success.
Following is an example for a query which the length of Return Data is within the limitation.
Use Case 1:
The original query:

OP=Q;Tbl_Name=PROFILE;Tbl_key=13912345678;Field_Name=<Class of Service ID, Currency Label, ....., SIM Credit Expiry Date>
The return code and return data,
Return code: 00 - Success

Return data:
SIM_Tbl_key=13912345678;Class of Service ID=FlatOne9000;Currency Label=dollar;SCP Name=scp1;SIM State=ACTIVE;Third Party
Access PIN=;Error Indicator=0;Expiry Date=20080801;LanguageLabel=English;SIM Credit Expiry Date=
20060530;Counter=DNa,50,10;Counter=DNb,200,100;Counter=DNc,200,0;CT_Tbl_key=13912345678:0:0:All:1;Counter ID1=B001;Counter
Value1=;Extra Counter Value 1=; Time Value1=;Start Date1=20070101;End Date1=20071221;Counter Status1=A;Counter ID2=B002; Counter
Value2=;Extra Counter Value2=; Time Value2=;Start Date2=20070501;End Date2=20081221;Status2=A;Counter= DN1,100,50;
CT_Tbl_key=13912345678:0:0:All:2;Counter ID1=B001;Counter Value1=;Extra Counter Value 1=; Time Value1=;Start Date1=20070101;End
Date1=20071221;Counter Status1=A;Counter ID2=B002; Counter Value2=;Extra Counter Value2=; Time Value2=;Start Date2=20070501;End
Date2=20081221;Status2=A;Counter= DN2,180,20; Counter=DN3,350,
In case the length of Return Data exceeds the size limit (3000 characters), the Return Data will only include the records not exceeding the
size in the response, and the result code shall be set to 03 - Success - More Records Exist.
The client (e.g.UMF) can send a consequent command with Tbl_key by increasing 1 to the SeqNum of last CT_Tbl_key in the Return data for
the continous query.
Following is an example of this scenario.
Use Case 2:
The original query,
Command: OP=Q;Tbl_Name=PROFILE;Tbl_key=13912345678:0:0:All:1;Field_Name=<Class of Service ID, Currency Label, ....., SIM Credit

Expiry Date>
The return code and return data,
Return code: 03 - Success - More Records Exist

Return data:
SIM_Tbl_key=13912345678; Class of Service ID=FlatOne9000;Currency Label=dollar;SCP Name=scp1;SIM State=ACTIVE;Third Party
Access PIN=;Error Indicator=0;Expiry Date=20080801;LanguageLabel=English;SIM Credit Expiry Date=
20060530;Counter=DNa,50,10;Counter=DNb,200,100;Counter=DNc,200,0;CT_Tbl_key=13912345678:0:0:All:1;Counter ID1=B001;Counter
Value1=;Extra Counter Value 1=; Time Value1=;Start Date1=20070101;End Date1=20071221;Counter Status1=A;Counter ID2=B002; Counter
Value2=;Extra Counter Value2=; Time Value2=;Start Date2=20070501;End Date2=20081221;Status2=A;Counter= DN1,100,50;
CT_Tbl_key=13912345678:0:0:All:2;Counter ID1=B001;Counter Value1=;Extra Counter Value 1=; Time Value1=;Start Date1=20070101;End
Date2=20081221;Status2=A;Counter= DN2,180,20; Counter=DN3,350,
The consequent command,
OP=Q;Tbl_Name=PROFILE;Tbl_key=13912345678:0:0:All:3;Field_Name=<Class of Service ID, Currency

Label, ....., SIM Credit Expiry Date>
When SurePay receive this command, the service will continue to search CT RTDB from 13912345678:0:0:All:3, untill the last record
13912345678:0:1:All:n is reached, or another more query is still needed. In this case, the rest record length does not reach the return data
limitation.The Ruturn Code is 00-Success, the whole query and response is done.
Return code: 00 - Success

Return data:
CT_Tbl_key=13912345678:0:0:All:3;Counter ID1=B001;Counter Value1=;Extra Counter Value 1=; Time Value1=; Start Date1=20070101;End
Date2=20081221;Status2=A;Counter= DN4,80,; CT_Tbl_key=13912345678:0:1:All :1; Counter ID1=B001;Counter Value1=;Extra Counter
Value 1=; Time Value1=;Start Date1=20070101;End Date1=20071221;Counter Status1=A;Counter ID2=B002; Counter Value2=;Extra Counter
Value2=; Time Value2=;Start Date2=20070501;End Date2=20081221;Status2=A
From V10SU15/R26SU7, if SurePay successfully returns data from the CTRTDB then the Result Code will indicate whether there are any
more records existing for the same Account ID.
* Result code 00 - Success will be returned if there is no further record in the RTDB.
* Result code 03 - Success - More Records Exist will be returned if further records do exist. The LDAP client can access these by sending
another LDAP query, incrementing the Sequence Number in the Tbl_Key parameter.
Example:
The return_data for querying the CTRTDB RTDB could be:
Counter ID1=B001;Counter Value1=;Extra Counter Value 1=; Time Value1=;Start Date1=20070101;End Date1=20071221;Counter Status1
=A;Counter ID2=B002; Counter Value2=;Extra Counter Value2=; Time Value2=;Start Date2=20070501;End Date2=20081221;Status2=A
(note that the meanings of the returned values, e.g. counter status values, are documented elsewhere).
No AMA generated for the LDAP request of querying RTDB data.
2.1.7.3.1.2.2 Authenticate 3rd party user

The service shall be able to receive a request to authenticate a 3rd party user with the following LDAP SEARCH key.
OP=A;ACTION=3RD_PARTY_AUTH#SubscriptionID=xxx,PIN=xxx,Provider_ID=xxx
"OP=A;ACTION=3RD_PARTY_AUTH#" shall be kept as it is, "xxx" shall be substituted with the proper value collected by the
requesting system.
Below table describes the variable part of LDAP SEARCH key.
Input parameter (Name) Required Type Comments
SubscriptionID Y String(16), 0~9, A~F only the user ID, card ID or
account ID, which SurePay
will used as key for
accessing account data.
PIN N String(18) the 3rd party PIN collected

by requesting system.
Provider_ID N String(10) This parameter is used to

indicate the service
provider that the 3rd party
access is valid for.
If Not populated then there

is no check for the service
provider.
Below table describes the output parameters of the request.

Output parameter Required Type Comments
Result Code Y string(2) LDAP response result from
SurePay
Return Data Y string(3000) Additional information
carried back to requesting
system.
If the user is authenticated successfully, SurePay shall use string "3RD_PARTY_AUTH" as the AccountDataGrpID input
parameter and SubscriberID as Subscriber ID input parameter to follow the same logic as "Request Balance" LDAP request
(all other input parameters for "Request Balance" are treated as not present).
If "Request Balance" logic fails, service will still return a success response for the action.
Following result of "Request Balance" logic will be joint with ',' and set to the "Return Data" output parameter of Authenticate
3rd party user LDAP request.
• balance_1
• bal_type_1
• currency_label
• acc_data
If the authentication failed, the above logic is skipped.
The balance_1 shall support long counter.

SurePay could return an application result code in below list:
00 - Success
This result code indicates the authentication is successful.

This result code indicates that mandatory parameter is missing or data is present but in wrong foramt.
02 - Account Not Found

This result code indicates that there is no account found with input parameter subscriptionID as account ID.
05 - Not supported in Life Cycle state/ Subscriber activity barred

This result code indicates the authentication failed because:
* The subscriber's account has expired

This result code indicates that input parameter PIN doesn't macth the account's 3rd party access PIN.
71 - Maximum call exceeded for third party call

This result code indicates that maximum simultaneous call exceeded for the account.
85 - Inactive PIN attempts

This result code indicates that the account's error indicator has been set to "Inactive PIN attempts" due to the Cumulative
Incorrect PIN Attempts exceeding the threshold.
86 - Third party access blocked

This result code indicates that 3rd party access is blocked for the account.
87 - Third Party Access Attempted From Incorrect Account

This result code indicates that the input parameter provider ID doesn't match the one in account data.
99 - Internal error
This result code indicates all the other errors which could happen.
2.1.7.3.1.2.3 Modification 3rd party PIN

The service shall be able to receive a request to update the subscriber’s third party PIN with the following LDAP SEARCH key.
OP=A;ACTION=MOD_3RD_PIN#SubscriptionID=xxx,OLD_PIN=xxx,NEW_PIN=xxx
"OP=A;ACTION=MOD_3RD_PIN#" shall be kept as it is, "xxx" shall be substituted with the proper value collected by the
requesting system.

Input Parameters (Name) Required Type Comments
OLD_PIN N String(18) OLD PIN of the subscriber.

NEW_PIN Y String(18) New PIN that will be
changed to. (Usually, it's
collected by requesting
system)
This request will have the same output parameter as the request of "Authenticate 3rd party user", the difference is that "MOD_
3RD_PIN" shall be used as the AccountDataGrpID input parameter of "Request Balance" logic if the PIN is updated
successfully.
If PIN update failed, the above logic is skipped.

SurePay could return an application result code in below list:
00 - Successful
02 - Invalid subscriber details
99 - internal error
Refer to the application result code of "Authenticate 3RD party user".
2.1.7.3.1.2.4 Authenticate Balance transfer

The service shall be able to receive a request to check whether the subscriber is allowed to do balance tranfer (acting as
source or target) with the following LDAP SEARCH key.
OP=A;ACTION=AUTH_BAL_TRANS#TID=xxx,RID=xxx,SubscriptionID=xxx,VERIFY_PIN=xxx,3RD_PIN=xxx,ROLE
=xxx,SOURCE=xxx,TARGET=xxx,AMT=xxx,CURRENCY=xxx,METHOD=xxx,LASTRP=xxx,SBALANCE=xxx,TBALANCE=xxx
"OP=A;ACTION=AUTH_BAL_TRANS#" shall be kept as it is, "xxx" shall be substituted with the proper value collected by the
requesting system.

Parameter TID and RID shall be moved before '#' in V10 SU11.
Input Parameters (Name) Required Type Comments
TID N String(20), 0~9 only Refer to eCommerce
Transaction ID part.
RID N String(14), 0~9 only Requesting System. Refer
to eCommerce Requesting
System.
VERIFY_PIN Y String(1) Indicates whether PIN
verification is required.
0 - Not require.
1- Required.
3RD_PIN N String(18) 3RD party PIN of the
subscriptionID. If present,
PIN verification will be
done.
ROLE Y String(1), T or S Indicates whether the
"subscriptionID" is target or
source during balance
transfer.
T - Target
S - Source
SOURCE N String(16), 0~9, A~F only Source account ID of the
balance transfer.

TARGET N String(16), 0~9, A~F only Target account ID of the
balance transfer.
AMT N String(15). Transfer amount in
currency from SOURCE for
the balance transfer.
May include "." and up to 4

digits after the decimal
point. (To be consistent
with other eCommerce
interface, it may be
negative, prepended by "-",
but balance transfer doesn't
support).
If not presented, it indicates

that all the balance from
SOURCE will be transfered
to TARGET.
If ROLE is TARGET, it shall

be populated.
CURRENCY N String(24). Currency Label for the input
amount.
All possible values to be

sent must be provisioned in
the
Surepay International
Currency (IC)
Table.
If not presented (''), it

indicates that the default
currency label in
SubscriptionID's profile will
be used.
METHOD N String(1) Indicates the balane

transfer menthod that can
be recorded in EDR.
1 = IMOM Balance Transfer

2 = IVR Balance Transfer
3 = IVR Scratch
Card/Calling Card
Recharge
4 = Automatic Balance
Transfer
LASTRP Y String(1) Indicate whether it is the

last reprompt for requesting
system.
0 - False
1- True
This request will have the same output parameter as the request of "Authenticate 3rd party user", the difference is that
"AUTH_BAL_TRANS" shall be used as the AccountDataGrpID input parameter of "Request Balance" logic if the
SubscriptionID is allowed to do balance transfer.
If SubscriptionID is not allowed to do balance transfer, the above logic is skipped.

This table describes the returned result of Authenticate Balance Transfer data request with enhancement.
Result Code (res) Y String (2) LDAP response result from
SurePay
Return Data (rd) N String (10) Mixed Credit (
0 - False
1- True)
Max_Balance_Exceed
(enum string: 0 - both, 1-
primary, 2 - secondary, 3 -

none)
Life_Cycle_Bar (enum
string: 0 - both, 1- primary,
2 - secondary, 3 - none)
Balance_Payment_Type_N
ot_Allowed (enum: 0 - both,
1- primary, 2 - secondary, 3
- none)
SurePay will return an application result code in below list:
00 - Success
This result code indicates that the account is allowed to do balance transfer.
05 - Not supported in Life Cycle state

This result code indicates that balance transfer is not allowed in the acount's current life cycle state.
06 - Card in use
This result code indicates balance transfer is not allowed because of calls in progress.
08 - Balance limit Exceeded

This result code indicates a failure because the Recharge Amount would cause
the subscriber's balance to exceed a provisioned maximum limit.maximum.
13 - Invalid PIN
This result code indicates the provided PIN doesn't pass the validation.
18 - Invalid balance
This result code indicates that the provided balance indicator is not allowed to do balance transfer. (This case is not support in
V10.10)
Also, this result code will be returned if there is no prepaid balance available for balance transfer.
35 - Insufficient balance
This result code indicates remaining balance of the account is not enough to fund the specified AMT.
88 - Balance transfer Not allowed

This result code indicates that the account is not allowed to do balance transfer.
99 - Internal error
This result code indicates other errors which could happen.
There is mixed credit support, result code 00- Success can cover the result code of 05, 08, 18 already. and 18 in the context should be only
applicable for stand-alone balance.
The return data shall be in the format of
<val1>;<val2>;<val3>;<val4>
2.1.7.3.1.2.5 Balance transfer

The service shall be able to receive a request to do balance tranfer for a subscriber (acting as source or target) with the
following LDAP SEARCH key.
OP=A;ACTION=BAL_TRANS#TID=xxx,RID=xxx,SubscriptionID=xxx,VERIFY_PIN=xxx,3RD_PIN=xxx,ROLE=xxx,S
OURCE=xxx,SBALANCE=xxx,TARGET=xxx,TBALANCE=xxx,AMT=xxx,CURRENCY=xxx,METHOD=xxx,LASTRP=xxx
"OP=A;ACTION=BAL_TRANS#" shall be kept as it is, "xxx" shall be substituted with the proper value collected by the
requesting system.
This request has the same input parameters with authenticate balance transfer request with following exceptions:
• VERIFY_PIN and 3RD_PIN shall always be omitted.
• SOURCE and TARGET are required.
• METHOD is required.
Also with the following more input parameters

This request will have the same output parameter as the request of "Authenticate 3rd party user", the difference is that
"BAL_TRANS" shall be used as the AccountDataGrpID input parameter of "Request Balance" logic if balance transfer

successes.
If balance transfer failed, the above logic is skipped.

Beside all the result code listed for "authenticate balance transfer" action, this action will also return the following result code:



too small a value.
89 - System Error
This result code indicates that service was failed to debit/credit the account.
Note: result code '00' indicates balance transfer is successful.
2.1.7.3.1.2.6 Execute IMOM command

The service shall be able to receive a request to execute an IMOM command with the following LDAP SEARCH key.
OP=A;ACTION=IMOM#<IMOM_Command>
"OP=A;ACTION=IMOM" is used to indicate that the operation is requesting an IMOM execution, <IMOM_Command> shall be
a valid IMOM command in SurePay.
Below table describes the output parameters of the request.
Result Code Y String(2) LDAP response result from
SurePay
Return Data N String(3000) Additional information
system.
The service will return result code - '00 - Successfull' if the IMOM command is executed successfully (STATUS is PASS).
Otherwise, result code '98 - Failure' will be used to indicate execution failure.
Return Data will contain the output message generated by IMOM command. Message format will follow the eSM format like
below:
EVENT=<SENDTEXT or TBL_UPD>;ID=<SMS Correlation Id>;STATUS=<PASS, INCOMPLETE or FAIL>;REASON=

<Command Output Message>;<Event Specific Information>
<SMS Correlation Id> will be filled with TID if presented. Otherwise, left as blank.
2.1.7.3.1.2.7 Update RTDB data

The service shall be able to receive a request to update RTDB data with the following LDAP SEARCH key.
OP=U;Tbl_Name=<RTDB Name>;Tbl_Key=<RTDB Key Value>;ALW_INST=<allow insert>;REASON=<Update
Reason>#<field1=value2,field2=value2...,fieldn=valuen>
From SP27.4, update as below:

OP=U;Tbl_Name=<RTDB Name>;Tbl_Key=<RTDB Key Value>;ALW_INST=<allow insert>;NumCheck=<number
check>;REASON=<Update Reason>#<field1=value2,field2=value2...,fieldn=valuen>
<RTDB Name> can be only "SSDRTDB" for V10 SU11.
Before SP27.4, only record update with SIMSD Special Destination Type set as "4 - Friends and Family List" is supported.
From SP27.4, SIMSD record update with any value of SIMSD Special Destination Type is supported.
Below table describes the input parameters of this operation.

Input Parameter Required Type Comments
Tbl_Name Y String The table to be updated.
the name shall be
provisioned as one of the
key in LDAP Request Data
Mapping data.
Tbl_Key Y String Key to be used for RTDB
access.
ALW_INST N String(1) Whether to allow insert a
0 - No new record if there is no
1 - Yes record for the Tbl_Key. If
not present, default value
0-No.
REASON N String(2). Update Reason. The
reason can be used to
06- F&F modification mapping to a feature type
08- LP Application for charging purpose.
Field 1~n N String Name of the field to be
updated. The name shall
be provisioned in LDAP
Request Data mapping
data. If no field is
presented, service will
make no changes to the
RTDB. If ALW_INST is '1 -
Yes' and no record found,
service will insert a record
with only Key field
populated.
Below table describes the output parameters of this operation.
SurePay
system.
Result code "'00' - Update Successful" shall be returned if the fields have been updated.
If Tbl_Name is not valid, result code "01 - Invalid or missing parameter" shall be returned.
If any of the specified field is not valid (can't found in LDAP request data mapping table or failed to set the value), result code
"72 - Parameters not Provisioned Correctly" shall be returned.
Otherwise, without specification, "99 - internal error" shall be returned.

If there is no record can be found with the specified key and ALW_INST is '1 - Yes', service will insert a new record into the
RTDB with Tbl_Key and field value from the request. Otherwise if ALW_INST is '0 - NO', result code "02 - Record Not Found"
shall be retured.
If update reason is specified, service will try to apply a charge for this operatioin first by mapping the update reason to one of
the allowed feature type in Feature Type Usage Type Conversion table, and apply the corresponding charging logic. If there is
no enough balance for the charge, result code "35 - Insufficent Balance" will be returned.
REASON - 06 will be mapped to one of the following feature type in FTUTC table according to whether the subscriber have
F&F modification or not (Friends_And_Family_Modified flag in subscriber's profile).
06 - First F&F Modification

07 - Subsequent F&F Modification
For SSDRTDB update, subscriber ID can be obtained from the Tbl_Key input parameter as specified in SurePay RTDB
definition.
Delimiter characters in field value shall be escaped by client as specified in "LDAP Query RTDB data" operation. Sevice will
remove the escape character before using.
2.1.7.3.1.2.8 Request Notification

The service shall be able to receive a request to send notification with the following LDAP SEARCH key.
OP=A;ACTION=REQ_NOTIFY;SubscriptionID=<SubscriptionID>;Scenario=<Notification Scenario>;Event=
<Event1,Event2,... Event n>#<field1=value1,field2=value2...,fieldn=valuen>
Below table describes input parameters of this operation.

Input Parameter Required Type Comments
SubscriptionID Y String(16) Subscriber that the
notification will be sent to.
Scenario Y String(16) Notification scenario as
allowed in NCOSP table.
Event Y String Notification event as
allowed in NCOSP table.
Multiple Notification events
are joined by ','.
Field 1 ~ n N String Additional data required for
the notification. The name
shall be provisoned in
LDAP Request Data
Mapping table together with
table name set as
"REQ_NOTIFY"
Below table describes output parameters of this operation.
SurePay
system. If the notification
requires an announcement,
this field will be used to
carry back announcement
content.
Following notification method are not supported by this operation.

• Redirection = 8
If configured method is not supported, the corresponding notification event is ignored.

Prompt and Collect is not supported by this operation.
For SMS and USSD notification, service will directly send it, and result code will be set to "00 - Successful" and Return_Data
set to "" if the notification has been sent.
For announcement, service will return announcement content in Return_Data with following encoding schema, and result code
will be set to "00 - Successful". Requestig system shall play the announcement based on it.
<Announcement1>,<Announcement2>,...,<Announcementn>
Each announcement will have the following format:
SID=<Service Point ID>;VP=<Variable Part>;VPT=<Variable Part Type>;F1=<Interruptable>

Parameter Required Type Comments
SID Y String(10) Service Point ID of the
announcement which will
be played. Shall be one of
the valid service point ID in
SurePay.
VP N String Variable part of the
announcement.
VPT N String(2) Type of Variable part. If VP
is presented, VPT shall
01 - Variable_Parts_Time also have a value.
02 - Variable_Parts_Date
03 - Variable_Parts_Price
04 - Variable_Parts_Integer
05 - Variable_Parts_Number
06 - Variable_Parts_Duration
07 - Variable_Parts_Volume
08 - VPT_None

F1 Y String(1) Used to indicate whether
0 - False the announcement is
1 - Ture interrupttable or not.
If any of the field is not valid (can't found in LDAP request data mapping table or failed to set the value) or notification
scenario/event can't be found in NCOSP table, result code "72 - Parameters not Provisioned Correctly" shall be returned.
For any other error occured during the request, service shall return with result code "98 - Failure". It's up to requesting system
to determine whether to continue it's service accordingly.
One or more announcemenst can be returned in Return_Data. If result_code is "00 - successful", requesting system shall
further check whether there is announcement to be played by checking Return_Data (is "" or not).
Delimiter characters in <variable part> and field value shall be escaped by '\' as specified in "LDAP Query RTDB data"
operation. Client will remove the escape character before using.
2.1.7.3.1.3 Dataview definition

objectName "sid=<key attribute value>" All input parameters concatenated in
the original Search Request key will
be returned. See General
Requirements.
AttributeType
AttributeValue
resultCode Failure code assigned by See [RFC1777]

platform
A successful request shall cause two responses to be returned. The first Search Response shall include the objectName and
attributes parameters. The attributes parameter shall be a sequence of pairs of AttributeType and AttributeValue. The second
Search Response shall include only the resultCode set to "Success" (0).
assigned by the MAS platform.
The attributes returned in a successful LDAP Search Response shall be as follows
res OCTET STRING(SIZE(2)) Application result code. As defined in
the General LDAP NE Query Interface
Section
rd OCTET STRING(SIZE(3000)) Corresponding information in the
response
2.1.8 LDAP Request Definitions with SurePay as Client

This section provides a detailed description of the complete set of external LDAP requests sent by the Surepay service to an
external server.
2.1.8.1 Digit Mapping Request

This Message is used to submit a Digit Mapping Request to the Digit Mapping Server. This request is used to map one digit
string to another. This may be used, for example, for ported subscribers where the DN requires mapping to a ported DN.
2.1.8.1.1 Interface Requirements

LDAP Search Request

baseObject "dview=<server_id>_DM_Req" See General Requirements section
sizeLimit 0 (No size limit restrictions) Server will only return 1 result

timeLimit 0 (No timelimit restrictions) Server expected to respond within a
predefined time (up to 10s)
attrsOnly 0 (FALSE) (attribute types and values) Server will always return both names &
values
AttributeValueAssertion AttributeType = "dig" dig = OCTET STRING(SIZE(16))
AttributeValue = <key attribute value> This is the table key field
The output information shall be "encoded" in the LDAP SEARCH request key as follows:
Original Digits (16 characters) Mandatory 0..9, A..F, *, # only
2.1.8.1.2 Dataview Definition


objectName "dig=<key attribute value>" <Key attribute Value> up to 100
characters may be returned here.
The server can optionally include the

dataview name as part of the objectName
response parameter after the original
digits (comma separated). For example:
"dig=12345,dview=servID_DM_Req"
AttributeType
AttributeValue
As defined by the LDAP standard, a successful request shall cause two responses to be returned. The first Search Response
shall include the objectName and attributes parameters. The attributes parameter shall be a sequence of pairs of AttributeType
and AttributeValue. The second Search Response shall include only the resultCode set to "Success" (0).
assigned by the server.
ndig OCTET STRING(SIZE(26)) The new digit mapped digit string.
In cases of "no match", the server should respond with a single SearchResponse message containing the resultCode set to 0
"Success".
2.1.8.2 Family Group Releation Request

LDAP Search Request:

baseObject "dview=<server_id>_getfgsubdata_Req" See General Requirements section
timeLimit 0 (No timelimit restrictions) Server expected to respond within a
predefined time (up to 10s)
attrsOnly 0 (FALSE) (attribute types and values) Server will always return both names &
values

AttributeValueAssertion AttributeType = "msisdn_info" msidn_info = OCTET STRING(SIZE(49))
AttributeValue = <key attribute value> This is the table key field
2.1.8.2.2 Dataview Definition


objectName "msisnd_info=<key attribute value>" <Key attribute Value> up to 100
characters may be returned here.
The server can optionally include the

dataview name as part of the objectName
response parameter after the msisdn_info
(comma separated). For example:
"msisdn_info=
123456789101:1111111111,dview=Server
ID_getfgsubdata_Req"
AttributeType
AttributeValue
As defined by the LDAP standard, a successful request shall cause two responses to be returned. The first Search Response
shall include the objectName and attributes parameters. The attributes parameter shall be a sequence of pairs of AttributeType
and AttributeValue. The second Search Response shall include only the resultCode set to "Success" (0).
assigned by the server.
family_group OCTET STRING(SIZE(1)) The field identify the Cg, Cd's relationship
2.2 LDAP Standard Method

This section describes the standard LDAP v2/v3 client requirement to query a external DB. Only Bind and Search operation is
supported and follow [RFC1777] and [RFC 2251].
2.2.1 LDAP Initialisation Requirements

2.2.1.1 LDAP Initialisation with SurePay as Client
The LDAP protocol is defined to run on a standard TCP/IP interface. SurePay therefore shall initially set up a TCP/IP
connection to the server using the server host name and port number as defined on platform RC screens.
When initialisation, the Client application shall executes a AEX action ldap!attach_user action to attach a SPA user to a LDAP
connection established by TCPIPSCH. An instance generated will be used by the SPA to do further actions (e.g.
SearchRequest). When attach the LDAP server, the dataview name configured in RCV forms shall be used by AEX.
The platform must send a Bind Request to establish an LDAP connection for each different type of LDAP operation (configured
in platform RCV forms).
LDAP Bind Request

version 2 or 3 The MAS platform supports LDAP
Protocol Version 2 and Version 3 as
standard LDAP client. Configurable on
RCV form 9.4
name OCTET STRING The DN of a Directory object, re-use the
dataview name configurable on RCV form
9.4

authentication Choice = simple, containing the OCTET The password is defined on MAS platform
STRING "<password>" e.g. "pass01" RCV Form 9.4
LDAP Bind Response

success(0):
invalid
connection.
matchedDN zero length OCTET STRING
errorMessage zero length OCTET STRING
The BIND operation and corresponding handling are all in MAS platform. SurePay application does not have control on it.
It is the responsibility of the MAS platform to detect the loss or failure of the TCP/IP connection to the server. This will require
the client to reconnect and rebind.
2.2.2 LDAP Request Definitions with SurePay as Client

This section provides a detailed description of the complete set of external LDAP requests sent by the Surepay service to an
external server.
2.2.2.1 General Requirement

The "Standard LDAP Client Search Timer" in Common Parameter table in number of tenths of a seconds should be used to
monitor how long Surepay shall wait for a Search Request response from an LDAP external server. If no response received,
the corresponding behavior shall be applied per query configuration.
The "Standard LDAP Client Search TimeLimit" in Common Parameter table if configured should be used to fill in timeLimit in
Search Request.
If retry is configured, then retry number should be equal to or less than the "Standard LDAP Client Search Retry Limitation" in
Common Parameter table.
2.2.2.2 MNP Query Request

This operation is used to submit a MNP Query Request to the external LDAP Server. This request is used to get the B-nr's
MNP/MVNO information. CP "Standard LDAP Client MNP Query DN" shall be used in attach to the platform instance.
The Data Standard LDAP Client MNP SEARCH BaseObject in Common Parameter table if configured should be used to fill in
baseObject in Search Request.

LDAP Search Request

baseObject Configurable in CP "Standard LDAP
Client MNP SEARCH BaseObject”
scope wholeSubtree (2): the search scope is
allowed on all levels under the baseObject
timeLimit configurable in CP "Standard LDAP Client Server expected to respond within a
Search TimeLimit" predefined time.
0 (FALSE) (attribute types and values) Server will always return both names &
TypesOnly values

filter Choice equalityMatch[3] where:
subscriberId=<Number to search> <Number to search> will be either an
MSISDN or a Fixed number for which the
portability status will be queried
The response shall include following message:
LDAP SearchResultEntry
objectName DN of the entry returned by the directory subscriberId=3490333444555, db=np
Server
HLR Id HLR Id where the subscriber’s data are Identifies the HLR where subscriber’s data
stored if found or a configurable value are stored (in case of VFI or VFI MVNO)
otherwise.
Network Id up to 16 character string Identifies the Operator (in case of OLO)
adminStatus AdministrativeStatus:
0: allocated (default value for mobile
numbers)
1: unallocated
2: barred
smsSupport SMS support:
0: no
1: yes (default value for mobile numbers)
LDAP SearchResultDone
ResultCode Result Code returned from the directory
server
2.2.2.3 Community Tariff Query Request

This operation is used to submit a community tariff Query Request to the external LDAP Server. This request is used to get the
called party's tariff information. CP data Standard LDAP Client MNP Query DN shall be used in attach to the platform instance.
The CP Data Standard LDAP Client MNP SEARCH BaseObject if configured should be used to fill in baseObject in Search
Request.

LDAP Search Request

baseObject Configurable in CP "Standard LDAP e.g. ou=eplus.de, ou=customers,
Client MNP SEARCH BaseObject” o=eplus.de
scope It specifies the search scope.Allowed
values are:
• baseObject (0): the search scope is
restricted only to the baseObject
• singleLevel (1):the search scope is
restricted to the entries that are one level
under the baseObjects
• wholeSubtree (2): the search scope is
allowed on all levels under the baseObject
derefAliases It indicates in which way manage aliases neverDerefAliases (0)
during the search. Allowed values are:
• neverDerefAliases (0): aliases are not
solved
• derefAlaways (1): aliases are solved in
all the search
• derefInSearching (3): aliases are solved
in all subordinate objects of the
baseObject
• derefFindingBaseObject (4): aliases are
solved only in the baseObject

sizeLimit The max number of entries that can be An integer number
returned in the Search Response The value of this parameter is ignored
timeLimit configurable in CP "Standard LDAP Client Server expected to respond within a
Search TimeLimit" predefined time.
It indicates whether the response will FALSE
TypesOnly return only attributes types or also
attributes values. Allowed values are:
• TRUE: only attributes types will be
returned
• FALSE: both attributes types and
attributes values will be returned
filter It defines the conditions to be The only allowed filter will be
satisfied for the entry attributes to be equalityMatch with an
returned by the Search Response AttributeValueAssertion where:
AttributeDescription="mobile"
AssertionValue=<Number to search>
where <Number to search> will be
either an MSISDN or a Fixed number in
international format (39...), for which
the tariff information will be queried.
attributes List of the attributes to be returned back EMPTY means all attributes returned
by each search result entry. back
Empty = retrieve all attributes
Seq = retrieve only a subset of attributes
E.g. Following table shows how the message will be filled in from SurePay logic:
The response shall include following message:
LDAP SearchResultEntry
dn DN of the entry returned by the directory uniqueIdentifier=310A01782687,
server ou=eplus.de, ou=customers, o=eplus.de
eplus_prepaid_gprs_tarif Tariff information of corresponding 20010021
subscriber
LDAP SearchResultDone
ResultCode Result Code returned from the directory
server

R28.1-LDAP Interface Specification

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

R28.1-LDAP Interface Specification

Загружено:

Авторское право:

Доступные форматы

8620 SurePay® 27.7/28.

Mandatory customer information

Information product support

2 LDAP Interface for Surepay 2

1.1 External References

Page 1 of 73 Alcatel-Lucent - Proprietary

2.1 LDAP DataView Method

2.1.2 General Requirements

Page 2 of 73 Alcatel-Lucent - Proprietary

2.1.4 Server Requirements

Dataview Name (dview) = Server Id + “_” + Dataview Name

Page 3 of 73 Alcatel-Lucent - Proprietary

• An additional request type "Request Bundle Subscription" is added.

Page 4 of 73 Alcatel-Lucent - Proprietary

2.1.6 LDAP Initialisation Requirements

LDAP Bind Request

LDAP Bind Response

2.1.6.2 LDAP Initialisation with SurePay as Client

Page 5 of 73 Alcatel-Lucent - Proprietary

LDAP Bind Request

LDAP Bind Response

2.1.7 LDAP Request Definitions with SurePay as Server

2.1.7.1 e-Commerce LDAP Requests

2.1.7.1.1 General Requirements for e-Commerce

Page 6 of 73 Alcatel-Lucent - Proprietary

This parameter is required to be in

If the Transaction Logging feature is

This field will contain the value of the

Balance Indicator An indication of which balance to use for

Page 7 of 73 Alcatel-Lucent - Proprietary

- The double-quote character (")

2.1.7.1.1.2 Platform Result Codes

2.1.7.1.1.3 Application Result Codes

Page 8 of 73 Alcatel-Lucent - Proprietary

Possible reasons include (but are not limited to):

13 = Invalid or missing PIN

Page 9 of 73 Alcatel-Lucent - Proprietary

19=Transaction Amount Invalid

Page 10 of 73 Alcatel-Lucent - Proprietary

68 = Failed - Chargeable Event Happened before Recharge Reversal

Page 11 of 73 Alcatel-Lucent - Proprietary

Realtime SMS release cause LDAP result code

Bundle Purchase Disallowed Reason LDAP result code

Page 12 of 73 Alcatel-Lucent - Proprietary

(Cr edit Card)

2.1.7.1.2 Authenticate Subscriber

2.1.7.1.2.1 Interface Requirements

The parameters sent in the LDAP Search Request shall be as follows:

LDAP Parameter Population Rules Comments

Page 13 of 73 Alcatel-Lucent - Proprietary

Subscriber ID (16 digits) Mandatory 0..9, A..F only

LDAP Search Response

The parameters returned in the LDAP Search Response shall be as follows:

LDAP Parameter Population Rules Comments

The attributes returned in a successful LDAP Search Response shall be as follows:

cospid OCTET STRING(SIZE(15)) COSP ID from the SIM RTDB

2.1.7.1.3 Request Balance

Page 14 of 73 Alcatel-Lucent - Proprietary

2.1.7.1.3.1 Interface Requirements

The parameters sent in the LDAP Search Request shall be as follows:

LDAP Parameter Population Rules Comments

Subscriber ID (16 digits) Mandatory 0..9, A..F only

Page 15 of 73 Alcatel-Lucent - Proprietary

2.1.7.1.3.2 Dataview Definition