SurePay R26SU2 LDAP Interface Specification

Intelligent Network
SurePay OCS V10SU10/R25SU6/R26SU2

LDAP Interface Specification
270-735-079R10.10
Issue 1.0
August 2006
Copyright © 2006 Lucent Technologies. All Rights Reserved.
This material is protected by the copyright 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 Lucent Technologies), except in
accordance with applicable agreements, contracts or licensing, without the express written consent of Lucent
Technologies and the business management owner of the material.
Product Development Manager 1-630-224-0378
Notice
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
Ordering information
To order this document in the United States, call 1-888-582-3688. In other countries call your 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
You may report errors or ask questions about this information product by sending mail to
aidoc@ctipinu.ih.lucent.com.
Document History
Issue Version Date Change Description

Draft 0.1 July 2006 Initial draft
Issue 1.0 August 2006 First Issue
Document ID: 270-735-079R10.10 SurePay External LDAP Interface Specification 11 August 2006
Contents
1 Introduction 1
1.1 External References 1
1.2 Compliance to LDAP Standard 1
2 LDAP Interface for Surepay 3

2.1 General Requirements 3
2.2 Client Requirements 3
2.3 Server Requirements 4
2.4 Enhancements 4
2.5 LDAP Initialisation Requirements 5
2.5.1 LDAP Initialisation with SurePay as Server 5
2.5.2 LDAP Initialisation with SurePay as Client 6
2.6 LDAP Request Definitions with SurePay as Server 7
2.6.1 e-Commerce LDAP Requests 7
2.6.1.1 General Requirements for e-Commerce 7
2.6.1.2 Authenticate Subscriber 14
2.6.1.3 Request Balance 15
2.6.1.4 Request Credit (Credit Card) 17
2.6.1.5 Request Credit (Scratch Card) 20
2.6.1.6 Request Credit 21
2.6.1.7 Request Debit (Service Delivery) 23
2.6.1.8 Request Debit 27
2.6.1.9 Credit Reservation 28
2.6.1.10 Request Bundle Subscription 32
2.6.2 Misc. LDAP interface 35
2.6.2.1 Generic LDAP interface 35
2.7 LDAP Request Definitions with SurePay as Client 43
2.7.1 Digit Mapping Request 43
2.7.1.1 Interface Requirements 43
2.7.1.2 Dataview Definition 44
Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY

1 1 Introduction
2 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.
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.
3 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 SurePay ® OCS unless
there is a specific note to the contrary.
4 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.
5 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.
6 1.1 External References

7 References
8 [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
9 1.2 Compliance to LDAP Standard

10 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.
11 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.
12 2. Surepay supports only a subset of the LDAP operations supported by the Lucent Technologies eCS platform. Surepay
supports ONLY the following LDAP operations :
- BindRequest
- BindResponse
- SearchRequest
- SearchResponse
Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 1 of 44

12
Note that the LDAP UnbindRequest is purposely not supported. The eCS expects an LDAP connection to remain
permanently bound for performance reasons.
13 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.
14 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.
15 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.

16 2 LDAP Interface for Surepay

17 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].
18 2.1 General Requirements

19 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 eCS 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.
20
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)
21 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.
22 2.2 Client Requirements

23 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 eCS’s and each subscriber is assigned one eCS of
the pair to be primary (under normal call processing circumstances calls for a subscriber will be sent to the eCS that is
primary for that subscriber. Only if that eCS is down will the call be sent to the alternate eCS). This means that there are two
possible destination server eCS'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 eCS. This requires that a mechanism should be
defined on the client (e.g. data table) to map each subscriber to a primary and alternate eCS. The client should always send
the first request to the primary eCS for a subscriber.
24 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 eCS. If the first
LDAP Request from the client fails (time out) then the client should attempt to resend the request to the Secondary eCS.
25 The eCS 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 eCS platform
using RCV forms 9.*). The dataview name (dview) comprises the physical dataview table name on the server plus an eCS-
specific identifier, as follows:
Dataview Name (dview) = Server eCS Id + “_” + Physical Dataview Table Name
e.g. dview = “eCS01_sub_debit” will be the dataview name for the sub_debit dataview table on server eCS “eCS01”
The requirement for the client is to bind to the defined dataview names using an LDAP Bind Request for each dataview for
each server eCS. (i.e. there could be multiple BIND requests sent to each server eCS, one for each dataview required to be

25 used). This implies that a mechanism should be defined on the client to store the server eCS 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 eCS Id above) and port number. These are required for TCP/IP link setup.
Note that the maximum length of a dataview name (including the eCS Id) is 30 characters. This limit is imposed by the eCS
platform.
26 The client needs to store the LDAP password for each dataview to be provided in the BIND Request.
27
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.
28 2.3 Server Requirements

