(c) 1997, 1999 IBM Corporation. All rights reserved.
|
|
The IBM Payment Server 1.2 for NT, AIX and Solaris has been tested and evaluated by SETCo and fully complies with the SET(TM) Specification. The SET Word Marks and the SET Logo are trademarks, exclusively owned by SET Secure Electronic Transaction(TM) LLC (hereinafter referred to as SETCo). |
PTF |
AIX |
SUN |
NT |
APAR Description |
1.2.20.4 |
IW00326 |
IW00417 |
IR43278 |
Fix 4K+ memory leak on PInit exchange. |
1.2.20.4 |
IW00405 |
IW00418 |
IR43279 |
New profiles 18, 19 - similar to 8, 9 with multi-currency support. |
1.2.20.4 |
IW00374 |
IW00419 |
IR43280 |
Add instructions to readme on "How to Delete a Merchant from the Database" |
1.2.20.4 |
IW00372 |
IW00420 |
IR43281 |
Some ACB (Acquirer Controls Batch) batches do not close on Payment Server. |
1.2.20.4 |
IW00154 |
IW00421 |
IR43282 |
New profile 105 - similar to 5 with multiple currency support. |
1.2.20.4 |
IW00351 |
IW00422 |
IR43283 |
JNI panic when issueing an acceptpayment with autoauth. |
1.2.20.4 |
IW00169 |
IW00423 |
IR43284 |
Payment Server has now been tested with JDK 1.1.8 on AIX and Solaris, and JRE 1.1.8 on NT.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that installation instructions for the full product version of 1.2.20.0 are the same as those for the original version and can be found in the IBM Payment Server for AIX, Windows NT and Solaris, Administration Guide, V1.2 .
IBM Payment Server PTFs for AIX are available both electronically and on CD. To install a PTF:
Note: The installation directory is /usr/lpp/IBM_Payment_Server.
As of version 1.2.13, some Payment Server product files are backed up during PTF installation. The backup directory will be put in /usr/lpp and named after the PTF. For example, the backup directory for PTF U300080 is /usr/lpp/backup_U300080. The files are backed up with the complete directory structure of each file. The following files are backed up:
Once the product is installed, the rest of the setup instructions can be found in the IBM Payment Server for AIX, Windows NT and Solaris, Administration Guide, V1.2 . Also check Platform-specific Information for AIX, Windows NT, and Solaris for any updates to the setup instructions and software prerequisites.
IBM Payment Server PTFs for NT are available electronically. To install a PTF:
Note: The installation directory will be the directory of your current Payment Server installation.
Once the product is installed, the rest of the setup instructions can be found in the IBM Payment Server for AIX, Windows NT and Solaris, Administration Guide, V1.2 . Also check Platform-specific Information for AIX, Windows NT, and Solaris for updates to the setup instructions and software prerequisites.
IBM Payment Server PTFs for Solaris are available both electronically and on CD. To install a PTF:
cd /var/spool/pkgtar -xvf /cdrom/aix_tarservic/Uxxxxxxx.TAR
Note: The default installation directory is /opt/IBM_Payment_Server.
# pkgadd -d .
As of version 1.2.13, some Payment Server product files are backed up during the installation. The backup directory will be put in /opt and named after the PTF. For example, the backup directory for PTF U300081 is /opt/backup_U300081. The files are backed up with the complete directory structure of each file. The following files are backed up:
Once the product is installed, the rest of the setup instructions can be found in the IBM Payment Server for AIX, Windows NT and Solaris, Administration Guide, V1.2 . Also check Platform-specific Information for AIX, Windows NT, and Solaris for any updates to the setup instructions and software prerequisites.
A SET Sale transaction is an AuthReq with CaptureNow. This message causes the transaction to be both authorized and captured. The original versions of eTill and Payment Server reversed Sale transactions by sending a CapRevReq followed by an AuthRevReq. Clarification of the SET spec from the Tenth Mountain DRB indicates that sale transactions should be reversed with a single message - an authRevReq which reverses an authReq that had CaptureNow set to true. Starting with 1.2.20.4, the SET Cassette has been changed to reverse Sale transactions via an authRevReq. From the API, a Sale transaction can be reversed by issueing only a DepositReversal API command. This will cause the SET Cassette to send an AuthRevReq message to the gateway.
Starting with version 1.2.20.4, SET profiles 18 and 19 have been defined. Profile 18 is the first MCB (merchant controls batch) profile to support multiple currencies. Note that the SET protocol does not support the meaningful exchange of batch totals when there is more than one currency in the batch. No totals exchange is done for profile 18. Detailed information about these new profiles can be seen in the technical update section of this file under the heading "SET Profiles".
Starting with version 1.2.20.4, SET profile 105 has been defined. This profile is the same as profile 5 with the addition of multiple currency support. Detailed information about these new profiles can be seen in the technical update section of this file under the heading "SET Profiles".
Starting with version 1.2.20.2, SET profiles 101 and 102 have been defined. We recommend that all new installations of Payment Server start with one of these profiles unless directed differently by the acquirer. Profile 101 should be used when the acquirer expects the merchant to control the batch, that is issue open and close batch commands and set the batch id. Profile 102 should be used when the acquirer expects to control the batch. Detailed information about these new profiles can be seen in the technical update section of this file under the heading "SET Profiles".
Starting with version 1.2.20.2, SET profiles 103 and 104 have been defined. Both 103 and 104 are acquirer controls batch and allow multiple currencies in a single batch. Profile 103 supports split payments, profile 104 does not. Detailed information about these new profiles can be seen in the technical update section of this file under the heading "SET Profiles".
The migration utility can not migrate orders whose SET message records are deleted. However, it will continue with migration after finding such an order. The migration utility can also not migrate orders which refer to configuration such as brand and acquirer configuration that has been removed from the database. When the migration utility finds such an order it will print an error message and stop the migration process.
Payment Server now supports the Merchant Initiated Authorization (MIA) extension for SET Secure Electronic Transaction messages. The MIA extension permits a merchant to use SET messages for authorization and capture for orders that were placed by the cardholder using a transmission method other than SET. Since these messages will not carry a cardholder certificate, the gateway certficate must indicate that certless purchases are supported.
The MIA extension TransMethod field carries a defined value representing
the transmission method used by the merchant to collect card data from the consumer.
The value for this field will default to MIA_otherElectronic.
The default can be overridden
by the merchant through use of the new protocol data keyword,
$TRANSMETHOD. See the New Protocol Data Keywords heading in this
section for details. The optional TransCrypto field
is always set to null by Payment Server.
Prior to the definition of MIA, the Payment Server implemented the IBM-defined Merchant Originated Payment (MOP) extension. To allow time for gateway installations to migrate to the official MIA SET extension, Payment Server will build and send both the MIA and the MOP extensions on every merchant originated AuthReq. Every order created in the Payment Server via the ACCEPTPAYMENT API command is considered merchant originated. If a merchant is already using ACCEPTPAYMENT, no change is required to cause both the MIA and MOP extensions to be sent. These are both non-critical extensions and should be ignored by gateways which do not implement this support.
More information on SET extensions and on the MIA extension can be found on the SETCo web site.
The SET payment flows make use of certificates to identify the parties involved in the payment. The merchant and gateway are always required to have certificates. The presence of a cardholder certificate is optional. Payment flows which involve certificates for all three parties to the transaction are often referred to as "3KP". Payments which do not involve a cardholder certificate are referred to as "2KP". 2KP is also known as "certless purchase". The gateway certificate includes a flag which indicates whether or not it will accept 2KP transactions.
All merchant initiated authorizations (MIA or MOP) are 2KP flows. (Merchant initiated transactions are transactions in which cardholder data is collected by the merchant by means other than the exchange of SET messages.) A consumer with a SET wallet may also initiate a 2KP flow by choosing to pay with a credit card for which no SET certificate has been acquired. Some merchants who support MIA or MOP also want to be able to enforce consumer use of a SET certificate when a SET wallet is used. Since the gateway certificate in this case indicates that 2KP flows are accepted, the certificate cannot be used to reject certless purchases from a SET wallet.
Version 1.2.20.0 of the Payment Server introduces to the merchant the capability of specifing that wallet purchases must include consumer certificates even when the gateway certificate indicates that certless purchases are allowed. The merchant specifies this on a per-transaction basis by including the protocol data keyword/value $REQUIRECARDCERT=1 on the RECEIVEPAYMENT API command. If a PReq is received for an order where $REQUIRECARDCERT=1, Payment Server will return a SET Error message to the wallet with the error code ErrorCode_signatureRequired.
The certificate utility eecertreq which shipped with Payment Server 1.2.0.0 supported only "visible strings". These are strings whose characters fall between the values of 32 and 127 inclusive. DBCS languages and some SBCS languages have characters which can not be handled by this utility.
Now, eTillcertreq, will handle non-visible BMP strings as well as visible strings both for input and display. Use eTillcertreq exactly as you would eecertreq. The interface and function are identical except for the BMP support.
Use of eTillcertreq on NT requires that the iconv library be installed. See the NT subsection in the Platform-specific Information section below.
Any regristration form field can be entered as a BMP string but only five of those fields will be accepted as BMP strings by the underlying SET messaging code. For example, you can enter a BMP string for the Financial institution, but the request will not go through do to an error at a lower level of the code. The following fields can legitimately be entered as BMP strings.
These fields will be displayed as BMP strings when their values are set to BMP strings by the Certificate Authority.
Certificate messages include a field which specifies the language of the transaction. If you need to use a language other than English for these flows between the merchant and the certificate authority (CA), you can set the environment variable
EECERTREQ_LANGUAGE to the appropriate two digit language code from the ISO-639 standard. For example, en is the ISO-639 code for English, de is the ISO-639 code for German. This variable will be used by both eecertreq and eTillcertreq to determine the language code used in certificate messages.
Several new Payment API return codes have been added. The C definitions for Payment Framework return codes are in etillapi.h. The C definitions for SET Cassette return codes are in etillset.h. The Java definitions for both Framework and SET Cassette return codes are in ETillSocketAPI.java. ETillSocketAPI.java is part of the sample GUI sample code.
Primary return codes begin with "PRC_". Secondary return codes begin with "RC_".
PRC_AUTOAPPROVE_FAILED is returned on ACCEPTPAYMENT API command and indicates that the Order object is in Ordered state but the new Payment object was not approved. The secondary response will be RC_NONE or RC_SET_ACQUIRER_RESPONSE_UNEXPECTED.
PRC_AUTODEPOSIT_FAILED is returned on both ACCEPTPAYMENT and APPROVE API commands. This return code indicates that a Payment object was created in Approved state but the Payment was not deposited. The secondary response will be RC_NONE or RC_SET_ACQUIRER_RESPONSE_UNEXPECTED.
This return code may be returned on RECEIVEPAYMENT or ACCEPTPAYMENT API commands. RC_SET_MERORDERNUM indicates that the error described by the primary return code refers to the SET protocol data value of the MerOrderNum.
This return code may be returned on RECEIVEPAYMENT or ACCEPTPAYMENT API commands. RC_SET_MERCHCATCODE indicates that the error described by the primary return code refers to the SET protocol data value for MerchCatCode.
This return code may be returned on RECEIVEPAYMENT or ACCEPTPAYMENT API commands. RC_SET_MERCHGROUP indicates that the error described by the primary return code refers to the SET protocol data value for merchGroup.
This secondary return code indicates that the problem described by the primary return code refers to the value of the $REQUIRECARDCERT protocol data field.
This secondary return code indicates that the problem described by the primary return code refers to the value of the $TRANSMETHOD protocol data field.
Since Payment Server version 1.2 was first shipped, we have discovered the need to allow certain values to be configured which originally were determined by the Payment Server. Support for specifying these configuration values has been added through the use of Java environment variables.
All environment variables are specified with the -D flag on the command line when Payment Server is started. Environment variable definitions should be inserted between "java" and "com.ibm.etill.ETill" on the command line. Here is an example showing the placement of environment variable definitions:
java -classpath $CLASSPATH
-Djava.compiler=off
-Dvariable1=value1
-Dvariable2=value2
com.ibm.etill.ETill
DBdriver=JDBC_driver_name
DBjdbcURL=JDBC_URL
DBOwner=Database_owner
DBUserID=Database_userid
DBPassword=$1
This variable can be used to change the read timeout value used when Payment Server reads data from a SET Wallet. The default is 30 seconds. The new value is specified in number of seconds.
When a SET message is sent from the Payment Server to the gateway, the message is carried as the body of an HTTP POST message. The first line of the HTTP message uses the following format, as specified by the External Interface Guide to Secure Electronic Transaction (SET).
POST URI HTTP/1.0
URI is the HTTP Uniform Resource Identifier which identifies the resource at the gateway which will receive the SET message. The Payment Server builds this URI using the values for gateway hostname and gateway port specified in the ETACQCFG acquirer configuration table as follows.
POST http://gatewayhostname:gatewayport HTTP/1.0
As mentioned in the HTTP RFCs, the format of a URI need not be that of a URL. Some gateways require a more detailed URI. To support this requirement, Payment Server will look for a Java environment variable defining the URI. Java environment variables are specified on the java command line using the -D flag. When an environment variable is used to specify the URI for a particular acquirer, all SET messages sent to that acquirer will use the specified value.
POST specifiedURI HTTP/1.0
Since the Payment Server can support many acquirers, and a URI is associated with a single acquirer, the name of the Java environment variable is used to identify the acquirer.
GatewayURI.MerchantNumber.AccountNumber
where MerchantNumber and AccountNumber
are the merchant number and account number from the Acquirer configuration (ETACQCFG) table.
To specify the URI for one or more acquirers, specify one or more URI environment variables on the command line using the -D flag when starting the Payment Server:
Example usage:
java -classpath $CLASSPATH
-DGatewayURI.123.888="http://hostname/cgi-bin/HiECG?protocol=SETV10_PAY&interface=credit1"
-DGatewayURI.456.999="http://hostname/cgi-bin/HiECG?protocol=SETV10_PAY&interface=credit1"
com.ibm.etill.ETill
DBdriver=COM.ibm.db2.jdbc.app.DB2Driver
DBjdbcURL=jdbc:db2:etill
DBOwner=etill
DBUserID=etill
DBPassword=pw
The eTill.Hostname environment variable is used to specify the Payment Server hostname.
By default, Payment Server 1.2 uses Java functions to get the fully qualified TCP/IP hostname of the machine on which Payment Server is running. This hostname is used by the SET Cassette to build the SET-SET-URL, SET-Query-URL, SET-Response-URL, and SET-Diagnostic-URL in the SET Payment Initiation (Wakeup) message. There is a documented bug in these Java functions. On some machines, Java returns a local hostname rather than the fully qualified TCP/IP hostname. When this shorter name is used in the SET URLs, the consumer's wallet cannot access the Payment Server unless the Payment Server is in the same TCP/IP domain.
This default behavior can now be overridden by specifying the hostname on the java command line when starting Payment Server. If the environment variable, eTill.Hostname, is defined, this value will be used everywhere hostname is used.
You may need to use the eTill.Hostname if one or both of the following applies:
Protocol Data is information passed on the Payment API which has meaning only to the payment cassette handling the request. The SET Cassette is shipped as part of the Payment Server and recognizes the protocol data described here. If you are using a payment cassette provided by a third party, refer to their documentation for protocol data information for that payment type.
Protocol data is specified as keyword/value pairs. The C interface provides C functions to help you build these pairs. If you are using the socket API directly you can build these pairs yourself according to the format described in the IBM Payment Server for AIX, Windows NT and Solaris, Programmer's Guide and Reference, V1.2 .
The Payment Server's SET Cassette now accepts $REQUIRECARDCERT as protocol data on the RECEIVEPAYMENT API command. This keyword is used to indicate that an incoming PReq from a Wallet must contain a cardholder certificate. If it does not, a SET Error message will be returned.
Valid values for this keyword are 0 and 1. "0" indicates that no cardholder cert is required. "1" indicates that the presence of a cardholder cert should be enforced by the Payment Server.
Note that in order to accept certless purchases, the gateway certificate must indicate that certless purchases are allowed. The $REQUIRECARDCERT keyword is used to enforce the presence of a cert even when the gateway allows certless purchases.
The Payment Server's SET Cassette now accepts $TRANSMETHOD as protocol data on the ACCEPTPAYMENT API command. This keyword is used to specify the value of the TransMethod field passed in the MIA (Merchant Initiated Authorization) extension. The TransMethod value is used to tell the gateway what type of transmission was used when the merchant collected card data from the consumer. The allowed values of this field are shown below.
When $TRANSMETHOD is not specified, the value MIA_otherElectronic=4 will be used.
The Payment Server's SET Cassette now accepts $MERORDERNUM as protocol data on the ACCEPTPAYMENT and RECEIVEPAYMENT API commands. The MerOrderNum filed is in the SaleDetail structure of CapReq and AuthReq (with capture now) messages. This value will be used on later SET messages.
The value specified should be a character string of length at most 24 characters.
Note: The requirement to use this field, if any, will come from the acquirer.
The Payment Server's SET Cassette now accepts $MERCHGROUP as protocol data on the ACCEPTPAYMENT and RECEIVEPAYMENT API commands. MerchGroup, is one of two fields in the merchData structure defined by the SET Protocol for the AuthReq message. When the merchant specifies this value on the API, the SET Cassette will use it when building the AuthReq message. This data will also be included in later SET messages because it is included in the authReqPayload.
The value for merchGroup should be a numeric string with values between "1" and "8." The semantics for the possible values are described in the SET specification.
Note: The requirement to use this field, if any, will come from the acquirer.
The Payment Server's SET Cassette now accepts $MERCHCATCODE as protocol data on the ACCEPTPAYMENT and RECEIVEPAYMENT API commands. MerchCatCode, is one of two fields in the merchData structure defined by the SET Protocol for the AuthReq message. When the merchant specifies this value on the API, the SET Cassette will use it when building the AuthReq message. This data will also be included in later SET Messages because it is included in the authReqPayload.
The value for merchCatCode should be a 4 character numeric string.
Note: The requirement to use this field, if any, will come from the acquirer.
The etAddProtocolDataString() function adds a keyword/data pair to the set of pairs managed by a ProtocolData structure. Use this API when creating protocol data that is printable (that is, string data, not binary data).
On EBCDIC-based platforms (such as, OS/390 and OS/400), this function translates the string data from EBCDIC to ASCII. On ASCII-based platforms (such as, Windows NT, AIX/6000 and Solaris), no such translation is required or performed, making this call functionally equivalent to etAddProtocolData. However, if you intend to write merchant programs that are portable across EBCDIC- and ASCII-based platforms, you should use this function for string data.
See "API Return Codes" in the IBM Payment Server for AIX, Windows NT and Solaris, Programmer's Guide and Reference, V1.2 .
This API call builds the format for a PROTOCOLDATA field as required by the Payment Server.
A new mechanism has been added to the Payment Server to avoid security exposures related to specifying the database password on the IBMPayServer command on AIX and Solaris. To use this mechanism, perform the following steps.
DBPassword = password
If this file exists in the Payment Server working directory, then the password specified in the file will be used. Otherwise, the name specified on the IBMPayServer command will be used. The DBPassword must be specified in one of these two places.
Note: You may also use this feature on NT, however, you may find it difficult to create a file with the name .payment. This is not a legal file name according to NT's Explorer. You can create this file with the Notepad editor by typing the command:
Notepad .payment
The IBM Payment Server now includes changes made as a result of SET compliance testing.
Compliance requires strict adherence to and enforcement of the SET protocol. Interoperability problems are possible between compliant levels of IBM Payment Server and other vendors products which have not completed their compliance testing.
The most significant compliance change to the IBM Payment Server is the manner in which it responds to improperly formatted messages. If a cardholder or acquirer sends a message that is not properly formatted (for example, required fields omitted, identifiers altered, certificates omitted), the Payment Server will respond with a SET Error message.
The IBM Payment Server now permits setting the acquirerBusinessID field to null in the ETBRANDCFG table.
Each acquirer has an entry in the ETACQCFG table to determine the properties of that acquirer, and the SETProfile field in that table determines how the IBM Payment Server interacts with the acquirer. Two new profiles, 10 and 11, have been introduced for interaction with gateways that have passed SET compliance tests. Profile 10 is used for acquirers where the merchant controls the batch ID, while profile 11 is used when the acquirer controls the batch ID. As always, contact your acquiring institution to determine the proper SETProfile setting.
When an AuthReq sets the SubsequentAuthInd field to true, the gateway is required to include an AuthToken in the AuthRes. The compliance changes caused this existing SET rule to be enforced by the Payment Server. IBM's 1.0 Payment Gateway must be at the 1.0.18 or later level to work with Payment Server 1.2.19 or later. IBM's 1.2 Payment Gateway must be at the 1.2.12 or later level to work with Payment Server 1.2.19 or later.
As of version 1.2.13, Payment Server will not store PanToken and CardExpiry in the ETSETMESSAGES database table by default. If you require these fields to be stored, you must take action by modifying the user exit library. (Net.Commerce customers cannot do this since Net.Commerce ships a modified user exit library.) To cause these fields to be stored, the UserExit_ApproveResponseReceived routine in the userexit lib must return the value UE_DEFINED and the new storeCardholderInfo field must be set.
The last two UEIO Fields:
short storeCardholderInfo;
char reserved[38];
storeCardholder Field Values
/* flag values for storeCardholderInfo */
#define UE_CARDHOLDERINFO_OMIT 0
#define UE_CARDHOLDERINFO_STORE 1
The storeCardholder value must be set by including the following statement in the UserExit_ApproveResponseReceived routine.
ueio->storeCardholderInfo = UE_CARDHOLDERINFO_STORE;
Note that the two bytes used for storeCardholderInfo were taken from the reserved bytes at the end of the structure. For this reason, previously compiled user exit libraries that ignore storeCardholderInfo should continue to work.
The ACCEPTPAYMENT and RECEIVEPAYMENT API commands accept a keyword called CHARSET. When using the 'C' interface, the etAcceptPayment and etReceivePayment functions accept a field in the OrderDescription structure called contenttypecharset. The 'C' interface library will use the value in this field as the value associated with the CHARSET keyword on the API command. The accepted length for this parameter has increased from 32 characters to 64 characters. However, only the first 32 characters will be stored in the ETORDER table CTYPECHARSET field. This change is added to support payment cassettes which wish to receive a value longer than 32 characters. The longer value will be used throughout processing of the ACCEPTPAYMENT or RECEIVEPAYMENT API command.
A number of error messages are missing from Appendix B of the IBM Payment Server for AIX, Windows NT and Solaris, Administration Guide, V1.2 . Many are new error messages added since GA. Others were inadvertently omitted. Documentation for these missing messages has been included with this service release in a file named messagesAddendum.html. This file can be found in the documentation directory along with other Payment Server HTML documents (such as, the IBM Payment Server for AIX, Windows NT and Solaris, Programmer's Guide and Reference, V1.2 ). Please use this file in conjunction with Appendix B of the IBM Payment Server for AIX, Windows NT and Solaris, Administration Guide, V1.2 to diagnose problems encountered when running the Payment Server.
This information is for payment cassette writers participating in the Cassette Kit beta program. The Cassette interface includes a method named batchesForAccount(). This method can be called by the cassette. The original version takes only the account number as a parameter.
batchesForAccount(String AccountNumber)
A second method by this name has been added which takes both merchant name and account number.
batchesForAccount(String merchantName, String accountNumber)
This is the preferred method. All new uses of the method should choose the two-parameter version. Existing calls to this method should be changed if possible.
As of version 1.2.6, the database migration tool will allow the 1.2 tables to be created in the database that contains the 1.0 tables.
Softcopy publications are contained in the installation package in both Portable Document Format (PDF) and Hypertext Markup Language (HTML) formats.
- After you install this product, you will find the following PDF-format publications:
The PDF files will be located in the following directories assuming that Payment Server was installed in the default location.
- Additionally, you will find the following HTML-format versions
The HTML files will be located in the following directories assuming that Payment Server was installed in the default location.
To view, navigate, and print PDF files, you will need the Adobe** Acrobat** Reader, available from the http://www.adobe.com/prodindex/acrobat Web site. The books in HTML format can be interpreted and displayed by Web browsers on any of the supported platforms. If you do not want the Adobe**Acrobat** Reader or a Web Browser on the same machine as the Payment Server, you may upload the document files to a system of your choosing, such as a PC, to view and print the files.
PTF |
AIX |
SUN |
NT |
APAR Description |
1.2.5 |
IW00136 |
IW00137 |
IR38515 |
Add PaymentType field to ETBATCH table. |
1.2.5 |
IW00143 |
IW00144 |
IR38576 |
Add capability to migrate database tables within an existing database: plus other changes for service update. |
1.2.8 |
IW00149 |
IW00160 |
IR38832 |
PaymentServer does autoAuth even if userexit changes approve amount to 0. |
1.2.8 |
IW00157 |
IW00161 |
IR38833 |
New Return codes if etAcceptPayment fails doing autoApprove or autoDeposit because the batchID is not valid |
1.2.8 |
IW00158 |
IW00162 |
IR38834 |
Migrate eTill 1.0 ETACQCFG record with GatewayProtocol of HTTPALT1 to a PaymentServer 1.2 ETACQCFG with SETProfile of 3. |
1.2.8 |
IW00159 |
IW00163 |
IR38835 |
Fixes made in SDK 1.2.8. |
1.2.8 |
IW00165 |
IW00166 |
IR38720 |
Certificate validation fails when merchantID in certificate request differs from merchantID in generated certificate. |
1.2.13 |
IW00172 |
IW00185 |
IR39054 |
SaleTransaction does not work for buyer using debit card. |
1.2.13 |
IW00176 |
IW00186 |
IR39055 |
Allow database password to be read from .payment file and not specified on IBMPayServer command |
1.2.13 |
IW00183 |
IW00192 |
IR39061 |
Allow user to set MerOrderNum in SaleDetail for a SET payment transaction |
1.2.13 |
IW00187 |
IW00195 |
IR38746 |
Allow the JDBC driver to be specified for IBMPayServerSetup utility. |
1.2.13 |
IW00188 |
IW00191 |
IR38968 |
Do not store PAN token in the ETSETMESSAGES database. |
1.2.13 |
IW00189 |
IW00190 |
IR39056 |
Allow setting of eTill.Hostname Java parameter for use in SET-SET-URL and SET-Response-URL |
1.2.13 |
IW00193 |
IW00194 |
IR39062 |
Various SDK fixes included in this PTF. |
1.2.13 |
IW00196 |
IW00197 |
IR39137 |
Retry of auto approved payment fails with NullPointerException |
1.2.13 |
IW00198 |
IW00199 |
IR39138 |
AcquirerBusinessID in ETBRANDCFG whose numeric value is greater than Java Integer.MAX_VALUE (around 2000000000) causes PaymentServer to terminate |
1.2.13 |
IW00200 |
IW00201 |
IR39139 |
GatewayHostname in ETACQCFG of more than 40 characters causes failed startup with error message CEPFW0725. |
1.2.19 |
IW00065 |
IW00184 |
IR39052 |
Pinquiry against order which is not in Payment Server DB doesn't result in OrderNotReceived Completion Code returned to wallet. |
1.2.19 |
IW00207 |
IW00219 |
IR39353 |
Memory Leak in "C" Interface functions. |
1.2.19 |
IW00217 |
IW00218 |
IR39043 |
The field CTYPECHARSET in the table ETORDER is too short. |
1.2.19 |
IW00215 |
IW00216 |
IR39352 |
Changes made to underlying SET Cassette libraries for PTF 1.2.19. |
1.2.19.1 |
IW00242 |
IW00243 |
IR39830 |
Net.Commerce userexit library overwritten |
1.2.19.1 |
IW00244 |
IW00248 |
IR39881 |
CEPSET0359 and "authToken required" errors |
1.2.19.2 |
IW00250 |
IW00252 |
IR40127 |
DBCS messages logged to eTillError contain garbage. |
1.2.19.2 |
IW00251 |
IW00253 |
IR40128 |
Exception: "violated internal assertion" when multiple merchants use same account number in ETACQCFG |
1.2.20.0 |
IW00209 |
IW00210 |
IR39308 |
SET Compliance |
1.2.20.0 |
IW00266 |
IW00226 |
IR40296 |
CEPSET0320 error when brandID includes product name. |
1.2.20.0 |
IW00247 |
IW00265 |
IR40295 |
CEPSET0718 error when SETProfile 6 used with Net.Commerce. |
1.2.20.0 |
IW00254 |
IW00261 |
IR40276 |
Payment Server crashes when garbage sent to payment port. |
1.2.20.0 |
IW00231 |
n/a |
IR38618 |
Create eTillcertreq, a bmp-enabled version of eecertreq |
1.2.20.0 |
IW00257 |
IW00262 |
IR40279 |
SETProfile 12 added to support specific acquirer. |
1.2.20.0 |
IW00258 |
IW00259 |
IR40269 |
Support new Merchant Initiated Authorization (MIA) SET extension. |
1.2.20.0 |
IW00263 |
IW00264 |
IR40294 |
3KP enforcement: Allow merchant to reject certless purchases even when gateway allows certless purchases. |
1.2.20.0 |
IW00267 |
IW00268 |
IR40299 |
Changes in SET messaging libraries (sdk) for 1.2.20.0. |
1.2.20.1 |
IW00269 |
IW00285 |
IR40811 |
Create CancelOrder API command. |
1.2.20.1 |
IW00273 |
IW00286 |
IR40812 |
InqReq before PReq causes CEPFW0207 |
1.2.20.1 |
IW00275 |
IW00287 |
IR40813 |
Check format of $MERORDERNUM. |
1.2.20.1 |
IW00277 |
IW00284 |
IR40809 |
Allow Payment Server to start when some merchants are misconfigured. |
1.2.20.1 |
IW00279 |
IW00290 |
IR40826 |
Improve configuration error messages, document fmttrace. |
1.2.20.1 |
IW00282 |
IW00288 |
IR40814 |
Restart crashes when batch open for deleted merchant. |
1.2.20.2 |
IW00278 |
IW00336 |
IR41454 |
Provide instructions for starting Payment Server in the background. |
1.2.20.2 |
IW00283 |
IW00318 |
IR41256 |
Allow timeout for read from wallet to be configured. |
1.2.20.2 |
IW00291 |
IW00319 |
IR41257 |
Migration of ETBATCH fails without good error message when configuration missing. |
1.2.20.2 |
IW00294 |
IW00320 |
IR41258 |
ReceivePayment method in ETillSocketAPI sample code uses wrong command value. |
1.2.20.2 |
IW00295 |
IW00321 |
IR41259 |
Requests to gateway should be retried after receiving an HTTP error response code. |
1.2.20.2 |
IW00296 |
IW00322 |
IR41260 |
PInitReq for canceled order requires SETError message response. |
1.2.20.2 |
IW00299 |
IW00323 |
IR41261 |
Batch table entries refering to non-existent acquirer configuration cause start to fail. |
1.2.20.2 |
IW00300 |
IW00324 |
IR41262 |
No error message in eTillError log when amount or order description in PReq differs from merchant's data. |
1.2.20.2 |
IW00301 |
IW00325 |
IR41263 |
Explanation of success URL added to readme. |
1.2.20.2 |
IW00317 |
IW00303 |
IR41255 |
Leading zero in currency code not displayed in sample GUI. |
1.2.20.2 |
IW00330 |
IW00333 |
IR41442 |
Use retry logic when null response received with HTTP 200. |
1.2.20.2 |
IW00331 |
IW00302 |
IR41440 |
eTillInitializeAPI() not thread safe on AIX and Solaris. |
1.2.20.2 |
IW00332 |
IW00307 |
IR41441 |
Net.Commerce orders stuck in pending state when message retries fail. |
1.2.20.2 |
IW00334 |
n/a |
n/a |
Y2K: Hardware Crypto: Ship new CDSA certificates: Document required CCA upgrade. |
1.2.20.2 |
IW00335 |
IW00337 |
IR41455 |
Corrupt paytrx.db prevents start. |
1.2.20.2 |
IW00338 |
IW00339 |
IR41456 |
SET message library changes for 1.2.20.2. |
1.2.20.2 |
IW00341 |
IW00342 |
IR41540 |
Allow multiple currencies in an implicit batch. |
1.2.20.3 |
IW00352 |
IW00353 |
IR41778 |
NullPointerException in SETBatch.addItem when batchid is null. |
1.2.20.3 |
IW00347 |
IW00354 |
IR41779 |
All transactions fail with 11,207 and CEPSET0155. |
1.2.20.3 |
IW00355 |
IW00356 |
IR41780 |
Delete paytrx.db only if corruption detected. |
1.2.20.4 |
IW00326 |
IW00417 |
IR43278 |
Fix 4K+ memory leak on PInit exchange. |
1.2.20.4 |
IW00405 |
IW00418 |
IR43279 |
New profiles 18, 19 - similar to 8, 9 with multi-currency support. |
1.2.20.4 |
IW00374 |
IW00419 |
IR43280 |
Add instructions to readme on "How to Delete a Merchant from the Database" |
1.2.20.4 |
IW00372 |
IW00420 |
IR43281 |
Some ACB (Acquirer Controls Batch) batches do not close on Payment Server. |
1.2.20.4 |
IW00154 |
IW00421 |
IR43282 |
New profile 105 - similar to 5 with multiple currency support. |
1.2.20.4 |
IW00351 |
IW00422 |
IR43283 |
JNI panic when issueing an acceptpayment with autoauth. |
1.2.20.4 |
IW00169 |
IW00423 |
IR43284 |
To purge the database of all configuration and transaction data for a given merchant, follow these instructions in this order. Replace XXX with the number of the merchant you are deleting.
When a consumer uses SET to make a purchase, the last message they receive from the Payment Server is the Payment Response (PRes). The PRes carries a CompletionCode with the status of the message. The IBM Wallet will redirect the browser to either the success, failure, or cancel URL, depending on the value of this CompletionCode. The possible values of the CompletionCode, the meaning of each value, and the URL displayed are detailed in the table below.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In most situations, the behavior of the wallet is straight-forward
and easy to understand.
There is however one scenario that results in behavior that
many people find confusing.
This confusion results when the merchant attempts to send
the Authorization Request (AuthReq) to the gateway but receives no response.
This could happen when there is a communication error or an error at the
gateway which prevents it from sending the Authorization Response (AuthRes)
back to the merchant.
In this case the Payment Server does not know whether the authorization
completed successfully at the gateway, was rejected by the gateway,
or failed to be processed by the gateway at all.
The only correct CompletionCode in this case is orderReceived.
The CompletionCode cannot be set to orderRejected or authorizationPerformed
since no AuthRes has been received which would provide this information.
The order has been successfully received and the Authorization may be sent
again later using the automatic retry logic in Payment Server.
Neither the merchant nor the consumer can know the status of the
authorization until an AuthRes has been received.
The consumer browser will be directed to the Success URL.
If a merchant wishes to provide detailed information about the state of the order,
the success URL can be the address of a CGI program. The CGI program can read the
order number from the URL and use it to look up the status of both the order and
the payment in the Payment Server database. This information can be used to
present a more complete description of the status to the consumer. For instance,
in the situation described above, the consumer might be presented with a message
which says "Your order has been received. Authorization is pending with your
financial institution. Check back later for authorization status".
Some acquirers require that a batch contain transactions for only a
single brand. When the merchant controls the batch, the merchant
can accomplish this easily by using multiple calls to OpenBatch and
setting the batchID according to brand. But when the acquirer controls
batch, the Payment Server only supports one open batch per acquirer
as defined by a single entry in the ETACQCFG table.
The following configuration can be used when the merchant clears multiple brands with
an acquirer who both controls the batch and requires that
only one brand be included in a batch.
Configure one ETACQCFG entry per brand.
All of these ETACQCFG entries will describe the same physical acquirer.
The only difference will be the account number and the signing BrandID.
When a CANCELORDER command is received, the Payment Server Framework
will remove the Order and associated Payment information from the
in-memory cache and will delete all related data from the ETORDER
and ETPAYMENT tables. It will also forward the cancel command to
the payment cassette. The cassette will delete the associated
payment-specific data. The SET Cassette will delete all related
records in the SETOrder, SETPayment, SETCredit, BinaryData,
and SETMessages tables.
CANCELORDER will not be accepted if the Order is in Pending state.
In addition, CANCELORDER will not be accepted for any Order which has
associated Payments unless those payments are in Void or Declined state.
The CANCELORDER command in Payment Server 1.2 will not change the
state of the Order.
A new secondary return code, RC_DELETEORDER, value 165,
has been added for the CANCELORDER command. RC_DELETEORDER will
be returned if the value of the deleteOrder flag is not equal to 1.
The following table shows the parameters used with the CANCELORDER command.
See the Chapter 5 of the
IBM Payment Server for AIX, Windows NT and Solaris, Programmer's Guide and Reference, V1.2
for a complete description of the
Payment Server's socket based API.
The etCancelOrder() function sends a CANCELORDER command to the Payment Server.
The Payment Server logic has been changed so that it will start as long as there
is at least one correctly configured merchant. When configuring a merchant for
SET, correctly configured means that the merchant has defined at least one brand
and has valid certificates for all configured brands.
Formerly, Payment Server would stop if an error was found with any configured merchant.
Error messages for the following common configuration errors
will now be logged to eTillError.
Formerly the data available to debug these problems was buried
in the eTillSETMsgDump.x dump files making them very
difficult to debug.
These messages will be displayed in English on all systems.
The eTillSETMsgDump files are binary files intended
for use by IBM service personel.
These files can be found in the log directory after certain
types of errors. (The log directory is specified by the LogPath field in
the ETILLCONFIG database table.)
Most errors reported in these files can only be resolved by IBM service.
There are however, certain errors that can be resolved by the user
and can only be understood by looking at the error messages in these dump
files.
We are providing instructions for formatting and finding the error
messages for those of you who want to take an
extra step to resolve your own problems before contacting IBM service.
The utility fmttrace can be found in the directory tree where
Payment Server is installed.
The FastForward JDBC driver for Microsoft SQL Server 6.5** from Connect Software
is no longer available.
BEA WebLogic JDBC drivers from BEA Systems Inc.** are available for SQL Server.
If you are using the WebLogic JDBC driver, enter the following settings
when using the IBMPayServerSetup wizard to setup your database:
JDBC class name: weblogic.jdbc.mssqlserver4.Driver
JDBC URL: jdbc:weblogic:mssqlserver4:database name@hostname:port
If you are writing to the Payment Server API using Java, take a look
at the sample file ETillSocketAPI.java.
ETillSocketAPI has methods which build each of the socket API commands.
SETProfile is a field in the ETACQCFG database.
Its value tells the Payment Server how to use the optional
parts of the SET Protocol when sending messages to the acquirer.
Acquirers use SET in a variety of ways.
In some cases, acquirers require merchants to use particular optional fileds or messages.
In other cases, acquirers do not allow merchants to use particular optional fields or messages.
In addition, different acquirers have interpreted parts of the SET specification
differently.
Payment Server needs to be able to work in each of these different ways.
The SETProfile field
encodes these differences in the Payment Server's configuration. To determine
the value to put in the SETProfile field, you must consult with your
acquirer and determine which profile corresponds to the behavior expected
by that acquirer.
Acquirer Setting Technical Meaning AuthToken If the acquirer will build an authToken when the
AuthReq contains subsequentAuthInd=true, then this setting can be true.
Authtokens are required to support split payments. Batch Control If the acquirer assigns batch IDs on
Capture/CaptureRev and Credit/CreditRev response messages, this value is true.
This situation is often referred to as "acquirer controls batch". If the
acquirer expects the merchant to issue batch open and batch close commands
and to assign batch ids, then this setting is false. This situation is
often referred to as "merchant controls batch". Sale Transactions If the acquirer can accept and process an AuthReq with CaptureNow=true to both authorize and capture a payment with one message, then this setting is true AuthRevReq MessageIDs True if the acquirer expects to receive message IDs in the AuthRevReq message wrapper. Merchant Requests Totals If the acquirer expects the merchant to always request totals on the batch admin close message, then this setting will be true CapRev Amount is New Amount. If the acquirer interprets the CapRevOrCredReqAmt field in the CapRevReq
as the new amount of settlement, (new capture amount), then this setting is true.
If the acquirer interprets this as the full reversal amount then this setting is false.
Note: On March 30, 1999 a dispute resolution board statement was issued declaring this
to be the full reversal amount. Multiple Currencies per Batch This setting is true when the
acquirer puts transactions for multiple currencies in a
single batch. Customized Profile. There are so many possible combinations of
the various optional fields in SET messages, that sometimes we find an acquirer who
cannot work with any of our profiles.
Customized profiles were created for these acquirers.
Behavior not described by one of the above settings may also be associated
with a customized profile.
Acquirer Settings SET Profile Number . 101 102 103 104 105 1 2 3 4 5 6 7 8 9 10 11 12 13 18 19 AuthToken T T T . . T T . . . T T . . T T . . . . Batch Control . T T T T . T . . T . T . T . T . . . T Sale Transactions T T T T . . . . . . T T T T . . . . T T AuthRevReq MessageIDs T T T T . . . . . . . . . . T T . . . . Merchant Requests Totals T . . . . T . . T . T . T . T . T . . . CapRev Amount is New Amount. . . . . T T T . T T T T T T T T . . T T Multiple Currencies. . . T T T . . . . . . . . . . . . . T T Customized Profile. . . . . . . . T . . . . . . . . . T . .
Acquirer Settings Merchant Implications AuthToken When true, merchant can choose to perform multiple
authorizations against the same order by setting the SplitAllowed flag to true on
the Approve API command. Batch Control When this is true, the merchant must not use the
BatchOpen and BatchClose API commands and must not specify batchID on the
Deposit, DepositReversal, Credit and CreditReversal API commands.
When this is false, the merchant is required to use the BatchOpen and
BatchClose API commands and is required to specify batchID on the Deposit, DepositReversal,
Credit and CreditReversal API commands. Sale Transactions When this is true and the merchant specifies autoDeposit on the AcceptPayment, ReceivePayment or Approve commands, the AuthReq will set the CaptureNow flag to true. When this is false and the merchant specifies autoDeposit on the AcceptPayment, ReceivePayment or Approve commands, the AuthReq will set CaptureNow to false and will be followed by a CapReq message without further input from the merchant. AuthRevReq messageIDs No impact on merchant behavior. Merchant request totals Payment Server will always request totals on the
batch close when this is true. If the totals do not match, the batch will not close. CapRev amount is new amount. No impact on merchant behavior.
Payment Server will interpret the Deposit Reversal amount appropriately. Multiple currencies per batch.
This is an essential setting for merchants who accept multiple currencies and
use an acquirer which controls the batch and puts transactions
for multiple currencies in the same batch. Customized profile. Use only when specified explicitely by your acquirer.
The settings for customized profiles are not published and are subject to change based on
the needs of a particular acquirer.
The list of SET profiles and the behaviors that can be specified in the profiles
will continue to change as new acquirers support SET and undergo interoperability
testing.
Batch reconciliation is the process of adjusting the
merchant's and/or gateway's view of the batch until
they agree.
When the batch totals exchanged on a SET batch close message indicate
that the totals do not agree, action is required.
The merchant needs to work directly with the acquirer
to determine the cause of the discrepancy.
In the pre-Internet, point-of-sale world, this was frequently done via phone.
When a merchant establishes a business relationship with an acquirer,
provision is made for dealing with errors of this type.
The merchant should follow the procedures specified by the acquirer
to determine the problem.
The merchant can use the data in the Payment Server database to create
a batch content report.
This data can be used while working with the acquirer to find the problem.
Once the merchant and acquirer have identified the missing,
and/or inaccurate transactions, the merchant must choose how to correct
the problem. In some cases, the merchant will be able to use the Payment Server
to make corrections to these transactions.
The batch has remained open since the totals did not match.
The merchant can issue any of the payment commands necessary to correct the batch contents.
Reversals can be used to correct the amounts of specific transactions or remove them entirely.
New Deposit and Credit API commands can be issued to add missing transactions.
After these transactions are made, the merchant can try again to close this batch.
This process can be repeated until the totals match.
The splitAllowed flag is accepted as a parameter on the Approve and ApproveReversal API commands.
It is also included with the autoApprove options on ReceivePayment and AcceptPayment.
This flag is an indication to the Payment Server of the merchant's intention to split the payment.
The SET Cassette does not translate this flag directly into the setting of the subsequentAuthInd in the
AuthReq message.
Rather, it uses the flag as a hint of what may come.
There are cases where the SET Cassette will set subsequentAuthInd to true even when splitAllowed is
false.
This is true for all AuthRevReq messages and for any AuthReq messages issued after a complete reversal.
If the SETProfile in the ETACQCFG table indicates that the Acquirer does not support split (authtoken),
the subsequentAuthInd flag will never be set to true.
See the section on SET Profiles in this README file for a complete list of currently supported profiles
and their characteristics.
The use of sale transactions by the SET Cassette is controlled by the configured Acquirer SET Profile.
Sale transactions are combined authorization and capture messages.
When the SET Profile configured in the Acquirer Profile specifies the use of SaleTransactions, all uses of
autoDeposit will result in a combined authorization and capture request.
For instance, if the ReceivePayment call specifies autoApprove and autoDeposit, and the SET Profile configured for
Acquirer indicates that this acquirer supports sale transactions, then the ReceivePayment call will cause an
Authorization Request with the CaptureNow field set to true to be sent to the Acquirer. Also, if the Approve API
command specifies autoDeposit, the Approve command will cause a sale transaciton to be sent to the Acquirer.
See the section on SET Profiles in this README file for a complete list of currently supported profiles
and their characteristics.
As of version 1.2.19,
the database migration utility will take into account the 1.0 SaleTransaction field in the
ETACQCFG table. If SaleTransactions is true in the 1.0 configuration, the SETProfile field in the 1.2
ETACQCFG table is set to 7. This profile will cause the CaptureNow flag in the
AuthReq message to be set to true when the merchant sets the autoDeposit flag to true
on a Payment Server API command.
See the section on SET Profiles in this README file for a complete list of currently supported profiles
and their characteristics.
Configuring Payment Server for one brand per batch.
Overview
Payment Server customers have expressed the need to cancel
an order so that no further action can be taken and so that the
data is removed from the database.
This need arises in several situations.
Here are three examples.
Description
Name
Required or Optional?
Value
OPERATION
R
ASCII character string "CancelOrder"
ORDERNUMBER
R
Integer in ASCII characters. Must be from 1 to 999999999.
MERCHANTNUMBER
R
Integer in ASCII characters. Must be from 1 to 999999999.
DELETEORDER
R
Indicates that the order and all related data should be deleted from the database. 1 is the only valid value for Payment Server 1.2. The data will always be deleted.
ETAPIVERSION
R
2 (Indicates Payment Server Version 1.2 initial GA version.) The length of the string is the number of significant digits. (There is no need to pad on the left with zeros.)
'C' interface to the Payment Server CANCELORDER Command
etCancelOrder()
Description
Syntax
long etCancelOrder(
PaymentServerHandle handle,
Key* keys,
ProtocolData* protocoldata,
long* secondaryrc,
ReturnData* returndata);
Parameters
handle
Handle identifying the session with the merchant server.
For details, see "Handles" on page 23 of the
IBM Payment Server for AIX, Windows NT and Solaris, Programmer's Guide and Reference, V1.2
.
keys
Structure containing orderNumber and merchantNumber.
For details, see "Key" on page 26 of the
IBM Payment Server for AIX, Windows NT and Solaris, Programmer's Guide and Reference, V1.2
.
protocoldata
Specifies any protocol-specific data the payment cassette
requires in order to process the API call.
Refer to the documentation for the payment cassette
you are using to determine what information should be included.
The SETCasssette does not require or allow protocol data with
the CANCELORDER command.
secondaryrc
Optional secondary return code.
A new secondary return code, RC_DELETEORDER,
value 165, has been added for the CANCELORDER command.
RC_DELETEORDER will be returned if the value of the
deleteOrder flag is not equal to 1.
Since the etCancelOrder() function inserts the
deleteOrder and always sets its value to 1,
this return code should never be received when using the
'C' interface to the API.
returndata
Structure containing data and length. For
details see "ReturnData" on page 28 of the
IBM Payment Server for AIX, Windows NT and Solaris, Programmer's Guide and Reference, V1.2
fmttrace eTillSETMsgDump.3 > 3.out
where database name, hostname, and port are replaced with your settings (port default is 1433).
SET Profiles
The following table describes the acquirer behavior encoded in a SETProfile.
This next table describes the possible settings for the SETProfile entry
in the ETACQCFG (Acquirer Configuration) database table. The letter 'T' in
the table below indicates that the acquirer option is supported for the profile.
This third table explains the implications of each setting for merchant behavior.
Batch Reconciliation
The splitAllowed flag and the SET subsequentAuthInd
Enabling Sale Transactions
Migrating SaleTransaction flag
IBM Payment Server 1.2.20.0 is the first full refresh of IBM Payment Server 1.2. The refresh replaces the original 1.2.0.0 version on CDs shipped to new customers. A PTF version of 1.2.20.0 is available to existing customers. 1.2.0.0 is a prerequisite for the PTF version of 1.2.20.0.
The functional content of the refresh and the PTF are identical. They include all bug fixes and enhancements made to the 1.2 product since 1.2.0.0. 1.2.20.0 is a prerequisite for all PTFs which follow.
The version number will no longer be tied to the service level of the SET messaging libraries (SDK).
The Readme file shipped with the 1.2.20.0 refresh was translated into 9 languages. This file, REFRESH_1.2.20.0_README.html can be found in the Payment Server installation directories. The Readme file shipped with each following PTF will be named PTF_README.html. It will include cumulative modifications to the 1.2.20.0 Readme file.
The SET message library (SDK) underlying the SET Cassette uses temporary file space when pruning the paytrx.db. This file is used to store information about the SET messages for a short period of time. Old messages are pruned from this database once an hour. During the pruning, the messages which will remain in the file are written to temporary space. These temporary files are deleted when the pruning operation is complete. The temporary file space must be large enough to handle this activity without running out of space. The actual space required will depend on the number of transactions processed per hour.
The temporary directory is determined by calling the C tmpfile() function.
This function returns the system default temporary directory. On AIX, this
is /tmp. On Solaris, it is /var/tmp.
And on NT, it is the current directory of the current drive, that is, the directory
from which Payment Server was started. (Prior to PTF 1.2.20.2 the root directory
of the current drive was used as temporary space on NT.)
It has been reported that in certain DBCS environments (Japanese and Korean) the backslash character (\) is being corrupted when read from the database. Specifically, the backslash character may appear in the LogPath field in the Payment Server Configuration Profile and in the CertFlatFilePath and SETFlatFilePath fields in the SET Configuration Profile. Note: These fields are described in the section "Required and Optional Fields in Database Tables" in the IBM Payment Server for AIX, Windows NT and Solaris, Administration Guide, V1.2 .
If you encounter this problem, it is recommended that you replace the backslash character with the forwardslash (/) character until a permanent solution is developed.
A new field was added to the Payment Server database tables in version 1.2.5. The new field name is PAYMENTTYPE. It has been added to the ETBATCH table. If your Payment Server database does not contain this field, action is required. Payment Server will fail on startup with error message CEPSET0202 if the new field does not exist in the database.
If you are creating the database tables for the first time, and you have a 1.2.5 or later version of the Payment Server installed, no special action is required. You need only follow the instructions in the IBM Payment Server for AIX, Windows NT and Solaris, Administration Guide, V1.2 for installing and configuring Payment Server. The versions of the utilities (TableMgr and IBMPayServerMigrate) shipped with PTF 1.2.5 and later will create the right version of the database tables the first time.
However, if your Payment Server database tables were created before version 1.2.5, the PAYMENTTYPE field will not be present in the ETBATCH table. You will need to take action the first time you install a version of the Payment Server equal to or greater than 1.2.5
The following Java class and database scripts are provided to aid you in adding the new field:
To add the field, the Payment Server class TableMgr must be executed with one of the AddDatabaseColumns script files. Before executing TableMgr, it is recommended that you backup the Payment Server's database. The Payment Server must be stopped while the modification is made. The script files will add the value "SET" to the PAYMENTTYPE field for every entry in the ETBATCH table. The syntax for invoking TableMgr is:
java -classpath $CLASSPATH
-Djava.compiler=off TableMgr
AddDatabaseColumn_script
JDBC_URL
JDBC_driver_name
Database_userid
Database_Password
Make sure that the values for database_java_driver, JDBC_driver_name, JDBC_URL, Database_userid, and Database_Password are the same as the values set in the script to invoke the Payment Server. When using Sybase SQL Anywhere, replace AddDatabaseColumn_script with "AddDatabaseColumns.sybase". When using any other database product, replace AddDatabaseColumn_script with "AddDatabaseColumns."
Due to a minor memory overlay problem on AIX that may impact Payment Server execution, it is recommended that service be applied to the AIX operating system:
The SDK used by IBM Payment Server 1.2 requires that you have xlC 3.1.4.8 or later. You may get a loadlibrary error without this level of xlC. The loadlibrary will fail trying to resolve the symbol __CurrentException. You may requst PTF U453697 to get to the required xlC service level.
Two different Y2K related problems have been found in hardware crypto support.
The CDSA libraries used by this level of the Payment Server require a 4758 CCA software level of at least 1.3.1. If your CCA software level is earlier than 1.3.1, you must upgrade immediately.
Note: Use lslpp -L csuf.com to determine your current level.
If you are installing this software update over a currently installed CommercePOINT eTill 1.0 or over Payment Server 1.2.0 (Payment Server 1.2 with no service applied), then you must deinstall and reinstall the CDSA libraries before starting the Payment Server or using eTillcertreq. If you fail to do this, the Payment Server or eTillcertreq will fail at the point of SetAPI initialization. To deinstall and reinstall:
An important note concerning 4758 CCA key storage locations and how the key storage may be affected during an upgrade to a new release of CCA software:
When you run the csufcnm utility, you will initialize the 4758 key storage directories and database. By default, this database is located under the /usr/lpp/csuf/csufkeys directory. It is recommended that you specify a different directory in order to ensure that your key storage is never overwritten or erased during a 4758 CCA software upgrade. (This can happen when upgrading to a new CCA release). We suggest keeping the key storage under the home directory of the userid under which the Payment Server runs (for example, /home/IBMPS/csufkeys).
Also note that once you've completed the key storage initialization step through csufcnm, you must notify CCA of the location by using the csufkeys utility which is supplied with the 4758 CCA support program.
If your 4758 is already installed and in use, you already have an active CCA key storage database. If this database is in the default location as defined by the csufcnm utility (/usr/lpp/csuf/csufkeys), it is important that you backup or relocate the database before upgrading to a new release of the 4758 CCA software since installation of a new release will overwrite the default CCA keys directories.
It is recommended that you first copy the entire /usr/lpp/csuf/csufkeys directory to another location (as a backup) and then relocate the database using the csufkeys utility. We recommend keeping the key storage under the home directory of the userid under which the Payment Server runs (for example, /home/IBMPS/csufkeys).
PTFs U300064 and U300113 introduced new versions of the CDSA libraries which are used in conjunction with the IBM 4758 Cryptogoraphic Coprocessor. CDSA must be deinstalled and reinstalled after applying one of these PTFs. In support of these new libraries, the CDSA installation and deinstallation procedures in chapter 5 change as follows:
Under the subheading "Adding CDSA Objects" the installation procedure changes to:
cd /usr/lpp/IBM_Payment_Server/cdsa
./CDSAforPS install
Under the subheading "Deleting CDSA ODM Objects" step 3 becomes:
3. ./CDSAforPS uninstall
The libetillapi.a library was created with the following compiler:
Merchant software written in C or C++ which uses the Payment Server C interface, must be compiled and linked with a compiler capable of linking libetillapi.a. We have only tested merchant programs created with the compiler named above.
To start any program in the background on AIX or Solaris run it using the standard unix utility nohup. For example:
nohup IBMPayServerYou can then close the window or log out of the machine and Payment Server will continue to run. Output will be redirected to a file named nohup.out.
Payment Server should be closed by using the documented STOP command. Using the kill command to stop the process can result in unreleased TCP/IP ports which require a reboot to clear.
The STOP API command is documented on page 75 of the Programmer's Guide. The STOP command can also be accessed via the 'C' interface function, etShutdowTill(), documented on page 54 of the Programmer's Guide. The sample GUI Administration panel provides a working example of how the STOP command can be integrated with a web-based admin interface.
If you are running Solaris 2.5.1, you will need the following patches to support the Java JRE 1.1.5 Native Threads package:
The IBM Payment Server relies on the native thread implementation in Java. If green threads are specified, the Payment Server will not run. Specify native threads by using the -native option on the command line.
Merchant software written in C or C++ which uses the Payment Server C interface, must be compiled and linked with a compiler which is able to link libetillapi.a. We have only tested merchant programs created with the compiler named above.
See information under this heading in the AIX section above.
Before running the installation process (setup.exe) on a Windows NT system, it is recommended that you apply Service Pack 3.
If you do not apply the service pack, the error message, "Can't run 16-bit Windows program : The path x:\ETILL1~B.NT\SETUP.EXE is invalid," may be displayed and the installation process will fail.
To run eTillcertreq, you will need to install iconv. To install iconv, do the following.
iconv -d
The etillapi.lib library was created with the following compiler:
Merchant software written in C or C++ which uses the Payment Server C interface, must be compiled and linked with a compiler which is able to link etillapi.lib. We have only tested merchant programs created with the compiler named above.
Payment Server 1.2.20.2 includes a new utility program to help you set up Payment Server as an NT service. This program can be found in the directory where Payment Server was installed. Follow these instructions to create Payment Server as a service on your NT machine.
SRVIBMPayServer -installTo remove the Payment Server service use the -remove flag.
SRVIBMPayServer -remove
The following terms are trademarks of the IBM Corporation in the United States or other countries or both:
SET Secure Electronic Transaction, Secure Electronic Transaction, SET and the SET Secure Electronic Transaction design mark are trademarks and service marks owned by SET Secure Electronic Transaction LLC(SETCo). License holders and IBM Business Partners of IBM software that uses the SET protocol must follow the trademark usage guidelines published by SETCo. These are available on their web site at http://www.setco.org. Use of the SET marks outside of these guidelines require a separate written license from SET Secure Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks of others.
THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. IBM DISCLAIMS ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE AND MERCHANTABILITY WITH RESPECT TO THE INFORMATION IN THIS DOCUMENT. BY FURNISHING THIS DOCUMENT, IBM GRANTS NO LICENSES TO ANY PATENTS OR COPYRIGHTS.
Note to U.S. Government Users - Documentation related to restricted rights - Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.