*************************************************************************** ** COPYRIGHT (c) 2004 BY TRI-8, INCORPORATED. ** ** A L L R I G H T S R E S E R V E D. ** *************************************************************************** OneStep Charge Version 2.1 RELEASE NOTES This document describes caveats and other important notes for the release named above. Please read this document carefully and consider all of the items discussed. 1) This release brings Purchase Card Level III support to OneStep Charge, for CCA_PURCHASE transactions on the TSYS platform. PC III allows a merchant to specify additional information about an order, such as the commodity code, shipping and handling, duty, and discount, as well as the fields from PC II (PO number, tax, ship-to ZIP code). In addition, the merchant can supply order line information. PC III data appears on a cardholder's statement and assists corporate purchase departments in reconciling and tracking expenses. 2) Changes to tri8osc/oscapi have been made to add the new PC III fields (and one PC II field: shipToZip). Users upgrading from releases of OneStep Charge prior to 2.1 must merge any changes they have made in tri8osc/oscapi with the tri8osc/oscapi found in the 2.1 distribution. That is, use the 2.1 version of tri8osc/oscapi, but port in your customizations if you have made any. 3) An additional, optional, alternative OSCBroker module is now supplied: OSBrokerSS.jar. This broker causes OSC to produce only one settlement per day, instead of N settlements, one for each of the N processing nodes that the broker accessed during that given day. An important tradeoff for this functionality is that the multiple-redundant OSC Engine infrastructure will not be used by OSCBrokerSS.jar. Instead, it will force all transactions to a single node. This may affect performance or availability. OneStep Charge Version 2.0d RELEASE NOTES This document describes caveats and other important notes for the release named above. Please read this document carefully and consider all of the items discussed. 1) This release is an update merely for OSCBroker.jar. To implement, shut down your currently-running OSCBroker, then replace OSCBroker.jar with the version in this release. Then, start the OSCBroker. No other changes or actions are necessary. OneStep Charge Version 2.0c RELEASE NOTES This document describes caveats and other important notes for the release named above. Please read this document carefully and consider all of the items discussed. 1) Minor changes to tri8osc/oscapi have been made, including changes that affect functionality. Users upgrading from releases of OneStep Charge prior to 2.0c must merge any changes they have made in tri8osc/oscapi with the tri8osc/oscapi found in this release. That is, use the 2.0c version of tri8osc/oscapi, but port in your customizations if you have made any. OneStep Charge Version 2.0b RELEASE NOTES This document describes caveats and other important notes for the release named above. Please read this document carefully and consider all of the items discussed. No release notes for this release. OneStep Charge Version 2.0 RELEASE NOTES This document describes caveats and other important notes for the release named above. Please read this document carefully and consider all of the items discussed. 1) The CCA_VOID action has been REMOVED from OneStep Charge as of Version 2.0, as has the status value CCS_VOID. Programs that make use of CCA_VOID or CCS_VOID will receive compiler errors. The OneStep Charge Engine infrastructure can no longer support the removal of items from the open batch. In place of this functionality, users are advised to use CCA_CREDIT transactions to offset CCA_PURCHASE or CCA_AUTHONLY+CCA_CAPTURE transactions. The obvious disadvantage is that two transactions (a debit and a credit) will appear on cardholder statements, but the net effect is still the same as a CCA_VOID operation. 2) The CCA_SETTLEBT action has been REMOVED from OneStep Charge as of Version 2.0. Programs that make use of CCA_SETTLEBT will receive compiler errors. In place of CCA_SETTLEBT, OneStep Charge now AUTOMATICALLY settles open batches. This automatic settlement occurs at 20:00 (8 p.m.) Pacific Standard Time (PST), and the settlement servers do adhere to Daylight Saving Time. Thus, during Daylight Saving periods, the settlement time is 20:00 Pacific Daylight Time. This new capability in OneStep Charge ensures that open batches are not left unsettled past 24 hours, ensuring that delayed-settlement merchant account surcharges are avoided and that funds flows consistently, regardless of the scheduling infrastructure and reliability of OSC host hardware and OS software. 3) Note that the CCExec temp-table, upon which OneStep Charge is built, has been RENAMED to trExec, to better fit the multiple transaction execution types that OneStep Charge now supports, such as ACH. A buffer for trExec called CCExec has been declared in order to facilitate backward-compatibility, but PLEASE BEWARE of using both CCExec and trExec naming in a single program, as these may (by definition) retrieve different records simultaneously, since CCExec is now a defined buffer for trExec. 4) Note that the new cardholder data fields in the trExec table, such as CHPhone, CHEmail, and so forth, are NOT required for Address Verification Service (AVS) operation on credit cards. Furthermore, these fields are not even passed to the AVS system. Rather, the fields are merely for extra data tracking and handy use as additional fields. 5) The following trExec fields can NO LONGER be used as query parameters when running CCA_QTRANS queries: * trExec.comment * trExec.source * trExec.operator Specifying values for these fields in a CCA_QTRANS operation will have no effect on the results (e.g. the results will not be filtered by the field value). 6) The masking of credit/debit card account numbers has changed. OneStep Charge will now return only the last 4 digits of the number for status requests. The CCMask function can be used to mask full-length values appropriately, and has been updated for this masking. For example, CCMask("1234567890123456") will return "XXXXXXXXXXXX3456" as the masked value. A CCA_STATUS request to OneStep Charge would return merely "3456" for this example card (no "X" characters). You may either just use the last four digits, or you may make use of the provided CCMask function to store the original length of the card number, because the number of "X" characters plus the clear-text final 4 digits does equal the total card number length originally supplied. 7) Not all of the many available trExec fields will be returned on queries and status requests. For example, the trExec.PONo and trExec.tax fields, though being valid for transactions proper (e.g. CCA_PURCHASE), are not stored in the OneStep Charge Engine and will not be populated into trExec records on CCA_STATUS/CCA_QTRANS operations. 8) The trExec.comment and trExec.source fields will not be passed to the OSC Engine on CCA_CREDIT and ACHA_CREDIT/ACHA_PURCHASE transactions. If values are supplied for these fields, they will be ignored. 9) The trExec.amount field is no longer modified in demo mode, though the transaction is still run via a demo/development infrastructure. 10) The trExec.amount value must be greater than or equal to $1.00 (for US Dollar transactions), or equivalent denomination for other currencies. 11) OneStep Charge now enforces a 14-day window for pre-authorized (CCA_AUTHONLY) transactions. After 14 days, the transaction can no longer be captured (CCA_CAPTURE). If you wish to capture on a transaction older than 14 days, simply re-run a new CCA_AUTHONLY and then CCA_CAPTURE it, or run a CCA_PURCHASE (no separate CCA_CAPTURE execution needed in that case). 12) The outstanding new OneStep Charge Engine infrastructure includes some separation for querying/status requests as opposed to the triple-redundant transaction execution infrastructure. When an actual transaction (CCA_AUTHONLY, CCA_PURCHASE, etc.) is run, it may take up to 5-10 seconds for this transaction to replicate into the query infrastructure. So, for example, running a CCA_CAPTURE followed *immediately* by a CCA_STATUS request might indicate that the old amount (and CCS_AUTHONLY) still apply, but pausing 5-10 seconds will show that the status is indeed CCS_RTS (assuming successful capture) and the amount is as expected. 13) The new OSCA_VERSION and OSCA_BROKERCHK administrative actions must be used ALONE in the trExec table. All other records will be ignored. For example, if you create a trExec row with trExec.action = OSCA_BROKERCHK and then create more trExec rows with CCA_AUTHONLY, CCA_CREDIT, etc., ONLY the trExec row that is the OSCA_BROKERCHK row will be executed. The other rows will be ignored. 14) CCA_CAPTURE operations must now reference the OSCID to capture, RATHER THAN THE TRANSNO. The trExec.transNo field should still be used, as it is used to index the trExec table on calls to OneStep Charge and is likely used in your local database table for permanent transaction storage, but the trExec.OSCID field is the field that will specify to the OneStep Charge Engine which transaction to capture. PLEASE NOTE THIS AND UPDATE YOUR CODE APPROPRIATELY. If you do not supply the OSCID field (e.g. it is left blank), then you will receive an error (CCS_ERR) when attempting to capture. 15) The OSCConfig.CCTimeout field has been RENAMED to OSCConfig.defaultTimeout to more generally fit multiple transaction types (beyond credit cards). 16) Transaction dates and times (trExec.authDate, authTime, settleDate and settleTime) are expressed as Pacific Standard Time values (Pacific Daylight Time during Daylight Saving Time periods) (PST time zone is UTC/GMT -0800). The exception to this is at actual transaction execution time. When a standard transaction is run, trExec.authDate and trExec.authTime are set to, basically, "today" and "time" (Progress keywords) when the transaction finishes, as they have always been in OSC. This means that the date and time at transaction execution time do match the OSC host system clock (and its timezone). But, please note that in subsequent requests, for the rest of the life of the transaction and beyond, such as CCA_STATUS and QTRANS for reporting, the authDate, authTime, settleDate and settleTime will be returned as they are represented in the OSC Engine: in PST/PDT. Please keep this in mind when building QTRANS requests (if date/time is involved) and examining the results--you may wish to convert results to the end-user's time zone using standard offsets, such as +2 hours for US Central (CST = GMT -0600 while PST = GMT -0800; Central time is two hours ahead of Pacific time).