29 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 eCS 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 eCS Id) is 30 characters. This limit is imposed by the eCS
platform.
30 2.4 Enhancements
31 This section is added to describe enhancements in subsequent releases.
32 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.
33 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.
34 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.

34 • 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.
35 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.
36 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.
37 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)
38 From V10 SU10, the following enhancements are included:
• 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
39 2.5 LDAP Initialisation Requirements

40 2.5.1 LDAP Initialisation with SurePay as Server
41 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.
42 The LDAP client must send a Bind Request to establish an LDAP connection for each different type of LDAP operation
(dataview) for each server eCS.
43
LDAP Bind Request
LDAP Parameter Population Rules Comments
version 2 The eCS platform supports LDAP
Protocol Version 2
name OCTET STRING, populated as From the client's point of view, the
"dview=<eCS Id>_<dataview> e.g. "dataview" is the table name
"dview=eCS01_auth_sub"

authentication Choice = simple, containing the OCTET The password must match that defined on
STRING "<password>" e.g. "pass01" eCS platform RCV Form 9.4
61
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 eCS
platform. Client should ignore any value
in this field.
errorMessage zero length OCTET STRING Not set to any meaningful value by eCS
platform. Client should ignore any value
in this field.
79
The eCS 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.
80 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.
81 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.
82 2.5.2 LDAP Initialisation with SurePay as Client

83 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.
84 The SurePay client must send a Bind Request to establish an LDAP connection for each different type of LDAP operation
(dataview) for each server.
85
LDAP Bind Request
version 2 The eCS 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 eCS platform
STRING "<password>" e.g. "pass01" RCV Form 9.4
103
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
errorMessage zero length OCTET STRING
121
The eCS 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.
122 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.
123 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.
124 2.6 LDAP Request Definitions with SurePay as Server

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

127 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.
128 2.6.1.1 General Requirements for e-Commerce

129 2.6.1.1.1 Common Input Parameters
130 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 The Provider ID was formerly called
Provider ID. If present, this must match "Account ID" in V8.
the Provider 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
requesting the eCommerce service. included in any AMA record created by
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
service. If present, must match an entry included in any AMA record created by
in the Surepay e-Commerce Merchant e-Commerce Requests.
(EM) 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
debited from the subscriber's balance. 4 digits after the decimal point.
Reference A character string. This content of this If present, this parameter shall be
string is of no significance to Surepay. included in any AMA record created by
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 Up to 24 digits are supported, but the
an 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
credit validity period, as defined by the days, 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
180 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.

181
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)
182 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".
183 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.
184 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).
185 2.6.1.1.2 Platform Result Codes

186 The eCS platform will return one of the following LDAP result codes for unsuccessful eCommerce requests that fail at the
platform level. Note that the eCS 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 eCS platform will generally
never reach the SurePay service. Explanations of what the error indicates is also included below:
187 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.
188 49 = invalidCredentials
This error code indicates the hostname associated with the SearchRequest is NOT the same hostname as was verified by the initial
BindRequest.
189 51 = busy
This error code indicates the TCPIPSCH process is running out of memory processing LDAP SearchRequests. This indicates the eCS is
heavily loaded. If applicable the client may retry this request later.
190 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 eCS in a mated eCS configuration.
191 80 = other
This error code indicates the TCPIPSCH process encountered an LDAP decode problem while processing the SearchRequest.
192 2.6.1.1.3 Application Result Codes

193 For all the e-Commerce requests the following result codes are used. Explanations of what the error indicates is also
included:
194 00 = Success
This result code indicates the request was successfully processed.
195 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.

195 * 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.
196 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).
197 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.
198 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.
199 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
* 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)
200 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.
201 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.
202 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.
203 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.
204 10 = Credit card request declined
This error code indicates a Credit Card Recharge request failed because the external credit card system refused the transaction.
205 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.
206 12 This result code is not used.
207 13 = Invalid or missing PIN

This result code indicates a credit card recharge request fails, because the provided PIN was invalid.
208 14 = Credit card number unknown
This error code indicates a Credit Card Recharge request failed because the provided card number was invalid.
209 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.
210 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.
211 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.

212 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.
213 19 = Subscriber suspended
This code is Not Used.
214 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.
215 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.
216 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.
217 23 = Scratch card expired
This error code indicates a Scratch Card Recharge request failed because the external system indicated the scratch card had expired.
218 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.
219 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.
220 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.
221 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.
222 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.
223 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.
224 31 = Unexpected response from daemon
This error code indicates a Scratch Card Recharge request failed because the external system returned an expected response.
225 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.
226 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).
227 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.
228 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.
229 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.
230 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.

231 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.
232 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.
233 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.
234 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.
235 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).
236 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.
237 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.
238 45 = Account Data Truncated
239 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.
240 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.
241 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
242 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
243 98 = Failure
This result code indicates the request is failed during applying the recharge amount to the subscriber's account.

244 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.
245 The following table defines which types of request can return which result codes:
(Service Delivery)
Request Balance
Request Credit
Request Credit
Request Credit
(Scratch Card)
Reserve Credit
Request Debit
Request Debit
(Credit Card)
Authenticate
Result Code
Subscriber
00 x x x x x x x x
01 x x x x x x x x
02 x x x x x x x x
03 x x x x x x x x
04 x x x x x x x x
05 x x x x x x x x
06 x x x x x x
07 x x x x x x
08 x x x
09 x x
10 x
11 x
12
13 x
14 x
15 x
16 x
17 x x
18 x x x x x x 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
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
57 x
68 X
70~77 x
98 x x x
99 x x x x x x x x
246 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

246 from the eCS 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.
247 2.6.1.2 Authenticate Subscriber

248 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.
249 2.6.1.2.1 Interface Requirements

250 LDAP Search Request
251
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) eCS will only return 1 result
timeLimit 0 (No timelimit restrictions) eCS will respond within 4 seconds
attrsOnly 0 (FALSE) (attribute types and values) eCS 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
293 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.
294 LDAP Search Response

295
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]
313
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 eCS platform.
314 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
328 2.6.1.3 Request Balance

329 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.

332

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

Provider ID (10 digits) Optional0..9 only
Transaction ID (20 digit) Optional0..9 only
Requesting System (14 digits) Optional0..9 only
Merchant ID (16 chars) OptionalChars
Reference (40 chars) OptionalChars
Currency Label (24 chars) OptionalChars
Balance Requested (1 digit) Optional0..3 only
Balance Category (1 digit) Optional0..1 only
International Indicator (1 digit) Optional0..9 only

374 Connected DNlist (330 chars) Optional0..9, "#", "*", "," only
AccountDataGrpID (14 chars) OptionalChars
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.
375 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.
376 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.
377 The International Indicator defined in the interface is used to indicate if any number in the Connected DNlist is an
international number.
The Connected DNlist parameter is used to define the numbers to which the SMS will be sent.
These two 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.
378 2.6.1.3.2 Dataview Definition

380
section.
AttributeType
AttributeValue
398
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
eCS 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 512) Subscriber's additional data indentified by the AccountDataGrpID
in the request.
437 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.
438 2.6.1.4 Request Credit (Credit Card)

439 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.

442


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

Provider ID (10 digits) Optional 0..9 only
Transaction ID (20 digit) Optional 0..9 only
Requesting System (14 digits) Optional 0..9 only
Merchant ID (16 chars) Optional Chars
Reference (40 chars) Optional Chars
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
Currency Label (24 chars) Optional Chars
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.
485 Service Specific Data 1~4 (100 chars) Optional Chars (except for the listed four chars: " : ", " ' ", " \ ", and " $ ") (V10.9)
486 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 Card Depending on a provisioned option, as an
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 Card If Requires Processing is 1 then the Expiration
Expiry Date. See below for the required Date must be present. If Requires Processing
format. 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 Code. If Requires Processing is 1 then the Auth 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.
520 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'.
521 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.

524
section.
AttributeType
AttributeValue
542
eCS platform.
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.
565 2.6.1.5 Request Credit (Scratch Card)

566 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.

569
The parameters to be sent in theLDAP Search Request shall be as follows:
baseObject "dview=<scp_id>_sc_recharge" See General Requirements section
parameters

Transaction ID (20 digits) Optional0..9 only
Scratch Card Number (16 digits) Mandatory 0..9 only
Scratch Card PIN (8 digits) Mandatory 0..9 only
Balance Indicator (1 digit) Optional0..2 only
Notes:Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference support 40 character string.
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

629
section.
AttributeType
AttributeValue
647
eCS 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.

674 2.6.1.6 Request Credit

675 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.


678
The parameters to be sent in the LDAP Search Request shall be as follows:
baseObject "dview=<scp_id>_sub_credit" See General Requirements section
parameters

Transaction ID (20 digit) Optional0..9 only
Transaction Amount (15 chars) Mandatory 0..9, '.' only
Balance Indicator (1 digit) Optional0..2 only
Credit Type (3 digits) Optional0..9 only
AccountDataGrpID (14 chars) Optional Chars
Notes:Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference support 40 character strings
722 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):
723 "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.
724 Credit Validity Period is only valid when Credit Type is not "100". (from V10.7)

727
section.


AttributeType
AttributeValue
745
eCS platform.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the credit is applied, presented as a
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 compatibility with
earlier versions.
772 2.6.1.7 Request Debit (Service Delivery)

773 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.


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

Service Type (16 chars) OptionalChars
Content Type (16 chars) OptionalChars
Number Of Items (6 digits) Mandatory 0..9 only
Balance Indicator (1 digit) Optional0..2 only. From V10.9, "3" is also valid input.
Debit Type (3 digits) Optional0..9 only
Dest Address (16 digits) Optional0..9, A..F only
Content Value Type (16 chars) OptionalChars
Content Value (9 digits) Optional0..9 only
Location Information Type (1 char) Optional Char
Location Information (41 chars) Optional Chars
Connected DNlist (330 chars) Optional0..9, "#","*", "," only
AccountDataGrpID (14 chars) Optional Chars
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.

819 The International Indicator defined in the interface is used to indicate if any number in the Connected DNlist is an international number.
The Connected DNlist parameter is used to define the numbers to which the SMS will be sent.
These two parameters are used to check if any "IN message buckets" or "Non-International Buckets" are available for this subscriber.
821 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).
822 "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.
823 "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.
Service Type Identifies the Service Type for the delivered The combination of Merchant ID, Service
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 delivered The combination of Merchant ID, Service
The Content Type is checked in the SurePay

eCommerce Content Type table (ECT). If no
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 is
allows special handling of this debit request "100","200","201". Any other value shall 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 Destination Zone. 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 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 Value If Content Value is present, but Content Value
Type. Type parameter is not present then Surepay
will attempt to use a default Content Value
This can be used, for example, to define the Type. If no default is available then Surepay
size of the eCommerce service provided (e.g. a will return the error "Invalid or Missing
Download in KBytes). Parameters".

Location Information Type Identifies the type of value defined by the If present, the Location Information Type and
location Information parameter. Location Information can be used in
combination to vary the charge applied. For
0 Location Number example, this allows SurePay to support
1 Geographic location based charging.
2 VLR Number
3 Location Info Number If Location Information Type is present, but
4 Cell ID LAI the Location Information parameter is not
5 SGSN Address (GT format) present then Surepay will return the error
6 SGSN IP Address "Invalid or Missing Parameters".
Location Information type in BOLD shall be if the Location Information Type is SGSN IP
supported in V10SU6. In the initial release Address. the Location Information shall be
only Location information based on VLR usual notation format. e.g for IPv4 address, it
address shall be supported in SurePay shall be dotted decimal notation format. e.g
service logic (Location Information Type = 2, 192.168.0.1, otherwise, Surepay will return the
5, 6). The LDAP interface supports the other error "Invalid or Missing Parameters". For
types indicated above for future expansion. IPv6 address, it should be enclosed in "[" and
The VLR address from external client shall be "]", and the address format must be
provided in E.164 format. "xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx"
, where 'x' is hexadecimal characters.
Location Information Location Information is defined by Location If Location Information is present, but
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 contain one international number
Connected DNlist Carry the numbers which the MMS/SMS will
be sent to.

876
section.
AttributeType
AttributeValue
894
eCS platform.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the debit is applied, presented as a

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
921 2.6.1.8 Request Debit

922 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.

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

Transaction Amount (15 chars) Mandatory 0..9, "." only
Balance Indicator (1 digit) Optional0..2 only. From V10.9, "3" is also valid input.
Connected DNlist (330 chars) Optional0..9, "#","*", "," only
AccountDataGrpID (14 chars) Optional Chars (V10SU11)
Notes:Before V10.5, Reference supports 14 digit string. From V10.5 onwards, Reference support 40 character strings
Debit Type (3 digits) Optional 0..9 only
969 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).
970 "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.

971 The following table describes those input parameters not already described in the General Requirements for e-Commerce
section:
Debit Type Identifies a particular type of debit. The only valid value defined for
This allows special handling of this Debit Type is "300". Any other
debit request value shall be ignored and the request
treated as a normal debit request.

983
section.
AttributeType
AttributeValue
1001
eCS platform.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the debit is applied, presented as a
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.
1028 2.6.1.9 Credit Reservation

1029 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.


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

Transaction ID (20 digit) Mandatory 0..9 only
Merchant ID (16 chars) Optionalchars
Reference (40 Chars) OptionalChars
Service Type (16 chars) OptionalChars
Content Type (16 chars) OptionalChars
Number Of Items (6 digits) Optional0..9 only
Balance Indicator** (1 digit) Optional0..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) Optional0..9 only
Dest Address (16 digits) Optional0..9, A..F only
Content Value Type (16 chars) OptionalChars
Content Value (9 digits) Optional0..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.
Service Type Identifies the Service Type for the delivered The combination of Merchant ID, Service
The Service Type is checked in the SurePay

eCommerce Service Type table (EST). If no
Content Type Identifies the Content Type for the delivered The combination of Merchant ID, Service

The Content Type is checked in the SurePay

eCommerce Content Type table (ECT). If no
Number of Items Identifies the number of items to be delivered This is only used if SurePay needs to 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 able to
1 = Reserve Credit - Fixed Amount determine the amount either from the Amount
2 = Execute Debit against Reserved Credit parameter or the combination of Number of
3 = Cancel Reserved Credit Items, Merchant ID, Service Type and Content
4 = Reserve Credit - Calculate Amount Type.
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 reserved Amount is specified in currency and may
from or charged to the indicated balance. include an optional "." and up to 4 decimal
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) when The credit will expire when the SurePay audit
the reserved amount will expire, if not first runs on or after this period has expired.
previously used.
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 SurePay to amount to charge.
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 Value This is only used if SurePay calculates the
Type. amount to charge.
This can be used, for example, to define the If the Content Value is present, but the Content
size of the eCommerce service provided, in Value Type parameter is not present then
KBytes. Surepay will attempt to use a default Content
Value Type. If none is available then Surepay
will return the error "Invalid or Missing
Parameters".

1120
section.
AttributeType
AttributeValue
1138
eCS platform.
bal OCTET STRING(SIZE(15)) Subscriber's balance after the credit reservation, execution or
cancellation is applied, presented as a string. May include "." and
up to 4 digits after the decimal point. May be negative (prepended
by "-").
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.
1169 2.6.1.10 Request Bundle Subscription

1170 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 eCS/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.
1171 From V10SU8 the LDAP message size limit is increased to 5K.

1174

baseObject "dview=<scp_id>_req_bundle" See General Requirements section
parameters
1216 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
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.
1218 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.
1219 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.

1222
section.
AttributeType
AttributeValue
1240
eCS platform.
for e-Commerce section
b1 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.

b2 OCTET STRING(SIZE(15)) Subscriber's Secondary Balance (if supported), presented as a

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 subscriber
Attributes) profile.
ps1~ps5 (5 OCTET STRING(SIZE(8)) Indicates promotional tariff plan 1 ~ 5 Start Date in subscriber
Attributes) profile. Format is DDMMYYYY
pe1~pe5 (5 OCTET STRING(SIZE(8)) Indicates promotional tariff plan 1 ~ 5 End Date in subscriber
Attributes) 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
3 - Promotion Expired
4 - Active No Renewal
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(10)) Indicates discount 1~10 subscription's current value e.g. bucket
Attributes) value or UBD counter etc. Range 0..9999999999
du1~du10 (10 OCTET STRING(SIZE(10)) Indicates discount 1~10 subscription's carry-over value (only
Attributes) applicable for bucket). Range 0..9999999999

ff1~ff15 (15 OCTET STRING(SIZE(24)) Indicates the 15 FF numbers asociated with the 5 bundles. These
attributes) parameters will only be populated in V10SU7 and later.
1351 2.6.2 Misc. LDAP interface
1352 2.6.2.1 Generic LDAP interface

1353 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.
1354 2.6.2.1.1 Application Result Code

1355 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.
1356 00 - Success
This result code indicates the request/operation is successful.
1357 01 - Invalid or missing parameter
This result code indicates that mandatory parameter is missing or data is present but in wrong format.
1358 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 opeartion is query
RTDB and the queried table is not SIMRTDB, this result code indicates that there is no record in queried table with the input key.
1359 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.
1360 06 - Card in use/ Barred Call in Progress
This result code indicates balance transfer is not allowed because of calls in progress.
1361 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.
1362 13 - Invalid or missing PIN
This result code indicates that input parameter PIN doesn't match the account's 3rd party access PIN.
1363 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.
1364 35 - Insufficient balance
This result code indicates remaining balance of the account is not enough to fund the specified AMT.
1365 37 = Failed - Transaction ID Used
1366 38 = Failed - Transaction ID Committed
1367 41 = Failed - Transaction in Progress
1368 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.

1369 71 - Maximum call exceeded for third party call

This result code indicates that maximum simultaneous call exceeded for the account.
1370 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.
1371 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.
1372 86 - Third party access blocked
This result code indicates that 3rd party access is blocked for the account.
1373 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.
1374 88 - Balance transfer Not allowed
This result code indicates that the account is not allowed to do balance transfer.
1375 89 - System Error
This result code indicates that service was failed to debit/credit the account.
1376 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.
1377 The following table defines which types of request can return which result codes:
LDAP Query RTDB
Balance Transfer
Balance Transfer
Authenticate 3rd
Modify 3rd Party
Authenticate
Result Code
party user
data
PIN
00 x x x x x
01 x x x x x
02 x x x x 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
71 X
72 x
85 X
86 X
87 X
88 x
89 x
99 x x x x x

1379 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
1380 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;'.
1381 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.
1382 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.
1384 The parameters sent in the LDAP Search Request shall be as follows:
baseObject "dview=<scp_id>_request_data" See General Requirements section
attrsOnly 0 (FALSE) (attribute types and eCS will always return both names & values
values)
AttributeValueAssertio AttributeType = "sid" sid = OCTET STRING(SIZE(1500))
n AttributeValue = <key attribute This is the table key field which shall be
value> composed of a concatenated
string of input parameters
1426 2.6.2.1.2.1 LDAP Query RTDB data

1427 LDAP Query Request
1428 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>

1429 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
1430 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 The table name shall be
RTDB name which is provisioned as one of key in the rc
accessed in the LDAP table LDAP Query Data Mapping.
request.
Tbl_Key Y String This parameter indicates the The key which is used to access
key which is used to access RTDB. In V10.9, since SIM RTDB
RTDB. is supported to access, the table
key shall be subscriber ID, i.e.
MSISDN
Field_Name N Sting This parameter includes all The field names divided by comma
the field names that needs to need to be provisioned in the rc
be retrieved out from the table LDAP Query Data Mapping.
RTDB.
1456 LDAP Query Response

1457 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.
1474 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.
1475 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.
* For the successful case, then return result code 00- Success and return data in response.
Example:
The return_data 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
1476 No AMA generated for the LDAP request of querying RTDB data.
1477 2.6.2.1.2.2 Authenticate 3rd party user

1478 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.
1479 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.
1501 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.
1518 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.

1519 SurePay could return an application result code in below list:
00 - Success
This result code indicates the authentication is successful.
01 - Invalid or missing parameter

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:
13 - Invalid or missing PIN

This result code indicates that input parameter PIN doesn't macth the account's 3rd party access PIN.

1519
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.
1520 2.6.2.1.2.3 Modification 3rd party PIN

1521 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

will used as key for accessing
account data.
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)
1544 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.

1545 SurePay could return an application result code in below list:
00 - Successful
01 - Invalid or missing parameter
02 - Invalid subscriber details
13 - Invalid or missing PIN
99 - internal error
Refer to the application result code of "Authenticate 3RD party user".
1546 2.6.2.1.2.4 Authenticate Balance transfer

1547 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=xx
x,SOURCE=xxx,TARGET=xxx,AMT=xxx,CURRENCY=xxx,METHOD=xxx,LASTRP=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.
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.
will used as key for accessing
account data.
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

LASTRP Y String(1) Indicate whether it is the last

reprompt for requesting
system.
0 - False
1- True
1615 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.

1616 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.
1617 2.6.2.1.2.5 Balance transfer

1618 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,SOUR
CE=xxx,TARGET=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.
1619
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.
1620 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.

1621 Beside all the result code listed for "authenticate balance transfer" action, this action will also return the following result code:
37 = Failed - Transaction ID Used

38 = Failed - Transaction ID Committed

41 = Failed - Transaction in Progress

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.
1622 2.6.2.1.3 Dataview definition

1624 The parameters returned in the LDAP Search Response shall be as follows:
original Search Request key will be
returned. See General
Requirements.
AttributeType
AttributeValue
resultCode Failure code assigned by See [RFC1777]

platform
1642 A successful request shall cause two responses to be returned. The first Search Response shall include the objectName and attributes
eCS 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
1656 2.7 LDAP Request Definitions with SurePay as Client

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

1659 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.
1660 2.7.1.1 Interface Requirements

1662

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
1704 The output information shall be "encoded" in the LDAP SEARCH request key as follows:
Original Digits (16 characters) Mandatory 0..9, A..F, *, # only
1705 2.7.1.2 Dataview Definition

1707
objectName "dig=<key attribute value>" <Key attribute Value> up to 100
characters may be returned here.
AttributeType
AttributeValue
1725
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).
server.
ndig OCTET STRING(SIZE(26)) The new digit mapped digit string.
1736 In cases of "no match", the server should respond with a single SearchResponse message containing the resultCode set to 0
"Success".

SurePay R26SU2 LDAP Interface Specification

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SurePay R26SU2 LDAP Interface Specification

Uploaded by

Copyright:

Available Formats

Intelligent Network

SurePay OCS V10SU10/R25SU6/R26SU2

Product Development Manager 1-630-224-0378

Mandatory customer information

Information product support

Issue Version Date Change Description

2 LDAP Interface for Surepay 3

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY

6 1.1 External References

9 1.2 Compliance to LDAP Standard

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 1 of 44

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 2 of 44

16 2 LDAP Interface for Surepay

18 2.1 General Requirements

22 2.2 Client Requirements

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 3 of 44

28 2.3 Server Requirements

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

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

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 4 of 44

39 2.5 LDAP Initialisation Requirements

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 5 of 44

82 2.5.2 LDAP Initialisation with SurePay as Client

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 6 of 44

LDAP Parameter Population Rules Comments

124 2.6 LDAP Request Definitions with SurePay as Server

126 2.6.1 e-Commerce LDAP Requests

128 2.6.1.1 General Requirements for e-Commerce

This parameter is required to be in

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 7 of 44

If the Transaction Logging feature is

This field will contain the value of the

Balance Indicator An indication of which balance to use for

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 8 of 44

- The double-quote character (")

185 2.6.1.1.2 Platform Result Codes

192 2.6.1.1.3 Application Result Codes

Possible reasons include (but are not limited to):

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 9 of 44

207 13 = Invalid or missing PIN

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 10 of 44

212 18 = Wrong type/missing balance

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 11 of 44

231 38 = Failed - Transaction ID Committed

Realtime SMS release cause LDAP result code

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 12 of 44

244 99 = Internal Error

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 13 of 44

247 2.6.1.2 Authenticate Subscriber

249 2.6.1.2.1 Interface Requirements

LDAP Parameter Population Rules Comments

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

294 LDAP Search Response

LDAP Parameter Population Rules Comments

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 14 of 44

attributes: sequence of see below

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

328 2.6.1.3 Request Balance

330 2.6.1.3.1 Interface Requirements

LDAP Parameter Population Rules Comments

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

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 15 of 44

378 2.6.1.3.2 Dataview Definition

Issue 1.0 LUCENT TECHNOLOGIES PROPRIETARY Page 16 of 44