Simple Order API Client Developer Guide

This section describes how to use this guide and where to find further information.
Audience and Purpose
This guide is written for application developers who want to use the Simple Order API client to integrate
Cybersource
services into their order management system. The guide describes tasks you must complete to install, test, and use the Simple Order API client software.
Using the Simple Order API client SDK requires programming skills in one of the following programming languages:
  • C, C++
  • Java/Cold Fusion
  • .NET
  • PHP
To use these SDKs, you must write code that uses the API request and reply fields to integrate
Cybersource
services into your existing order management system.
Conventions
These statements appear in this document:
An
Important
statement contains information essential to successfully completing a task or learning a concept.
A
Warning
contains information or instructions, which, if not heeded, can result in a security risk, irreversible loss of data, or significant cost in time or revenue or both.
Related Documentation
Visit the
Cybersource
documentation hub
to find additional technical documentation.
Customer Support
For support information about any service, visit the Support Center:

Recent Revisions to This Document

25.12.01

This revision contains only editorial changes and no technical updates.

20.07.01 (July 2020)

Added endpoints for merchants in India.

19.09.01 (September 2019)

Deprecated and deleted Perl and ASP sections and removed ASP and Perl section references from About this Guide and Introduction sections.

19.04.01 (April 2019)

Updated
.NET 4.0
to
.NET 4.0 or later
.
Updated the types of endpoints:

15.09.01 (September 2015)

Updated the production server URL and the test server URL.

14.09.01 (September 2014)

Added the new .NET 4.0 client section. See .NET 4.0 or Later Client.

Introduction

Only the .NET 4.0 or later client for the Simple Order API is supported on both 32-bit and 64-bit operating systems. All of the other Simple Order API clients are supported on 32-bit operating systems only.
The Simple Order API enables you to access
Cybersource
services using name-value pairs, XML, or the Simple Object Access Protocol (SOAP). The Simple Order API SDKs provide the client software for the following programming languages:
  • C, C++
  • .NET version 1.1 and version 2.0
  • Java
  • PHP
The Simple Order API is a good choice for businesses who:
  • Must access
    Cybersource
    services that can only be accessed with APIs.
  • Have high volumes of transactions that warrant high levels of automation.
  • Must control and customize their customers’ buying experience.
  • Have an order page that is secured with Secure Sockets Layer (SSL).
  • Can provide skilled software programmers to implement
    Cybersource
    services with the API.

C/C++ Client

  • The C/C++ client for the Simple Order API is supported on 32-bit operating systems only.
  • If you are building an application to sell to others, see Using the Client Application Fields. This section includes a list of API fields you can use in your request that describe the application, its version, and its user. If you use these fields in your request, you can view their values in the Transaction Search Details page of the
    Business Center
    .

Choosing Your API and Client

API Variation

With this client package, you can use either of these variations of the Simple Order API:
  • Name-value pairs, which are simpler to use than XML
  • XML, which requires you to create and parse XML documents
The test that you run immediately after installing the client uses name-value pairs.

Client Versions

We update the Simple Order API on a regular basis to introduce new API fields and functionality. To identify the latest version of the API, go to: transactionProcessor.
This represents the version of the server-side code for the
Cybersource
services.
The Simple Order API Client for C/C++ also has a version, but it is not the same as the API version. The client version represents the version of the client-side code that you use to access the
Cybersource
services.
When configuring the client, you indicate which version of the API you want to use. When setting this parameter, do not use the current version of the client; use the current version of the API.

Sample Code

The client contains two sets of sample code, one for using name-value pairs and one for using XML. See Testing the Client or see the README file for more information about using the sample code to test the client.
  • Name-value pairs: See
    authCaptureSample.c
    in <installation directory>
    /samples/nvp
    .
  • XML: We suggest that you examine the name-value pair sample code listed above before implementing your code to process XML requests.
For the XML sample code, see
authSample.c
in <installation directory>
/samples/xml
. Also see the
auth.xml
XML document that the script uses.

Basic C/C++ Page Example

The following example shows the code required to send a Simple Order API request for credit card authorization and process the reply. The example uses name-value pairs. For a more complete example, see the sample code and sample store included in the package (see Sample Code). Using Name-Value Pairs, shows you how to create the code.
#include "cybersource.h" // Load the configuration settings const char CYBS_CONFIG_INI_FILE[] = "../cybs.ini"; pConfig = cybs_load_config( CYBS_CONFIG_INI_FILE ); // Set up the request by creating an empty CybsMap and add fields to it pRequest = cybs_create_map(); // We want to do credit card authorization in this example cybs_add( pRequest, "ccAuthService_run", "true" ); // Add required fields cybs_add( pRequest, "merchantID", "infodev" ); cybs_add( pRequest, "merchantReferenceCode", "MRC-14344" ); cybs_add( pRequest, "billTo_firstName", "Jane" ); cybs_add( pRequest, "billTo_lastName", "Smith" ); cybs_add( pRequest, "billTo_street1", "Charleston" ); cybs_add( pRequest, "billTo_city", "Mountain View" ); cybs_add( pRequest, "billTo_state", "CA" ); cybs_add( pRequest, "billTo_postalCode", "94043" ); cybs_add( pRequest, "billTo_country", "US" ); cybs_add( pRequest, "billTo_email", "jsmith@example.com" ); cybs_add( pRequest, "card_accountNumber", "4111111111111111" ); cybs_add( pRequest, "card_expirationMonth", "12" ); cybs_add( pRequest, "card_expirationYear", "2010" ); cybs_add( pRequest, "purchaseTotals_currency", "USD" ); // This example has two items cybs_add( pRequest, "item_0_unitPrice", "12.34" ); cybs_add( pRequest, "item_1_unitPrice", "56.78" ); // Add optional fields here according to your business needs // Send request Create the reply structure and send the request pReply = cybs_create_map(); status = cybs_run_transaction(pConfig, pRequest, pReply); // Handle the reply. See Handling the Return Status.

Installing and Testing the Client

Minimum System Requirements For Linux

  • Linux kernel 2.2, LibC6 on an Intel processor
  • GNU GCC compiler (with C++ enabled)

Minimum System Requirements For Windows

  • Windows XP, 2000, or newer
  • Microsoft Visual Studio 6.0
The SDK supports UTF-8 encoding.
Failure to configure your client API host to a unique, public IP address will cause inconsistent transaction results.
The client API request ID algorithm uses a combination of IP address and system time, along with other values. In some architectures this combination might not yield unique identifiers.

Transaction Security Keys

The first thing you must do is create your security key. The client uses the security key to add a digital signature to every request that you send. This signature helps ensure that no one else can use your
Cybersource
account to process orders. You specify the location of your key when you configure the client.
You must generate two transaction security keys—one for the
Cybersource
production environment and one for the test environment. For information about generating and using security keys, see ).
The Simple Order API client for C/C++ package includes the
ca-bundle.crt
, a bundle of certificate files. The client expects to find the
ca-bundle.crt
file in the same directory as your security keys. If you decide to move it elsewhere, use the sslCertFile configuration parameter to specify the file’s location (see the description of sslCertFile).
You must protect your security key to ensure that your
Cybersource
account is not compromised.

Install the Client

  1. Go to the client downloads page on the Support Center.
  2. Download the latest client package, and save it in any directory.
  3. Unpack the file. This creates an installation directory called
    simapi-c-n.n.n
    , where
    n.n.n
    is the client version. The client is now installed on your system.
  4. Configure the client. See Configuring Client Settings below.
  5. Test the client. See Testing the Client.

RESULT

You have installed and tested the client. You are ready to create your own code for requesting
Cybersource
services. Finish reading this section, and then move on to either Using Name-Value Pairs, if you plan to use name-value pairs, or Using XML, if you plan to use XML.

Configuring Client Settings

To run the sample code included in the client package, you must set the configuration parameters in the
cybs.ini
file, which is located in the installation directory. You can also use this file when running transactions in a production environment (see the function descriptions in C/C++ API for the Client). The table below describes the parameters that you can set. Note that the default
cybs.ini
file that comes with the client package does not include all of the parameters listed in the table below. It includes only the ones required to run the sample code.
If you have multiple merchant IDs, or if you are a reseller handling multiple merchants, you can use different configuration settings depending on the merchant ID. See Configuring for Multiple Merchant IDs, for more information.
Configuration Settings
Setting
Description
merchantID
Merchant ID. This client uses this value if you do not specify a merchant ID in the request itself.
keysDirectory
Location of the merchant’s security keys for the production and the test environments. The client includes a
keys
directory that you can use.
We recommend that you store your key locally for faster request processing.
sendToProduction
Flag that indicates whether the transactions for this merchant should be sent to the production server. Use one of these values:
  • false
    : Do not send to the production server; send to the test server (default setting).
  • true
    : Send to the production server.
targetAPIVersion
Version of the Simple Order API to use, for example:
1.18
. Do not set this property to the current version of the client; set it to an available API version. See Client Versions for more information.
Go to https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor to see a current list of the available versions. For transactions in India, go to https://ics2ws.in.ic3.com/commerce/1.x/transactionProcessor.
keyFilename
Name of the security key filename for the merchant in the format

<
key_fileName
>
.
p12
.
serverURL
Alternate server URL to use. See Using Alternate Server Configuration Settings for more information. Give the complete URL because it will be used exactly as you specify here.
namespaceURI
Alternate namespace URI to use. See Using Alternate Server Configuration Settings for more information. Give the complete namespace URI, as it will be used exactly as you specify here.
enableLog
Flag directing the client to log transactions and errors. Possible values:
  • false
    : Do not enable logging (default setting).
  • true
    : Enable logging.
    Logging can cause very large log files to accumulate. Therefore, we recommend that you use logging only when troubleshooting problems. To comply with all Payment Card Industry (PCI) and Payment Application (PA) Data Security Standards regarding the storage of credit card and card verification number data, the logs that are generated contain only masked credit card and card verification number data (CVV, CVC2, CVV2, CID, CVN).
    Follow these guidelines:
    • Use debugging temporarily for diagnostic purposes only.
    • If possible, use debugging only with test credit card numbers.
    • Never store clear text card verification numbers.
    • Delete the log files as soon as you no longer need them.
    • Never send email to
      Cybersource
      containing personal and account information, such as customers' names, addresses, card or check account numbers, and card verification numbers.
      For more information about PCI and PABP requirements, see www.visa.com/cisp.
logDirectory
Directory to which to write the log file. Note that the client will not create this directory for you; you must specify an existing directory. The client includes a
logs
directory that you can use.
logFilename
Log file name. The client uses
cybs.log
by default.
logMaximumSize
Maximum size in megabytes for the log file. The default value is
"10"
. When the log file reaches the specified size, it is archived into
cybs.log
.<yyyymmdd
T
hhmmssxxx> and a new log file is started. The xxx indicates milliseconds.
sslCertFile
The location of the bundled file of CA Root Certificates (
ca-bundle.crt
) which is included in the client download package. The client automatically looks for the file in the directory where your security keys are stored (specified by keysDirectory). If you move the file so it does not reside in keysDirectory, use this configuration setting to specify the full path to the file, including the file name.
timeout
Length of timeout in seconds. The default is 110.
proxyServer
Proxy server to use. Allowable formats include:
  • <http://>server<:port>
  • <http://>IP address<:port>
    The
    http://
    and
    port
    are optional.
    The default port is 1080. If your proxy server is listening on another port, you must specify a port number.
proxyUsername
Username used to authenticate against the proxy server, if required. If the proxy server requires the domain name during authentication, add the domain name and a backslash: <domain>\<username>
proxyPassword
Password used to authenticate against the proxy server, if required.

Testing the Client

After you install and configure the client, test it immediately to ensure that the installation is successful.

Test the Client

  1. At a command prompt, go to the <installation directory>
    /samples/nvp
    directory.
  2. Run the sample program by typing
    authCaptureSample
    . The results of the test are displayed in the window.

RESULT

  • If the test is successful, a decision of ACCEPT appears for both the credit card authorization and the follow-on capture.
  • If the test is not successful, a different decision value or an error message appears.

Troubleshoot if The Test Fails

  1. Check to see that your
    cybs.ini
    settings are correct.
  2. Run the test again.
  3. If the test still fails, look at the error message and find the return status value (a numeric value from 0 to 8).
  4. See the descriptions of the status values in Possible Return Status Values, and follow any instructions given there for the error you received.
  5. Run the test again.
  6. If the test still fails, contact Customer Support.

Run the XML Sample

  1. At a command prompt, go to the <installation directory>
    /samples/xml
    directory.
  2. Run the sample program by typing
    authSample
    . The results of the test are displayed in the window.

RESULT

  • If the test is successful, a decision of ACCEPT appears for both the credit card authorization and the follow-on capture.
  • If the test is not successful, a different decision value or an error message appears.

Going Live

When you have completed all of your system testing and are ready to accept real transactions from your customers, your deployment is ready to
go live
.

Cybersource
Essentials Merchants

If you use
Cybersource
Essentials services, you can use the
Business Center
site to go live.
You must also configure your client so that it sends transactions to the production server and not the test server. See the description of the
sendToProduction
setting in Configuration Settings.
After your deployment goes live, use real card numbers and other data to test every card type you support. Because these are real transactions in which you are buying from yourself, use small monetary amounts to do the tests. Process an authorization, then capture the authorization, and later refund the money. Use your bank statements to verify that money is deposited into and withdrawn from your merchant bank account as expected. If you have more than one
Cybersource
merchant ID, test each one separately.

Cybersource
Advanced Merchants

If you use
Cybersource
Advanced services, see Getting Started with Cybersource Advanced for information about going live.
When your deployment goes live, your
Cybersource
account is updated so that you can send transactions to the
Cybersource
production server. If you have not already done so, you must provide your banking information to
Cybersource
so that your processor can deposit funds to your merchant bank account.
After
Cybersource
confirms that your deployment is live, make sure that you update your system so that it can send requests to the production server (
ics2wsa.ic3.com
or
ics2ws.in.ic3.com
in India) using your security keys for the production environment. The test server (
ics2wstesta.ic3.com
) cannot be used for real transactions. For more information about sending transactions to the production server, see the description of the configuration setting sendToProduction.
After your deployment goes live, use real card numbers and other data to test every card type, currency, and
Cybersource
application that your integration supports. Because these are real transactions in which you are buying from yourself, use small monetary amounts to do the tests. Use your bank statements to verify that money is deposited into and withdrawn from your merchant bank account as expected. If you have more than one merchant ID, test each one separately.

Updating the Client to Use a Later API Version

Cybersource
periodically updates the Simple Order API (previously called the Web Services API). You can update your existing client to work with the new API version. Go to https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor for a list of the available API versions.
To update the client to use a later API version, update the value for the
targetAPIVersion
configuration parameter. For example, to use the 1.18 version of the API, set the property to
1.18
.

C/C++ API for the Client

CybsMap Structure

CybsMap is the structure that contains your configuration settings, your request, and the reply. You use the functions described in the next section to manipulate the structure, which includes adding the configuration settings, adding either name-value pairs or an XML document for the request, sending the request, and retrieving the corresponding reply.

Available Functions

The client API includes the functions described in the following sections.

cybs_load_config()

cybs_load_config()
Syntax
CybsMap *cybs_load_config( const char *szFilename )
Description
Creates an empty CybsMap structure and loads the configuration settings into the structure from a file. If you include a configuration property in the file more than once, the behavior is undefined. The
add behavior
setting (see cybs_set_add_behavior()) of the returned map is set to 2 (overwrite). This allows you to use the cybs_add() function (cybs_add()) to immediately override any settings that were read from the configuration file.
You must later free the returned pointer by using cybs_destroy_map() (see cybs_destroy_map(),).
Returns
Returns a pointer to the CybsMap structure containing the configuration settings.
Parameters
szFilename
: Name of the configuration file with the full or relative path.

cybs_create_map()

cybs_create_map()
Syntax
CybsMap *cybs_create_map()
Description
Creates an empty CybsMap structure with the add behavior set to CYBS_NO_CHECK.
You must later free the returned pointer by using cybs_destroy_map() (see cybs_destroy_map()).
Returns
Returns a pointer to the new empty CybsMap structure.
Parameters
None.

cybs_destroy_map()

cybs_destroy_map()
Syntax
void cybs_destroy_map( CybsMap *pMap )
Description
Destroys a CybsMap structure created with either cybs_create_map() or cybs_load_config().
Returns
Returns nothing.
Parameters
pMap
: The CybsMap structure to be destroyed.

cybs_set_add_behavior()

cybs_set_add_behavior()
Syntax
CybsAddBehavior cybs_set_add_behavior(
CybsMap *pRequest, CybsAddBehavior add_behavior )
Description
Sets the type of add behavior that will be used when you add name-value pairs to the specified message structure:
  • 0: When you add a new name-value pair, the client does not check to see if the name-value pair already exists in the structure. If the name already exists, the client still adds the name-value pair to the structure. This is the default value for cybs_create_map().
  • 1: If you try to add a name that already exists in the structure, the client keeps the existing name and value. The client does not allow you to add the same name or change the value of an existing name.
  • 2: If you try to add a name that already exists in the structure, the client overwrites the existing name’s value with the new value. This is the default value for cybs_load_config().
Returns
Returns the previous add behavior setting.
Parameters
pRequest
: The CybsMap structure in which to apply the add behavior setting.
add_behavior
: The add behavior type to assign to the structure.

cybs_add()

cybs_add()
Syntax
int cybs_add( CybsMap *pRequest, const char *szName, const char *szValue )
Description
Adds a name-value pair to the specified message structure.The function will do nothing if
pRequest
,
szName
, or
szValue
is null. With this function you can add name-value pairs for API fields or for configuration settings.
Returns
Returns
0
on success or
-1
on failure.
Parameters
pRequest
: The CybsMap structure to add the name-value pairs to.
szName
: The name to add.
szValue
: The value to add.

cybs_remove()

cybs_remove()
Syntax
void cybs_remove( CybsMap *pRequest, const char *szName )
Description
Uses the specified name to remove the name-value pair from the structure.
Returns
Returns nothing. Simply returns if the name does not exist.
Parameters
pRequest
: The CybsMap structure to be used.
szName
: The name of the value to remove.

cybs_get()

cybs_get()
Syntax
const char *cybs_get( CybsMap *pMap, const char *szName )
Description
Gets the value corresponding to the specified name. Note that this pointer is owned by the client and you should not free it.
Returns
Returns a pointer to the value or null if the name does not exist.
Parameters
pMap
: The CybsMap structure to be used.
szName
: The name to use.

cybs_get_first()

cybs_get_first()
Syntax
void cybs_get_first( CybsMap *pMap, const char **pszName, const char **pszValue )
Description
Returns a pointer to the first name and to its value in the map. Note that the entries in the map are not sorted in any way. If the map contains no entries,
*pszName
and
*pszValue
are null. It is sufficient just to check
*pszName
. Note that the pointers
*pszName
and
*pszValue
are owned by the client; you should not free them.
Use cybs_get_next() to get the subsequent entries (see cybs_get_next()).
Returns
Returns nothing.
Parameters
pMap
: The CybsMap structure to use.
*pszName
: Pointer to the first name in the map.
*pszValue
: Pointer to the value of the first name in the map.

cybs_get_next()

cybs_get_next()
Syntax
void cybs_get_next( CybsMap *pMap, const char **pszName, const char **pszValue )
Description
Returns a pointer to the next name and to its value in the map. Note that the entries in the map are not sorted in any way. You may use this function only after using cybs_get_first() with the same CybsMap structure.
If the map contains no more entries, then
*pszName
and
*pszValue
would be null. It is sufficient just to check
*pszName
.
Note that the pointers
*pszName
and
*pszValue
are owned by the client; you should not free them.
The function’s behavior is undefined if you update the map (for example, if you add a new entry) between calls to cybs_get_first() and cybs_get_next().
Returns
Returns nothing.
Parameters
pMap
: The CybsMap structure to use.
*pszName
: Pointer to the first name in the map.
*pszValue
: Pointer to the value of the first name in the map.

cybs_get_count()

cybs_get_count()
Syntax
int cybs_get_count( CybsMap *pMap )
Description
Returns the number of name-value pairs in the specified message structure.
Returns
Returns the number of name-value pairs.
Parameters
pMap
: The CybsMap structure to use.

cybs_create_map_string()

cybs_create_map_string()
Syntax
char *cybs_create_map_string( CybsMap *pMap )
Description
Creates a string containing all of the name-value pairs in the structure separated by the newline character sequence that is appropriate to the operating system. If the structure is empty, the function returns an empty string. On failure, the function returns null.
You must later free the returned pointer using cybs_destroy_map_string() (see below).
Returns
Returns a pointer to the string containing the name-value pairs.
Parameters
pMap
: The CybsMap structure to use.

cybs_destroy_map_string()

cybs_destroy_map_string()
Syntax
void cybs_destroy_map_string( char *szMapString )
Description
Destroys a string created with cybs_create_map_string().
Returns
Returns nothing.
Parameters
szMapString
: The map string to destroy.

cybs_run_transaction()

cybs_run_transaction()
Syntax
CybsStatus cybs_run_transaction( CybsMap *pConfig, CybsMap *pRequest, CybsMap **ppReply )
Description
Sends the request to the
Cybersource
server and receives the reply.
Returns
A value that indicates the status of the request (see Possible Status Values for a list of values).
Parameters
pconfig
: Pointer to the configuration map structure to use.
pRequest
: Pointer to a map structure containing one of these:
  • The individual name-value pairs in the request (for name-value pair users)
  • A single key called
    _xml_document
    whose value is the XML document representing the request (for XML users)
ppReply
: Pointer to a pointer to a map structure containing one of these:
  • The individual name-value pairs in the reply (for name-value pair users)
  • A single key called
    _xml_document
    whose value is the XML document representing the reply (for XML users)
  • If an error occurs, a combination of these keys and their values:
      _error_info
      _raw_reply
      _fault_document
      _fault_code
      _fault_string
      _fault_request_id
    See below for descriptions of these keys.
    You must later free the
    *ppReply
    pointer with cybs_destroy_map() (see cybs_destroy_map()).

Reply Key Descriptions

  • _error_info
    : Information about the error that occurred
  • _raw_reply
    : The server’s raw reply
  • _fault_document
    : The entire, unparsed fault document
  • _fault_code
    : The fault code, which indicates where the fault originated
  • _fault_string
    : The fault string, which describes the fault.
  • _fault_request_id
    : The request ID for the request.

Possible Return Status Values

The cybs_run_transaction() function returns a status indicating the result of the request. Table 16 describes the possible status values, including whether the error is critical. If an error occurs after the request has been sent to the server, but the client cannot determine whether the transaction was successful, then the error is considered critical. If a critical error happens, the transaction may be complete in the Cybersource system but not complete in your order system. The descriptions below indicate how to handle critical errors.
The sample code (when run from a command prompt) displays a numeric value for the return status, which is listed in the first column.
Possible Status Values
Numeric Value (for Sample Code)
Value
Description
0
CYBS_S_OK
Critical:
No
Result:
The client successfully received a reply.
Keys in **ppReply:
For name-value pair users, **
ppReply
has the reply name-value pairs for the services that you requested.
For XML users, **
ppReply
contains the
_xml_document
key, with the response in XML format.
Manual action to take:
None
1
CYBS_S_PRE_SEND_ERROR
Critical:
No
Result:
An error occurred before the request could be sent. This usually indicates a configuration problem with the client.
Keys in **ppReply:
_error_info
Manual action to take:
Fix the problem described in the error information.
2
CYBS_S_SEND_ERROR
Critical:
No
Result:
An error occurred while sending the request.
Keys in **ppReply:
_error_info
Manual action to take:
None
A typical send error that you might receive when testing occurs if the
ca-bundle.crt
file is not located in the same directory as your security key. See the description of the sslCertFile configuration parameter in Configuration Settings for information about how to fix the problem.
3
CYBS_S_RECEIVE_ERROR
Critical:
Yes
Result:
An error occurred while waiting for or retrieving the reply.
Keys in **ppReply:
_error_info
_raw_reply
Manual action to take:
Check the Transaction Search page in the
Business Center
to verify that the request was processed, and if so, whether it succeeded. Update your transaction database appropriately.
4
CYBS_S_POST_RECEIVE_ERROR
Critical:
Yes
Result:
The client received a reply or a fault, but an error occurred while processing it.
Keys in **ppReply:
_error_info
_raw_reply
Manual action to take:
Examine the value of
_raw_reply
. If you cannot determine the status of the request, then check the Transaction Search pages in the
Business Center
to verify that the request was processed, and if so, whether it succeeded. Update your transaction database appropriately.
5
CYBS_S_CRITICAL_SERVER_FAULT
Critical:
Yes
Result:
The server returned a fault with
_fault_code
set to CriticalServerError.
Keys in **ppReply:
_error_info
_fault_document
_fault_code
_fault_string
_fault_request_id
Manual action to take:
Check the Transaction Search pages in the
Business Center
to verify that the request succeeded. When searching for the request, use the request ID provided by
_fault_request_id
.
6
CYBS_S_SERVER_FAULT
Critical:
No
Result:
The server returned a fault with _fault_code set to ServerError, indicating a problem with the
Cybersource
server.
Keys in **ppReply:
_error_info
_fault_document
_fault_code
_fault_string
Manual action to take:
None
7
CYBS_S_OTHER_FAULT
Critical:
No
Result:
The server returned a fault with _fault_code set to a value other than ServerError or CriticalServerError. Indicates a possible problem with merchant status or the security key. Could also indicate that the message was tampered with after it was signed and before it reached the
Cybersource
server.
Keys in **ppReply:
_error_info
_fault_document
_fault_code
_fault_string
Manual action to take:
Examine the value of the
_fault_string
and fix the problem. You might need to generate a new security key, or you might need to contact Customer Support if there are problems with your merchant status. For more information, see ).
A typical error that you might receive occurs if your merchant ID is configured for “test” mode but you send transactions to the production server. See the description of the sendToProduction configuration parameter in Configuration Settings for information about fixing the problem.
8
CYBS_S_HTTP_ERROR
Critical:
No
Result:
The server returned an HTTP status code other than 200 (OK) or 504 (gateway timeout). Note that if a 504 gateway timeout occurs, then the status=
3
.
Keys in **ppReply:
_error_info
_raw_reply
(contains the HTTP response body, or if none was returned, the literal
"(no response available)")
.
Manual action to take:
None.
The figure below summarizes the reply information you receive for each status value.

Using Name-Value Pairs

This section explains how to use the client to request
Cybersource
services by using name-value pairs.

Requesting
Cybersource
Services

To request
Cybersource
services, write code that:
  • Collects information for the
    Cybersource
    services that you will use
  • Assembles the order information into requests
  • Sends the requests to the
    Cybersource
    server
  • Processes the reply information
    The
    Cybersource
    servers do not support persistent HTTP connections.
The instructions in this section explain how to use C/C++ to request
Cybersource
services. For a list of API fields to use in your requests, see Related Documents.

Sample Code

The code in this section's example is incomplete. For a complete sample program, see the
authCaptureSample.c
file in the
<installation directory>
/samples/nvp
directory.

Creating and Sending Requests

To use any
Cybersource
service, you must create and send a request that includes the required information for that service.
The example that is developed in the following sections shows basic code for requesting
Cybersource
services. In this example, Jane Smith is buying an item for 29.95.

Adding the Use Statement

First add the include statement for the
cybersource.h
file:
#include "cybersource.h"

Loading the Configuration Settings

Next use cybs_load_config() to create a new CybsMap structure and load the configuration settings from a file:
const char CYBS_CONFIG_INI_FILE[] = "../cybs.ini"; pConfig = cybs_load_config( CYBS_CONFIG_INI_FILE );
You could instead create an empty CybsMap structure and add each configuration setting separately. You could also use a combination of the two methods: You could read the settings from a file and then add new settings using the cybs_add() function to override the settings read from the file.

Creating the Empty Request and Reply

Next use cybs_create_map() to create the request and reply:
pRequest = cybs_create_map(); pReply = cybs_create_map();

Adding the Merchant ID

You next add the merchant ID to the request. You can let the
Cybersource
C/C++ client automatically retrieve the merchant ID from the pConfig structure, or you can set it directly in the request (see below). The pRequest value overrides the pConfig value.
cybs_add( pRequest, "merchantID", "infodev" );

Adding Services to the Request Structure

You next indicate the service you want to use by adding the field to the request. For example, to request a credit card authorization:
cybs_add( pRequest, "ccAuthService_run", "true" );

Requesting a Sale

You can request multiple services by adding additional fields to the request. For example, if you fulfill the order immediately, you can request credit card authorization and capture together (referred to as a “sale”):
cybs_add( pRequest, "ccAuthService_run", "true" ); cybs_add( pRequest, "ccCaptureService_run", "true" );

Adding Service-Specific Fields to the Request

You next add the fields that are used by the services that you are requesting. If you request multiple services and they share common fields, you must add the field once only.
cybs_add( pRequest, "merchantReferenceCode", "3009AF229L7W" ); cybs_add( pRequest, "billTo_firstName", "Jane" ); cybs_add( pRequest, "billTo_lastName", "Smith" ); cybs_add( pRequest, "card_accountNumber", "4111111111111111" ); cybs_add( pRequest, "item_0_unitPrice", "29.95" );
The example above shows only a partial list of the fields you must send. Refer to Requesting Cybersource Services, for information about the guides that list all of the fields for the services that you are requesting.

Sending the Request

You next send the request:
status = cybs_run_transaction( pConfig, pRequest, pReply );

Interpreting Replies

Handling the Return Status

The
status
value is the handle returned by the cybs_run_transaction() function. The
status
indicates whether the
Cybersource
server received the request, the client received the reply, or there were any errors or faults during transmission. See Possible Return Status Values, for descriptions of each status value. For a different example, see the
authCaptureSample.c
file in the
<installation directory>
/samples/nvp
directory:
if( status == CYBS_S_OK ) {   // Read the value of the "decision" in pReply.   decision = cybs_get( pReply, "decision" );   // If decision=ACCEPT, indicate to the customer that the request was successful.   // If decision=REJECT, indicate to the customer that the order was not approved.   // If decision=ERROR, indicate to the customer that an error occurred and to try   // again later.   // Now get reason code results:   reason = cybs_get( pReply, "reasonCode" );   // See Processing the Reason Codes for how to process the   // reasonCode from the reply. } else {   handleError( status, pRequest, pReply ); } //--------------------- void handleError( CybsStatus stat, CybsMap* preq, CybsMap* prpl ) //--------------------- {   // handleError shows how to handle the different errors that can occur.   const char* pstr;   pstr = cybs_get( prpl, CYBS_SK_ERROR_INFO );   switch( stat ) {     // An error occurred before the request could be sent.     case CYBS_S_PRE_SEND_ERROR :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Notify appropriate internal resources of the error.     break;     // An error occurred while sending the request.     case CYBS_S_SEND_ERROR :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.     break;     // An error occurred while waiting for or retrieving the reply.     case CYBS_S_RECEIVE_ERROR :       // Critial error.       // Tell customer the order could not be completed and to try again later.       // Notify appropriate internal resources of the error.       // See the sample code for more information about handling critical errors.     break;     // An error occurred after receiving and during processing of the reply.     case CYBS_S_POST_RECEIVE_ERROR :       // Critical error.       // Tell customer the order could not be completed and to try again later.       // Look at _raw_reply in pReply for the raw reply.       // Notify appropriate internal resources of the error.       // See the sample code for more information about handling critical errors.     break;     // CriticalServerError fault     case CYBS_S_CRITICAL_SERVER_FAULT :       // Critial error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from the pReply.       // Notify appropriate internal resources of the fault.       // See the sample code for more information about reading fault details and       // handling a critical error.     break;     // ServerError fault     case CYBS_S_SERVER_FAULT :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from the pReply.       // See the sample code for information about reading fault details.     break;     // Other fault     case CYBS_S_OTHER_FAULT :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from pReply.       // Notify appropriate internal resources of the fault.       // See the sample code for information about reading fault details.     break;     // HTTP error     case CYBS_S_HTTP_ERROR :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Look at _raw_reply in pReply for the raw reply.       break;     default : // Unknown error   } }

Processing the Reason Codes

After the
Cybersource
server processes your request, it sends a reply message that contains information about the services you requested. You receive different fields depending on the services you request and the outcome of each service.
To use the reply information, you must integrate it into your system and any other system that uses that data. For example, you can store the reply information in a database and send it to other back office applications.
You must write an error handler to process the reply information that you receive from
Cybersource
. Do not show the reply information directly to customers. Instead, present an appropriate response that tells customers the result.
Because we might add reply fields and reason codes at any time, you should parse the reply data according to the names of the fields instead of their order in the reply.
The most important reply fields to evaluate are the following:
  • decision
    : A one-word description of the results of your request. The decision is one of the following:
  • reasonCode
    : A numeric code that provides more specific information about the results of your request.
You also receive a reason code for each service in your request. You can use these reason codes to determine whether a specific service succeeded or failed. If a service fails, other services in your request may not run. For example, if you request a credit card authorization and capture, and the authorization fails, the capture does not run. The reason codes for each service are described in the .
We reserve the right to add new reason codes at any time. If your error handler receives a reason code that it does not recognize, it should use the decision to interpret the reply.
// Example of how to handle reason codes   // Success   if( reason == "100" ) {     printf(       "Request ID: %s\nAuthorizedAmount: %s\nAuthorization Code: %s\n",       cybs_get(pReply, "requestID"),       cybs_get(pReply, "ccAuthReply_amount"),       cybs_get(pReply, "ccAuthReply_authorizationCode") );   }   // Insufficient funds   else if (reason == "204") {     printf(     "Insufficient funds in account. Please use a different      card or select another form of payment." ) ;   }     // add other reason codes here that you must handle specifically   else {     // For all other reason codes, return NULL, in which case, you should display     // a generic message appropriate to the decision value you received.   }

Handling
Decision Manager
Reviews

If you use
Decision Manager
, you may also receive the
REVIEW
value in the
decision
field.
REVIEW
means that
Decision Manager
has marked the order for review based on how you configured the
Decision Manager
rules.
If you will be using
Decision Manager
, you have to determine how to handle the new
REVIEW
value. Ideally, you will update your order management system to recognize the
REVIEW
response and handle it according to your business rules. If you cannot update your system to handle the
REVIEW
response, we recommend that you choose one of these options:
  • If you authorize and capture the credit card payment at the same time, treat the
    REVIEW
    response like a
    REJECT
    response. Rejecting any orders that are marked for review may be appropriate if your product is a software download or access to a Web site. If supported by your processor, you may also want to reverse the authorization.
  • If you approve the order after reviewing it, convert the order status to
    ACCEPT
    in your order management system. You can request the credit card capture without requesting a new authorization.
  • If you approve the order after reviewing it but cannot convert the order status to
    ACCEPT
    in your system, request a new authorization for the order. When processing this new authorization, you must disable
    Decision Manager
    . Otherwise the order will be marked for review again. For details about the API field that disables
    Decision Manager
    , see the .
Alternately, you can specify a custom business rule in
Decision Manager
so that authorizations originating from a particular internal IP address at your company are automatically accepted.
If supported by your processor, you may want to reverse the original authorization.

Requesting Multiple Services

When you request multiple services in one request,
Cybersource
processes the services in a specific order. If a service fails,
Cybersource
does not process the subsequent services in the request.
For example, in the case of a sale (a credit card authorization and a capture requested together), if the authorization service fails,
Cybersource
will not process the capture service. The reply you receive only includes reply fields for the authorization.
This following additional example applies
to
Cybersource
Advanced merchants only.
Many
Cybersource
services include “ignore” fields that tell
Cybersource
to ignore the result from the first service when deciding whether to run the subsequent services. In the case of the sale, even though the issuing bank gives you an authorization code,
Cybersource
might decline the authorization based on the AVS or card verification results. Depending on your business needs, you might choose to capture these types of declined authorizations anyway. You can set the
businessRules_ignoreAVSResult
field to “true” in your combined authorization and capture request:
cybs_add( pRequest, "businessRules_ignoreAVSResult", "true" );
This tells
Cybersource
to continue processing the capture even if the AVS result causes
Cybersource
to decline the authorization. In this case you would then get reply fields for both the authorization and the capture in your reply.
You are charged only for the services that
Cybersource
performs.

Retrying When System Errors Occur

You must design your transaction management system to include a way to correctly handle
Cybersource
system errors. Depending on which payment processor is handling the transaction, the error may indicate a valid
Cybersource
system error, or it may indicate a processor rejection because of some type of invalid data. In either case,
Cybersource
recommends that you do not design your system to retry sending a transaction many times in the case of a system error.
Instead, we recommend that you retry sending the request only two or three times with successively longer periods of time between each retry. For example, after the first system error response, wait 30 seconds and then retry sending the request. If you receive the same error a second time, wait one minute before you send the request again. Depending on the situation, you may decide you can retry sending the request after a longer time period. Determine what is most appropriate for your business situation.
If after several retry attempts you are still receiving a system error, it is possible that the error is actually being caused by a processor rejection and not a
Cybersource
system error. In that case, we suggest that you either:
  • Search for the transaction in the
    Business Center
    , look at the description of the error on the Transaction Detail page, and call your processor to determine if and why they are rejecting the transaction.
  • Contact
    Cybersource
    Customer Support to confirm whether your error is truly caused by a
    Cybersource
    system issue.
If
TSYS Acquiring Solutions
is your processor, you may want to follow the first suggestion as there are several common
TSYS Acquiring Solutions
processor responses that are returned to you as system errors and that only
TSYS Acquiring Solutions
can address.

Using XML

This section describes how to request
Cybersource
services using XML.

Requesting
Cybersource
Services

To request
Cybersource
services, write code that:
  • Collects information for the
    Cybersource
    services that you will use
  • Assembles the order information into requests
  • Sends the requests to the
    Cybersource
    server
    The
    Cybersource
    servers do not support persistent HTTP connections.
  • Processes the reply information
The instructions in this section explain how to use C/C++ to request
Cybersource
services. For a list of API fields to use in your requests, see Related Documents.

Sample Code

We suggest that you examine the name-value pair sample code provided in
authCaptureSample.c
before implementing your code to process XML requests. The sample will give you a basic understanding of how to request
Cybersource
services. The sample code file is located in the <installation directory>
/samples/nvp
directory.
After examining that sample code, read this section to understand how to create code to process XML requests. Note that the code in this section’s example is incomplete. For a complete sample program, see the
authSample.c
file in the <installation directory>
/samples/xml
directory.

Creating a Request Document

The client allows you to create an XML request document by using any application, then send the request to
Cybersource
. For example, if you have a customer relationship management (CRM) system that uses XML to communicate with other systems, you can use the CRM system to generate request documents.
The request document must validate against the XML schema for
Cybersource
transactions. To view the schema, go to 
https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor
and look at the
xsd
file for the version of the Simple Order API you are using.
Make sure that the elements in your document appear in the correct order. If they do not, your document will not validate, and your request will fail.
The example that is developed in the following sections shows a basic XML document for requesting
Cybersource
services. In this example, Jane Smith is buying an item for 29.95.
The XML document in this example is incomplete. For a complete example, see the
auth.xml
document in the
samples/xml
directory.

Creating an Empty Request

Add the XML declaration and the document’s root element:
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18"> </requestMessage>
When you construct a request, you must indicate the correct namespace for the elements, and the namespace must use the same API version that you specify in the configuration settings file. For example, if
targetAPIVersion
=
1.18
in the
cybs.ini
file, the namespace must be
urn:schemas-cybersource-com:transaction-data-1.18
.
The XML document that you receive in the reply always uses a prefix of
c:
(for example,
xmlns:c="urn:schemas-cybersource-com:transaction-data-1.18"
). Make sure you use an XML parser that supports namespaces.

Adding the Merchant ID

You next add the merchant ID to the request.
If you specify a merchant ID in the XML document, it overrides the merchant ID you specify in the configuration settings file.
<requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18">   <merchantID>infodev</merchantID> </requestMessage>

Adding Services to the Request

You next indicate the service that you want to use by creating an element for that service in the request, then setting the element’s
run
attribute to
true
. For example, to request a credit card authorization:
<requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18">   <merchantID>infodev</merchantID>   <ccAuthService run="true"/> </requestMessage>

Requesting a Sale

You can request multiple services by adding additional elements. For example, if you fulfill the order immediately, you can request a credit card authorization and capture together (referred to as a “sale”):
<requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18">   <merchantID>infodev</merchantID>   <ccAuthService run="true"/>   <ccCaptureService run="true"/> </requestMessage>

Adding Service-Specific Fields to the Request

You next add the fields that are used by the services you are requesting. Most fields are child elements of container elements; for example, a
<card>
element contains the customer’s credit card information.
<requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18">   <merchantID>infodev</merchantID>   <billTo>     <firstName>Jane</firstName>     <lastName>Smith</lastName>   </billTo>   <item id="0">     <unitPrice>29.95</unitPrice>   </item>   <card>     <accountNumber>4111111111111111</accountNumber>   </card>   <ccAuthService run="true"/> </requestMessage>
The example above shows only a partial list of the fields you must send. Refer to Requesting Cybersource Services, for information about the guides that list all of the fields for the services that you are requesting.

Sending Requests

Once you have created an XML document, you use C/C++ to send the request to
Cybersource
.

Adding the Use Statement

First add the include statement for the
cybersource.h
file:
#include "cybersource.h"

Loading the Configuration Settings

Next use cybs_load_config() to create a new CybsMap structure and load the configuration settings from a file:
const char CYBS_CONFIG_INI_FILE[] = "../cybs.ini"; pConfig = cybs_load_config( CYBS_CONFIG_INI_FILE );
You could instead create an empty CybsMap structure and add each configuration setting separately. You could also use a combination of the two methods: You could read the settings from a file and then add new settings using the cybs_add() function to override the settings read from the file.
The namespace that you specify in the XML document must use the same API version that you specify in the configuration settings file. For example, if
targetAPIVersion
=
1.18
in the file, the namespace must be
urn:schemas-cybersource-com:transaction-data-1.18
. The example code below retrieves the API version from the configuration settings file and places it in the XML document.

Creating the Empty Request and Reply

Next use cybs_create_map() to create the request and reply:
pRequest = cybs_create_map(); pReply = cybs_create_map();

Reading the XML Document

Next, read the XML document and add the information to the request.
const char CYBS_XML_INPUT_FILE[] = "./myXMLDocument.xml"; // Read the XML document and store in a variable called szXML. // See the authSample.c sample code for instructions on reading the // XML document. // Add the XML document to the request. cybs_add( pRequest, CYBS_SK_XML_DOCUMENT, szXML );

Sending the Request

You next send the request:
status = cybs_run_transaction( pConfig, pRequest, pReply );

Interpreting Replies

Handling the Return Status

The
status
value is the handle returned by the cybs_run_transaction() function. The
status
indicates whether the
Cybersource
server received the request, the client received the reply, or there were any errors or faults during transmission. See Possible Return Status Values, for descriptions of each status value. For a different example, see the
authSample.c
file in the client’s
<installation directory>
/xmlSample
directory.
if( status == CYBS_S_OK ) {   // Read the value of the "decision" in pReply.   decision = cybs_get( pReply, "decision" );   // If decision=ACCEPT, indicate to the customer that the request was successful.   // If decision=REJECT, indicate to the customer that the order was not approved.   // If decision=ERROR, indicate to the customer that there was an error and to try
  // again later.   // Now get reason code results:   reason = cybs_get( pReply, "reasonCode" );   // See "Processing the Reason Codes," page 31 for how to process the   // reasonCode from the reply. } else {   handleError( status, pRequest, pReply ); } //--------------------- void handleError( CybsStatus stat, CybsMap* preq, CybsMap* prpl ) //--------------------- {   // handleError shows how to handle the different errors that can occur.   const char* pstr;   pstr = cybs_get( prpl, CYBS_SK_ERROR_INFO );   switch( stat ) {     // An error occurred before the request could be sent.     case CYBS_S_PRE_SEND_ERROR :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Notify appropriate internal resources of the error.     break;     // An error occurred while sending the request.     case CYBS_S_SEND_ERROR :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.     break;     // An error occurred while waiting for or retrieving the reply.     case CYBS_S_RECEIVE_ERROR :       // Critial error.       // Tell customer the order could not be completed and to try again later.       // Notify appropriate internal resources of the error.       // See the sample code for more information about handling critical errors.     break;     // An error occurred after receiving and during processing of the reply.     case CYBS_S_POST_RECEIVE_ERROR :       // Critical error.       // Tell customer the order could not be completed and to try again later.       // Look at _raw_reply in pReply for the raw reply.       // Notify appropriate internal resources of the error.       // See the sample code for more information about handling critical errors.     break;     // CriticalServerError fault     case CYBS_S_CRITICAL_SERVER_FAULT :       // Critial error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from the pReply.       // Notify appropriate internal resources of the fault.     // ServerError fault     case CYBS_S_SERVER_FAULT :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from pReply.       // See the sample code for information about reading fault details.    break;     // Other fault     case CYBS_S_OTHER_FAULT :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from pReply.       // Notify appropriate internal resources of the fault.       // See the sample code for information about reading fault details.     break;     // HTTP error     case CYBS_S_HTTP_ERROR :       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Look at _raw_reply in pReply for the raw reply.       break;     default : // Unknown error   } }

Processing the Reason Codes

After the
Cybersource
server processes your request, it sends a reply message that contains information about the services you requested. You receive different fields depending on the services you request and the outcome of each service.
To use the reply information, you must integrate it into your system and any other system that uses that data. For example, you can store the reply information in a database and send it to other back office applications.
You must write an error handler to process the reply information that you receive from
Cybersource
. Do not show the reply information directly to customers. Instead, present an appropriate response that tells customers the result.
Because we may add reply fields and reason codes at any time, you should parse the reply data according to the names of the fields instead of their order in the reply.
The most important reply fields to evaluate are the following:
  • decision
    : A one-word description of the results of your request. The decision is one of the following:
  • reasonCode
    : A numeric code that provides more specific information about the results of your request.
You also receive a reason code for each service in your request. You can use these reason codes to determine whether a specific service succeeded or failed. If a service fails, other services in your request may not run. For example, if you request a credit card authorization and capture, and the authorization fails, the capture does not run. The reason codes for each service are described in .
We reserve the right to add new reason codes at any time. If your error handler receives a reason code that it does not recognize, it should use the decision to interpret the reply.
// Example of how to handle reason codes   // Success   if( reason == "100" ) {     printf(       "Request ID: %s\nAuthorizedAmount: %s\nAuthorization Code: %s\n",       cybs_get(pReply, "requestID"),       cybs_get(pReply, "ccAuthReply_amount"),       cybs_get(pReply, "ccAuthReply_authorizationCode") );   }   // Insufficient funds   else if (reason == "204") {     printf(     "Insufficient funds in account. Please use a different      card or select another form of payment." ) ;   }     // add other reason codes here that you must handle specifically   else {     // For all other reason codes, return NULL, in which case, you should display a     // generic message appropriate to the decision value you received.   }

Handling
Decision Manager
Reviews

If you use
Decision Manager
, you may also receive the
REVIEW
value in the
decision
field.
REVIEW
means that
Decision Manager
has marked the order for review based on how you configured the
Decision Manager
rules.
If you will be using
Decision Manager
, you have to determine how to handle the new
REVIEW
value. Ideally, you will update your order management system to recognize the
REVIEW
response and handle it according to your business rules. If you cannot update your system to handle the
REVIEW
response, we recommend that you choose one of these options:
  • If you authorize and capture the credit card payment at the same time, treat the
    REVIEW
    response like a
    REJECT
    response. Rejecting any orders that are marked for review may be appropriate if your product is a software download or access to a Web site. If supported by your processor, you may also want to reverse the authorization.
  • If you approve the order after reviewing it, convert the order status to
    ACCEPT
    in your order management system. You can request the credit card capture without requesting a new authorization.
  • If you approve the order after reviewing it but cannot convert the order status to
    ACCEPT
    in your system, request a new authorization for the order. When processing this new authorization, you must disable
    Decision Manager
    . Otherwise the order will be marked for review again. For details about the API field that disables
    Decision Manager
    , see the .
Alternately, you can specify a custom business rule in
Decision Manager
so that authorizations originating from a particular internal IP address at your company are automatically accepted.
If supported by your processor, you may want to reverse the original authorization.

Requesting Multiple Services

When you request multiple services in one request,
Cybersource
processes the services in a specific order. If a service fails,
Cybersource
does not process the subsequent services in the request.
For example, in the case of a sale (a credit card authorization and a capture requested together), if the authorization service fails,
Cybersource
does not process the capture service. The reply you receive only includes reply fields for the authorization.
This following additional example applies
to
Cybersource
Advanced merchants only.
Many
Cybersource
services include “ignore” fields that tell
Cybersource
to ignore the result from the first service when deciding whether to run the subsequent services. In the case of the sale, even though the issuing bank gives you an authorization code,
Cybersource
might decline the authorization based on the AVS or card verification results. Depending on your business needs, you might choose to capture these types of declined authorizations anyway. You can set the
businessRules_ignoreAVSResult
field to “true” in your combined authorization and capture request:
<businessRules>     <ignoreAVSResult>true</ignoreAVSResult> </businessRules>
This tells
Cybersource
to continue processing the capture even if the AVS result causes
Cybersource
to decline the authorization. In this case you would then get reply fields for both the authorization and the capture in your reply.
You are charged only for the services that
Cybersource
performs.

Retrying When System Errors Occur

You must design your transaction management system to include a way to correctly handle
Cybersource
system errors. Depending on which payment processor is handling the transaction, the error may indicate a valid
Cybersource
system error, or it may indicate a processor rejection because of some type of invalid data. In either case, we recommend that you do not design your system to retry sending a transaction many times in the case of a system error.
Instead, we recommend that you retry sending the request only two or three times with successively longer periods of time between each retry. For example, after the first system error response, wait 30 seconds and then retry sending the request. If you receive the same error a second time, wait one minute before you send the request again. Depending on the situation, you may decide you can retry sending the request after a longer time period. Determine what is most appropriate for your business situation.
If after several retry attempts you are still receiving a system error, it is possible that the error is actually being caused by a processor rejection and not a
Cybersource
system error. In that case, we suggest that you either:
  • Search for the transaction in the
    Business Center
    , look at the description of the error on the Transaction Detail page, and call your processor to determine if and why they are rejecting the transaction.
  • Contact
    Cybersource
    Customer Support to confirm whether your error is truly caused by a
    Cybersource
    system issue.
If
TSYS Acquiring Solutions
is your processor, you may want to follow the first suggestion as there are several common
TSYS Acquiring Solutions
processor responses that are returned to you as system errors and that only
TSYS Acquiring Solutions
can address.

Advanced Configuration Information

Using Alternate Server Configuration Settings

You use the serverURL and namespaceURI configuration settings if
Cybersource
changes the convention we use to specify the server URL and namespace URI, but we have not had the opportunity to update the client yet.
For example, these are the server URLs and namespace URI for accessing the
Cybersource
services using the Simple Order API version 1.18:
  • Test server URLs:
    • Internet endpoint:
      https://ics2wstest.ic3.com/commerce/1.x/transactionProcessor
    • Akamai endpoint:
      https://ics2wstesta.ic3.com/commerce/1.x/transactionProcessor
  • Production server URLs:
    • Internet endpoint: https://ics2ws.ic3.com/commerce/1.x/transactionProcessor
    • Akamai endpoint: https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor
    • India endpoint:
      https://ics2ws.in.ic3.com/commerce/1.x/transactionProcessor
  • Namespace URI:
    urn:schemas-cybersource-com:transaction-data-1.18
    .
If view the above URLs in a web browser, a list of the supported API versions and the associated schema files are displayed.
If in the future
Cybersource
changes these conventions, but does not provide a new version of the client, you can configure your existing client to use the new server and namespace conventions required by the
Cybersource
server.

Configuring for Multiple Merchant IDs

If you have multiple merchant IDs, or if you are a reseller handling multiple merchants, you can have different configuration settings for different merchant IDs. You set these in the configuration object that you pass to the cybs_run_transaction() function. When using the samples provided in the client package, you set the configuration parameters in
cybs.ini
file.
All of the properties except merchantID can be prefixed with "
<merchantID>.
" to specify the settings for a specific merchant.
Example: Merchant-Specific Properties Settings
If you have a merchant with merchant ID of
merchant123
, and you want enable logging only for that merchant, you can set the enableLog parameter to
true
for all requests that have
merchant123
as the merchant ID:
merchant123.enableLog=true
enableLog=false
The client disables logging for all other merchants.

.NET 4.0 or Later Client

  • The .NET 4.0 or later client for the Simple Order API is supported on 32-bit and 64-bit operating systems.
  • If you are building an application to sell to others, see Using the Client Application Fields. This section includes a list of API fields you can use in your request that describe the application, its version, and its user. If you use these fields in your request, you can view their values in the Transaction Search Details page of the
    Business Center
    .

Choosing an API and Client

API Variation

With this client package, you can use any of the three variations of the Simple Order API:
  • Name-value pairs, which are simpler to use than XML
  • XML, which requires you to create and parse XML documents
  • SOAP (Simple Object Access Protocol) 1.1, which provides an object-oriented interface
The test that you run immediately after installing the client uses name-value pairs.

Client Versions

Cybersource
updates the Simple Order API on a regular basis to introduce new API fields and functionality. To identify the latest version of the API, go to: https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor.
This represents the version of the server-side code for the
Cybersource
services.
If a new version of the API has been released, but
Cybersource
has not yet updated the .NET client to use this new version, you can manually update the client to use a different version. See Updating the Client to Use a Later API Version.

Basic C# Program Example

The following example shows the primary code required to send a SOAP request for credit card authorization and process the reply. See Using SOAP, for more information.
using CyberSource.Soap; using CyberSource.Soap.CyberSourceWS; using System; using System.Configuration; using System.Net; using System.Web.Services.Protocols; namespace Sample {   class Sample {     static void Main(string[] args) {       RequestMessage request = new RequestMessage();       request.merchantID = "infodev";       // we want to do Credit Card Authorization in this sample       request.ccAuthService = new CCAuthService();       request.ccAuthService.run = "true";       // add required fields       request.merchantReferenceCode = "148705832705344";       BillTo billTo = new BillTo();       billTo.firstName = "Jane";       billTo.lastName = "Smith";       billTo.street1 = "1295 Charleston Road";       billTo.city = "Mountain View";       billTo.state = "CA";       billTo.postalCode = "94043";       billTo.country = "US";       billTo.email = "jsmith@example.com";       request.billTo = billTo;       Card card = new Card();       card.accountNumber = "4111111111111111";       card.expirationMonth = "12";       card.expirationYear = "2010";       request.card = card;       PurchaseTotals purchaseTotals = new PurchaseTotals();       purchaseTotals.currency = "USD";       request.purchaseTotals = purchaseTotals;       // there is one item in this sample       request.item = new Item[1];       Item item = new Item();       item.id = "0";       item.unitPrice = "29.95";       request.item[0] = item;       // See "Interpreting the Reply," for details about       // processing the reply for a SOAP transaction.       try {         ReplyMessage reply = Client.RunTransaction( request );       } catch (CryptographicException ce) {         Console.WriteLine( ce.ToString() );       } catch (MessageSecurityException mse) {         Console.WriteLine( mse.ToString() );       } catch (WebException we) {         Console.WriteLine( we.ToString() );       } catch (Exception e) {         Console.WriteLine( e.ToString() );       }     }   } }

Installing and Testing the Client

Minimum System Requirements

  • Microsoft Windows 2000 or later
  • .NET Framework 4.0 or later
  • Microsoft Visual Studio 2010
    Failure to configure your client API host to a unique, public IP address will cause inconsistent transaction results.
The client API request ID algorithm uses a combination of IP address and system time, along with other values. In some architectures this combination might not yield unique identifiers.

Transaction Security Keys

The first thing you must do is create your security key. The client uses the security key to add a digital signature to every request that you send. This signature helps ensure that no one else can use your Cybersource account to process orders. You specify the location of your key when you configure the client.
You must generate two transaction security keys—one for the Cybersource production environment and one for the test environment. For information about generating and using security keys, see
Creating and Using Security Keys
(PDF | HTML).
You must protect your security key to ensure that your Cybersource account is not compromised.

Installing the Client

The .NET SDK is available to install from GitHub: https://github.com/CyberSource/cybersource-sdk-dotnet

Using the NuGet Package Manager

We recommend using the NuGet Package Manager to install the .NET SDK.
Run the following command in the NuGet Package Manager console:
PM> Install-Package CyberSource

Installing Individual Files

The .NET SDK files are available to download independently from GitHub: https://github.com/CyberSource/cybersource-sdk-dotnet/releases

Install the Files Individually

  1. Download the latest zip file. The current version is
    cybersource-sdk-dotnet-1.0.0.zip
    .
  2. Extract the contents of the zip file to an appropriate location.
  3. Add CyberSource.Base.dll and CyberSource.Clients.dll to your project references.

Upgrading from a Previous Version

The .NET 4.0 or later Simple Order API client is a pure .NET client without dependencies outside of the .NET 4.0 or later Framework. It is simplified in comparison to previous Simple Order API .NET clients because it does not require the Microsoft Web Services Enhancements (WSE) and it does not use the Cybersource security libraries.
Previous versions of the Cybersource.Clients.dll required that you register CybsWSSecurity.dll as a COM object. The CybsWSSecurity.dll had dependencies on many other dynamic-link libraries (DLLs). Because the .NET 4.0 or later Simple Order API client does not use the Cybersource security libraries, you can remove or unregister the following DLLs:
  • CybsWSSecurity.dll (unregister)
  • CybsWSSecurityIOP.dll
  • CyberSource.WSSecurity.dll
  • domsupport_1_4_0.dll
  • Msvcp60.dll
  • platformsupport_1_4_0.dll
  • spapache.dll
  • xalandom_1_4_0.dll
  • xalansourcetree_1_4_0.dll
  • xerces-c_2_1_0.dll
  • xercesparserliaison_1_4_0.dll
  • xmlsupport_1_4_0.dll
  • xpath_1_4_0.dll

Migrate from a .NET Framework 1.x Client

  1. Replace the old DLLs with the ones from this package.
  2. In your project, remove references to the previous
    Cybersource
    DLLs.
  3. Add a reference to
    CyberSource.Clients.dll
    .
  4. In your request code, make the following changes:

    ADDITIONAL INFORMATION

    Replace the referenced
    Cybersource
    namespaces with this one:
    CyberSource.Clients
    If you use the SOAP client, add the following namespace:
    CyberSource.Clients.SoapWebReference
    Example
    : In C#, with the SOAP client, you now have:
    using CyberSource.Clients.
    using CyberSource.Clients.SoapWebReference; /*
    for SOAP client only
    */
  5. Follow the instructions for migrating from .NET Framework 2.X.

Migrate from a .NET Framework 2.x Client

  1. Follow the installation instructions in Installing the Client.
  2. Open your project in Visual Studio 2010. If necessary, use the conversion wizard to update your project from Visual Studio 2005 to Visual Studio 2010.
  3. In your project properties, set the target framework to
    .NET Framework 4
    .
  4. Make sure that your reference to CyberSource.Clients points to the new .NET 4.0 or later version of the DLL. You must use the DLLs that you installed in Step 1.
  5. Remove references to System.Web.Services and remove the following namespace from your code:

    ADDITIONAL INFORMATION

    using System.Web.Services.Protocols
  6. If your code contains catch statements that use
    SignException
    , change them to use
    CryptographicException
    instead. Making this change requires that you add a reference to System.Security and add the following namespace to your code:

    ADDITIONAL INFORMATION

    using System.Security.Cryptography
    • For SOAP and name-value pair (NVP) clients only:
      Remove any catch statements that use
      SoapHeaderException
      or
      SoapBodyException
      .
    • For SOAP clients only:
      Consider replacing these exceptions with appropriate Windows Communication Foundation (WCF) services exceptions such as
      MessageSecurityException
      ,
      EndpointNotFoundException
      , or
      ChannelTerminatedException
      depending on your requirements. Then you must add a reference to
      System.ServiceModel
      and add the following namespaces to your code:
      using System.ServiceModel;
      using System.ServiceModel.Security;
    You have successfully upgraded your client to the new version.

Testing the Client

See the “Running the Samples” section on GitHub: https://github.com/CyberSource/cybersource-sdk-dotnet#running-the-samples
Once you have tested the client, you are ready to create your own code to request the Cybersource services. Depending on which API you are using, see:

Using the Test Applications

Each type of client variation—name-value pair, XML, and SOAP—includes a pre-compiled test application. You can use these test applications to ensure that the client was installed correctly. The applications request both credit card authorization and capture.
The test applications and their source code are installed in the
samples
directory. The
bin
subdirectory contains the pre-compiled binaries. The
src
subdirectory contains the source code and Visual Studio project files.

Configuring the Test Applications

Before you run a test application, you must edit its application settings file. The following table describes all the configuration fields that you can use in this file.
Configuration settings supported by the latest 1.x.x version are still supported. However, we recommend that you use the following new settings for this and future versions.
Fields in the Settings File
Field Name
Description
Required/Optional
cybs.connectionLimit
Maximum number of allowed concurrent connections between the client and the
Cybersource
server. For more information on this field and alternate ways to set the connection limits, see "Setting the Connection Limit," page 94.
Optional
cybs.keysDirectory
Directory that contains the pkcs12 security key file. For example:
c:\keys\
Required
cybs.merchantID
Your merchant ID. You can override this value by providing the merchantID field in the request itself. The merchant ID is case sensitive.
Optional
cybs. sendToProduction
Flag that indicates whether the transactions for this merchant should be sent to the production server. Use one of these values:
  • false
    : Do not send to the production server; send to the test server (default setting).
  • true
    : Send to the production server.
    Make sure that if your merchant ID is configured to use the test mode, you send requests to the test server.
Required
cybs.keyFilename
Name of the security key file name for the merchant in the format
<
security_key_filename
>
.
p12
.
Optional
cybs.serverURL
Alternate server URL to use. For more information, see Configuring Your Settings for Multiple Merchants. Give the complete URL because it will be used exactly as you specify.
Optional
cybs.enableLog
Flag directing the client to log transactions and errors. Use one of these values:
  • false
    : Do not enable logging (default setting).
  • true
    : Enable logging.
    Logging can cause very large log files to accumulate. Therefore, we recommend that you use logging only when troubleshooting problems. To comply with all Payment Card Industry (PCI) and Payment Application (PA) Data Security Standards regarding the storage of credit card and card verification number data, the logs that are generated contain only masked credit card and card verification number data (CVV, CVC2, CVV2, CID, CVN).
    Follow these guidelines:
  • Use debugging temporarily for diagnostic purposes only.
  • If possible, use debugging only with test credit card numbers.
  • Never store clear text card verification numbers.
  • Delete the log files as soon as you no longer need them.
  • Never send email to
    Cybersource
    containing personal and account information, such as customers' names, addresses, card or check account numbers, and card verification numbers.
    For more information about PCI and PABP requirements, see www.visa.com/cisp.
Optional
cybs.logDirectory
Directory to which to write the log file. Note that the client will not create this directory for you; you must specify an existing directory. The client includes a
logs
directory that you can use. Include the path. For example:
c:\simapi-net-2.0.0\logs
.
Required if
cybs.
enableLog

is true
cybs.logFilename
Name of the log file. The client uses
cybs.log
by default.
Optional
cybs.logMaximumSize
Maximum size in megabytes for the log file. The default value is
10
. When the log file reaches the specified size, it is archived into
cybs.log
.<yyyymmdd
T
hhmmssxxx> and a new log file is started. The xxx indicates milliseconds.
Optional
cybs.timeout
Length of time-out in seconds. The default is 130.
Optional
cybs.proxyURL
URL of a proxy server. For example:
https://proxy.example.com:4909
Optional
cybs.proxyUser
User name for the proxy server.
Optional
cybs.proxyPassword
Password for the proxy server.
Optional

Test Applications

  1. Decide which test application you want to run, such as
    SoapSample.exe
    .
  2. Using a text editor, open the settings file for the test application. The settings file has the same name as the test application, with the extension
    config
    appended to the name. For example,
    SoapSample.exe.config
    .
  3. Find the
    cybs.merchantID
    field and change its value to your Cybersource merchant ID. For example, if your merchant ID is
    widgetsinc
    , change the field to 

    <add key="cybs.merchantID" value="
    widgetsinc
    "/>
    . The merchant ID is case sensitive.
  4. Find the
    cybs.keysDirectory
    field and change its value to the directory that contains your security key. For example, if your key is in
    c:\keys\
    , change the field to 

    <add key="cybs.keysDirectory" value="
    c:\keys\
    "/>
    .
  5. Edit other fields as necessary. See Table 17, "Fields in the Settings File," for a complete list.
  6. Save and close the settings file.

Configuring Your Settings for Multiple Merchants

If you have multiple merchant IDs, or if you are a reseller handling multiple merchants, you can configure the settings to allow different configurations for different merchant IDs.
To specify the settings for a specific merchant, prefix all settings, except for
cybs.merchantID
and the
cybs.proxy
*, with
<merchantID>.
The
cybs.proxy*
wildcard refers to the
proxyURL
,
proxyUser
,
proxyPassword
settings.
You have a new merchant with merchant ID of
NewMerchant
. To send only test transactions for this merchant, you can set all requests for
NewMerchant
to go to the test server:
<add key="cybs.NewMerchant.sendToProduction" value="false"/> <add key="cybs.sendToProduction" value="true"/>
With the second line of the example, the client will send all other requests to the production server.

Running the Test Applications

Run Test Applications

  1. Open a Windows command-line shell.
  2. Change to the directory where the test application is located.
  3. Type the name of the test application, then press Enter. The test application requests an Cybersource service, interprets the reply, and prints information about the result. If you receive a .NET exception, use the error message to debug the problem.

Deploying the Client to Another Computer

To deploy the client to another computer without running the installer provided by
Cybersource
, you must include all the files from the
lib
directory in your custom installer and then run it. Then the client is ready to be used on the computer.

Going Live

When you complete all of your system testing and are ready to accept real transactions from consumers, your deployment is ready to
go live
.
After your deployment goes live, use real card numbers and other data to test every card type you support. Because these are real transactions in which you are buying from yourself, use small monetary amounts to do the tests. Process an authorization, then capture the authorization, and later refund the money. Use your bank statements to verify that money is deposited into and withdrawn from your merchant bank account as expected. If you have more than one merchant ID, test each one separately.

Cybersource
Essentials Merchants

If you use
Cybersource
Essentials services, you can use the
Business Center
site to go live. For a description of the process of going live, see Getting Started with Cybersource Essentials.
You must also configure your client so that it sends transactions to the production server and not the test server. See the description of the configuration setting
cybs. sendToProduction
.

Cybersource
Advanced Merchants

If you use
Cybersource
Advanced services, see Getting Started with Cybersource Advanced for information about going live.
When your deployment goes live, your
Cybersource
account is updated so that you can send transactions to the
Cybersource
production server. If you have not already done so, you must provide your banking information to
Cybersource
so that your processor can deposit funds to your merchant bank account.
After
Cybersource
confirms that your account is live, make sure that you update your system so that it can send requests to the production server (
ics2wsa.ic3.com
or
ics2ws.in.ic3.com
in India) using your security key for the production environment. The test server (
ics2wstesta.ic3.com
) cannot be used for real transactions. For more information about sending transactions to the production server, see the description of the configuration setting
cybs. sendToProduction
.

Updating the Client to Use a Later API Version

Cybersource
periodically updates the Simple Order API. You can update your existing client to work with the new API version. For a list of the available API versions, go to: https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor
Alternately, if a new client is available that works with the later API version, you can download that new client.
The new client may have new functionality unrelated to the changes in the API. Read the release notes in the
CHANGES
file to determine if the new client contains new functionality that you want to use.

Update a Name-Value Pair Client

  1. Load
    src\CyberSource.Clients.sln
    in Visual Studio 2010.
  2. In the Solution Explorer, locate the Service References folder.
  3. Right-click
    NVPWebReference
    and choose
    Configure Service Reference
    .
  4. Update the Address field with the New WSDL URL. Typically, only the version number at the end of the URL needs to be updated.
  5. Build the Release configuration.
  6. Save a copy of the original
    CyberSource.Clients.dll
    and then replace it with the newly built
    CyberSource.Clients.dll
    .

Update a SOAP Client

  1. Load
    src\CyberSource.Clients.sln
    in Visual Studio 2010.
  2. In the Solution Explorer, locate the Service References folder.
  3. Right-click
    SoapWebReference
    and choose
    Configure Service Reference
    .
  4. Update the Address field with the New WSDL URL. Typically, only the version number at the end of the URL needs to be updated.
  5. Build the Release configuration.
  6. Save a copy of the original
    CyberSource.Clients.dll
    and then replace it with the newly built
    CyberSource.Clients.dll
    .

Update an XML Client

Updating the client is unnecessary. Start using the new namespace URI in your input XML documents. The client automatically uses the specified version.

Using Name-Value Pairs

This section explains how to request
Cybersource
services by using name-value pairs.

Requesting Cybersource Services

To request
Cybersource
services, write code that:
  • Collects information for the
    Cybersource
    services that you will use
  • Assembles the order information into requests
  • Sends the requests to the
    Cybersource
    server
  • Processes the reply information
    The
    Cybersource
    servers do not support persistent HTTP connections.
The instructions in this section explain how to write C# programs that request
Cybersource
services. For a list of API fields to use in your requests, see Related Documents.

Creating and Sending the Request

To use any
Cybersource
service, you must create and send a request that includes the required information for that service.
The example developed in the following sections shows basic code for requesting
Cybersource
services. In this example, Jane Smith is buying an item for 29.95.
The code in this section’s examples is incomplete. For complete sample programs, see the source code in the client’s samples\src\nvp directory.

Creating a New Visual Studio .NET Project

To get started, create a new project in Visual Studio .NET, and add a reference to the client library,
CyberSource.Clients.dll
, which is located in the client’s lib directory.

Importing the Client Classes

In the code for your application, add the following import statements:
using CyberSource.Clients; using System; using System.Collections; using System.Net; using System.Security.Cryptography; using System.ServiceModel; using System.ServiceMode1.Security;

Creating an Empty Request

You next create a hashtable that holds the request fields:
Hashtable request = new Hashtable();

Adding the Merchant ID

You next optionally add your merchant ID to the request:
request.Add( "merchantID", "infodev" );
This value overrides any value you set with the merchantID configuration setting (see Table 17, "Fields in the Settings File"). The merchant ID is case sensitive.

Adding Services to the Request

You next indicate the service that you want to use by adding a field to the request. For example, to request a credit card authorization:
request.Add( "ccAuthService_run", "true" );

Requesting a Sale

You can request multiple services by adding additional fields to the request. For example, if you fulfill the order immediately, you can request a credit card authorization and capture together (also referred to as a “sale”):
request.Add( "ccAuthService_run", "true" ); request.Add( "ccCaptureService_run", "true" );

Adding Service-Specific Fields to the Request

You next add the fields that are used by the services you are requesting. If you request multiple services and they share common fields, you must add the field once only.
request.Add( "billTo_firstName", "Jane" ); request.Add( "billTo_lastName", "Smith" ); request.Add( "card_accountNumber", "4111111111111111" ); request.Add( "item_0_unitPrice", "29.95" );
The previous example shows only a partial list of the fields you must send. Refer to Requesting Cybersource Services, for information about the guides that list all of the fields for the services that you are requesting.

Sending the Request

You next send the request to
Cybersource
, store the reply in a new hash table, and catch several exceptions that you might receive:
try {   Hashtable reply = NVPClient.RunTransaction( request );   SaveOrderState();   // Using the Decision and Reason Code describes the ProcessReply   // method.   ProcessReply( reply ); } catch (CryptographicException ce) {   SaveOrderState();   Console.WriteLine( ce.ToString() ); } catch (WebException we) {   SaveOrderState();   /*    * Some types of WebException indicate that the transaction may have been    * completed by CyberSource. The sample code shows how to identify these    * exceptions. If you receive such an exception, and your request included a    * payment service, you should use the Cybersource transaction search screens to    * determine whether the transaction was processed.    */   Console.WriteLine( we.ToString() ); }private static void SaveOrderState() {   /*    * This is where you store the order state in your system for post-transaction    * analysis. Be sure to store the consumer information, the values of the reply    * fields, and the details of any exceptions that occurred.    */ }
In the preceding example, when an exception occurs, the exception is printed to the console. Your web store should also display a message to the consumer indicating that you were unable to process the order. The sample code for the name-value pair client shows you how to provide feedback to the consumer.
Also, if the transaction fails, and the request did not include any payment services, you may be able to resend the transaction. The sample code for the name-value pair client shows you how to do this.

Interpreting the Reply

After the
Cybersource
server processes your request, it sends a reply message that contains information about the services you requested. You receive different fields depending on the services you request and the outcome of each service.
To use the reply information, you must integrate it into your system and any other system that uses that data. For example, you can store the reply information in a database and send it to other back office applications.
You must write an error handler to process the reply information that you receive from
Cybersource
. Do not show the reply information directly to consumers. Instead, present an appropriate response that tells consumers the result.
Because
Cybersource
may add reply fields and reason codes at any time, you should parse the reply data according to the names of the fields instead of their order in the reply.
The most important reply fields to evaluate are the following:
  • decision
    : A one-word description of the results of your request. The decision is one of the following:
  • reasonCode
    : A numeric code that provides more specific information about the results of your request.
You also receive a reason code for each service in your request. You can use these reason codes to determine whether a specific service succeeded or failed. If a service fails, other services in your request may not run. For example, if you request a credit card authorization and capture, and the authorization fails, the capture does not run. The reason codes for each service are described in .
We reserve the right to add new reason codes at any time. If your error handler receives a reason code that it does not recognize, it should use the decision to interpret the reply.

Using the Decision and Reason Code

The following example shows how you can use the decision and the reason code to display an appropriate message to the consumer.
private static bool ProcessReply( Hashtable reply ) {   string template = GetTemplate(      ((string)reply["decision"]).ToUpper() );   string content  = GetContent( reply );   // This example writes the message to the console. Choose an appropriate display   // method for your own application.   Console.WriteLine( template, content ); } private static string GetTemplate( string decision ) {   // Retrieves the text that corresponds to the decision.   if ("ACCEPT".Equals( decision )) {     return( "The order succeeded.{0}" );   }   if ("REJECT".Equals( decision )) {     return( "Your order was not approved.{0}" );   }   // ERROR, or an unknown decision   return( "Your order could not be completed at this time.{0}" +           "\nPlease try again later." ); } private static string GetContent( Hashtable reply ) {   /*    * Uses the reason code to retrieve more details to add to the template.    *    * The messages returned in this example are meant to demonstrate how to    * retrieve the reply fields. Your application should display user-friendly    * messages.    */   int reasonCode = int.Parse( (string) reply["reasonCode"] );   switch (reasonCode) {     // Success     case 100:       return( "\nRequest ID: " + reply["requestID"] );     // Missing field or fields     case 101:       return( "\nThe following required fields are missing: " +               EnumerateValues( reply, "missingField" ) );     // Invalid field or fields     case 102:       return( "\nThe following fields are invalid: " +               EnumerateValues( reply, "invalidField" ) );     // Insufficient funds     case 204:       return( "\nInsufficient funds in the account. Please use a " +               "different card or select another form of payment." );     // Add additional reason codes here that you must handle more specifically.     default:       // For all other reason codes, such as unrecognized reason codes, or codes       // that do not require special handling, return an empty string.       return( String.Empty );   } } private static string EnumerateValues( Hashtable reply,                                        string fieldName ) {   System.Text.StringBuilder sb = new System.Text.StringBuilder();   string val = "";   for (int i = 0; val != null; ++i) {     val = (string) reply[fieldName + "_" + i];     if (val != null) {       sb.Append( val + "\n" );     }   }   return( sb.ToString() ); }

For
Cybersource
Advanced Merchants: Handling
Decision Manager
Reviews

The information in this section applies only to
Cybersource
Advanced merchants.
If you use
Decision Manager
, you may also receive the
REVIEW
value in the
decision
field.
REVIEW
means that
Decision Manager
has marked the order for review based on how you configured the
Decision Manager
rules.
If you will be using
Decision Manager
, you have to determine how to handle the new
REVIEW
value. Ideally, you will update your order management system to recognize the
REVIEW
response and handle it according to your business rules. If you cannot update your system to handle the
REVIEW
response, we recommend that you choose one of these options:
  • If you authorize and capture the credit card payment at the same time, treat the
    REVIEW
    response like a
    REJECT
    response. Rejecting any orders that are marked for review may be appropriate if your product is a software download or access to a Web site. If supported by your processor, you may also want to reverse the authorization.
  • If you approve the order after reviewing it, convert the order status to
    ACCEPT
    in your order management system. You can request the credit card capture without requesting a new authorization.
  • If you approve the order after reviewing it but cannot convert the order status to
    ACCEPT
    in your system, request a new authorization for the order. When processing this new authorization, you must disable
    Decision Manager
    . Otherwise the order will be marked for review again. For details about the API field that disables
    Decision Manager
    , see the .
Alternately, you can specify a custom business rule in
Decision Manager
so that authorizations originating from a particular internal IP address at your company are automatically accepted.
If supported by your processor, you may want to reverse the original authorization.

Requesting Multiple Services

When you request multiple services in one request, Cybersource processes the services in a specific order. If a service fails, Cybersource does not process the subsequent services in the request.
For example, in the case of a sale (a credit card authorization and a capture requested together), if the authorization service fails, Cybersource will not process the capture service. The reply you receive only includes reply fields for the authorization.
Many Cybersource services include “ignore” fields that tell Cybersource to ignore the result from the first service when deciding whether to run the subsequent services. In the case of the sale, even though the issuing bank gives you an authorization code, Cybersource might decline the authorization based on the AVS or card verification results. Depending on your business needs, you might choose to capture these types of declined authorizations anyway. You can set the
businessRules_ignoreAVSResult
field to
"true"
in your combined authorization and capture request:
request.put( "businessRules_ignoreAVSResult", "true" );
This tells Cybersource to continue processing the capture even if the AVS result causes Cybersource to decline the authorization. In this case you would then get reply fields for both the authorization and the capture in your reply.
You are charged only for the services that Cybersource performs.

Retrying When System Errors Occur

You must design your transaction management system to include a way to correctly handle
Cybersource
system errors. Depending on which payment processor is handling the transaction, the error may indicate a valid
Cybersource
system error, or it may indicate a processor rejection because of some type of invalid data. In either case, we recommend that you do not design your system to retry sending a transaction many times in the case of a system error.
Instead, we recommend that you retry sending the request only two or three times with successively longer periods of time between each retry. For example, after the first system error response, wait 30 seconds and then retry sending the request. If you receive the same error a second time, wait one minute before you send the request again. Depending on the situation, you may decide you can retry sending the request after a longer time period. Determine what is most appropriate for your business situation.
If after several retry attempts you are still receiving a system error, it is possible that the error is actually being caused by a processor rejection and not a
Cybersource
system error. In that case, we suggest that you either:
  • Search for the transaction in the
    Business Center
    (depending on which one you normally use), look at the description of the error on the Transaction Detail page, and call your processor to determine if and why they are rejecting the transaction.
  • Contact
    Cybersource
    Customer Support to confirm whether your error is truly caused by a
    Cybersource
    system issue.
If
TSYS Acquiring Solutions
is your processor, you may want to follow the first suggestion as there are several common
TSYS Acquiring Solutions
processor responses that are returned to you as system errors and that only
TSYS Acquiring Solutions
can address.

Creating an Application Settings File

After you finish writing code for your integration, you must create an application settings file. This file must contain at least the following information:
  • The directory that contains your security key
  • The location of the
    Cybersource
    server
See Table 17, "Fields in the Settings File," for a complete list of settings.
You can use the settings files that come with the sample applications as a starting point for your own settings file. See Configuring the Test Applications, for more information.

Using XML

This section explains how to request
Cybersource
services by using XML.

Requesting Cybersource Services

To request Cybersource services, write code that:
  • Collects information for the Cybersource services that you will use
  • Assembles the order information into requests
  • Sends the requests to the Cybersource server
  • Processes the reply information
    The Cybersource servers do not support persistent HTTP connections.
The instructions in this section explain how to write C# programs that request CyberSource services. For a list of API fields to use in your requests, see Related Documents.

Creating a Request Document

The XML client allows you to create an XML request document using any application, then send the request to
Cybersource
. For example, if you have a customer relationship management (CRM) system that uses XML to communicate with other systems, you can use the CRM system to generate request documents.
The request document must validate against the XML schema for
Cybersource
transactions. To view the schema, go to: https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor and look at the
xsd
file for the version of the Simple Order API you are using.
Make sure that the elements in your document appear in the correct order. If they do not, your document will not validate, and your request will fail.
The example that is developed in the following sections shows a basic XML document for requesting
Cybersource
services. In this example, Jane Smith is buying an item for 29.95.
The XML document in this example is incomplete. For complete examples, see
sample.xml
in the client’s
samples\bin
directory.

Creating an Empty Request

Add the XML declaration and the document’s root element:
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.17"> </requestMessage>
Make sure that the API version specified at the end of the namespace is correct. For example, to communicate with version 1.19, you must use the namespace
urn:schemas-cybersource-com:transaction-data-1.19
. When you must update the API version, see Updating the Client to Use a Later API Version .
The XML document that you receive in the reply always has the prefix
c:
, for example:
xmlns:c="urn:schemas-cybersource-com:transaction-data-1.17"
. Make sure you use an XML parser that supports namespaces.

Adding the Merchant ID

Optionally, you can add the merchant ID to the request:
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.17">   <merchantID>infodev</merchantID> </requestMessage>
This value overrides any value that you set with the merchantID configuration setting. For more information about the merchantID configuration setting, see Fields in the Settings File. The merchant ID is case sensitive.

Adding Services to the Request

You next indicate the service that you want to use by creating an element for that service in the request, then setting the element’s
run
attribute to
true
. For example, to request a credit card authorization:
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.15">   <merchantID>infodev</merchantID>   <ccAuthService run="true"/> </requestMessage>

Requesting a Sale

You can request multiple services by creating additional elements. For example, if you fulfill the order immediately, you can request a credit card authorization and capture together (referred to as a “sale”):
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.17">   <merchantID>infodev</merchantID>   <ccAuthService run="true"/>   <ccCaptureService run="true"/> </requestMessage>

Adding Service-Specific Fields to the Request

You next add the fields that are used by the services you are requesting. Most fields are child elements of container elements; for example, a
<card>
element contains the consumer’s credit card information.
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.15">   <merchantID>infodev</merchantID>   <billTo>     <firstName>Jane</firstName>     <lastName>Smith</lastName>   </billTo>   <item id="0">   </card>     <unitPrice>29.95</unitPrice>   </item>   <card>     <accountNumber>4111111111111111</accountNumber>   <ccAuthService run="true"/> </requestMessage>
The example above shows only a partial list of the fields you must send. Refer to Related Documents, for information about the guides that list all of the fields for the services that you are requesting.

Sending the Request

Once you have created an XML request document, you can use a .NET application to send the request to
Cybersource
. The example that follows is written in C#.
The code in this section’s examples is incomplete. For complete sample programs, see the source code in the client’s
samples\src\xml
directory.

Creating a New Visual Studio .NET Project

To start, create a new project in Visual Studio .NET. Then you must add a reference to the client library,
CyberSource.Clients.dll
(located in the client’s lib directory) and to the .NET Framework
System.Security.dll
library.

Importing the Client Classes

In the code for your application, add the following import statements:
using CyberSource.Clients; using System; using System.Net; using System.Xml; using System.Security.Cryptography

Sending the Request

You next read the XML request document, send the request to
Cybersource
, store the reply in a new
XmlDocument
object, and catch several exceptions that you might receive:
try {   XmlDocument request = new XmlDocument();   request.Load( "MyXmlDocument.xml" );   XmlDocument reply = XmlClient.RunTransaction( request );   SaveOrderState();   // "Using the Using the Decision and Reason Code Fields describes the ProcessReply   // method.   ProcessReply( reply ); } catch (CryptographicException ce) {   SaveOrderState();   Console.WriteLine( ce.ToString() ); } catch (FaultException fe) {   SaveOrderState();   /*    * Some types of FaultException indicate that the transaction may have been    * completed by CyberSource. The sample code shows how to identify these    * exceptions. If you receive such an exception, and your request included a    * payment service, you should use the Cybersource transaction search screens to    * determine whether the transaction was processed.    */   Console.WriteLine( fe.ToString() ); } catch (WebException we) {   SaveOrderState();   /*    * Some types of WebException indicate that the transaction may have been completed    * by CyberSource. The sample code shows how to identify these exceptions. If you    * receive such an exception, and your request included a payment service, you    * should use the Cybersource transaction search screens to determine whether the    * transaction was processed.    */   Console.WriteLine( we.ToString() ); } private static void SaveOrderState() {   /*    * This is where you store the order state in your system for post-transaction    * analysis. Be sure to store the consumer information, the values of the reply    * fields, and the details of any exceptions that occurred.    */ }
In the preceding example, when an exception occurs, the exception is printed to the console. Your web store should also display a message to the consumer indicating that you were unable to process the order. The sample code for the XML client shows you how to provide feedback to the consumer.
Also, if the transaction fails, and the request did not include any payment services, you may be able to resend the transaction. The sample code for the XML client shows you how to do this.

Interpreting the Reply

After the
Cybersource
server processes your request, it sends a reply message that contains information about the services you requested. You receive different fields depending on the services you request and the outcome of each service.
To use the reply information, you must integrate it into your system and any other system that uses that data. For example, you can store the reply information in a database and send it to other back office applications.
You must write an error handler to process the reply information that you receive from
Cybersource
. Do not show the reply information directly to consumers. Instead, present an appropriate response that tells consumers the result.
Because we may add reply fields and reason codes at any time, you should parse the reply data according to the names of the fields instead of their order in the reply.
The most important reply fields to evaluate are the following:
  • decision
    : A one-word description of the results of your request. The decision is one of the following:
  • reasonCode
    : A numeric code that provides more specific information about the results of your request.
You also receive a reason code for each service in your request. You can use these reason codes to determine whether a specific service succeeded or failed. If a service fails, other services in your request may not run. For example, if you request a credit card authorization and capture, and the authorization fails, the capture does not run. The reason codes for each service are described in .
We reserve the right to add new reason codes at any time. If your error handler receives a reason code that it does not recognize, it should use the decision to interpret the reply.

Using the Decision and Reason Code

The following example shows how you can use the decision and the reason code to display an appropriate message to the consumer.
private static bool ProcessReply( XmlDocument reply ) {   // The following code allows you to use XPath with the Cybersource schema, which   // uses a non-empty default namespace.   XmlNamespaceManager nsmgr     = new XmlNamespaceManager( reply.NameTable );   nsmgr.AddNamespace( "cybs", Client.CYBS_NAMESPACE );   XmlNode replyMessage     = reply.SelectSingleNode( "cybs:replyMessage", nsmgr);   string decision = replyMessage.SelectSingleNode(      "cybs:decision/text()", nsmgr ).Value;   string template = GetTemplate( decision.ToUpper() );   string content  = GetContent( replyMessage, nsmgr );   // This example writes the message to the console. Choose an appropriate display   // method for your own application.   Console.WriteLine( template, content ); } private static string GetTemplate( string decision ) {   // Retrieves the text that corresponds to the decision.   if ("ACCEPT".Equals( decision )) {     return( "The order succeeded.{0}" );   } }   if ("REJECT".Equals( decision )) {     return( "Your order was not approved.{0}" );   }      // ERROR, or an unknown decision   return( "Your order could not be completed at this time.{0}" +           "\nPlease try again later." ); private static string GetContent(    XmlNode replyMessage, XmlNamespaceManager nsmgr ) {   /*    * Uses the reason code to retrieve more details to add to the template.    *    * The messages returned in this example are meant to demonstrate how to retrieve    * the reply fields. Your application should display user-friendly messages.    */   string textVal = replyMessage.SelectSingleNode(      "cybs:reasonCode/text()", nsmgr ).Value;   int reasonCode = int.Parse( textVal );   switch (reasonCode) {     // Success     case 100:       return( "\nRequest ID: " +         replyMessage.SelectSingleNode(            "cybs:requestID/text()", nsmgr ).Value );     // Missing field or fields     case 101:       return( "\nThe following required fields are missing: " +               EnumerateValues( replyMessage.SelectNodes(                 "cybs:missingField/text()", nsmgr ) ) );     // Invalid field or fields     case 102:       return( "\nThe following fields are invalid: " +               EnumerateValues( replyMessage.SelectNodes(                 "cybs:invalidField/text()", nsmgr ) ) );     // Insufficient funds     case 204:       return( "\nInsufficient funds in the account. Please use a " +               "different card or select another form of payment." );     // Add additional reason codes here that you must handle more specifically.     default:       // For all other reason codes (for example, unrecognized reason codes, or       // codes that do not require special handling), return an empty string.       return( String.Empty );   } } private static string EnumerateValues( XmlNodeList nodes ) {   System.Text.StringBuilder sb = new System.Text.StringBuilder();   foreach (XmlNode node in nodes) {     sb.Append( val + "\n" );   }   return( sb.ToString() ); }

For
Cybersource
Advanced Merchants: Handling
Decision Manager
Reviews

The information in this section applies only to
Cybersource
Advanced merchants.
If you use
Decision Manager
, you may also receive the
REVIEW
value in the
decision
field.
REVIEW
means that
Decision Manager
has marked the order for review based on how you configured the
Decision Manager
rules.
If you will be using
Decision Manager
, you have to determine how to handle the new
REVIEW
value. Ideally, you will update your order management system to recognize the
REVIEW
response and handle it according to your business rules. If you cannot update your system to handle the
REVIEW
response, we recommend that you choose one of these options:
  • If you authorize and capture the credit card payment at the same time, treat the
    REVIEW
    response like a
    REJECT
    response. Rejecting any orders that are marked for review may be appropriate if your product is a software download or access to a Web site. If supported by your processor, you may also want to reverse the authorization.
  • If you approve the order after reviewing it, convert the order status to
    ACCEPT
    in your order management system. You can request the credit card capture without requesting a new authorization.
  • If you approve the order after reviewing it but cannot convert the order status to
    ACCEPT
    in your system, request a new authorization for the order. When processing this new authorization, you must disable
    Decision Manager
    . Otherwise the order will be marked for review again. For details about the API field that disables
    Decision Manager
    , see the .
Alternately, you can specify a custom business rule in
Decision Manager
so that authorizations originating from a particular internal IP address at your company are automatically accepted.
If supported by your processor, you may want to reverse the original authorization.

Requesting Multiple Services

When you request multiple services in one request,
Cybersource
processes the services in a specific order. If a service fails,
Cybersource
does not process the subsequent services in the request.
For example, in the case of a sale (a credit card authorization and a capture requested together), if the authorization service fails,
Cybersource
does not process the capture service. The reply you receive only includes reply fields for the authorization.
Many
Cybersource
services include “ignore” fields that tell
Cybersource
to ignore the result from the first service when deciding whether to run the subsequent services. In the case of the sale, even though the issuing bank gives you an authorization code,
Cybersource
might decline the authorization based on the AVS or card verification results. Depending on your business needs, you might choose to capture these types of declined authorizations anyway. You can set the
businessRules_ignoreAVSResult
field to
"true"
in your combined authorization and capture request:
<businessRules>     <ignoreAVSResult>true</ignoreAVSResult> </businessRules>
This tells
Cybersource
to continue processing the capture even if the AVS result causes
Cybersource
to decline the authorization. In this case you would then get reply fields for both the authorization and the capture in your reply.
You are charged only for the services that
Cybersource
performs.

Retrying When System Errors Occur

You must design your transaction management system to include a way to correctly handle
Cybersource
system errors. Depending on which payment processor is handling the transaction, the error may indicate a valid
Cybersource
system error, or it may indicate a processor rejection because of some type of invalid data. In either case, we recommend that you do not design your system to retry sending a transaction many times in the case of a system error.
Instead, we recommend that you retry sending the request only two or three times with successively longer periods of time between each retry. For example, after the first system error response, wait 30 seconds and then retry sending the request. If you receive the same error a second time, wait one minute before you send the request again. Depending on the situation, you may decide you can retry sending the request after a longer time period. Determine what is most appropriate for your business situation.
If after several retry attempts you are still receiving a system error, it is possible that the error is actually being caused by a processor rejection and not a
Cybersource
system error. In that case, we suggest that you either:
  • Search for the transaction in the
    Business Center
    (depending on which one you normally use), look at the description of the error on the Transaction Detail page, and call your processor to determine if and why they are rejecting the transaction.
  • Contact
    Cybersource
    Customer Support to confirm whether your error is truly caused by a
    Cybersource
    system issue.
If
TSYS Acquiring Solutions
is your processor, you may want to follow the first suggestion as there are several common
TSYS Acquiring Solutions
processor responses that are returned to you as system errors and that only
TSYS Acquiring Solutions
can address.

Creating an Application Settings File

After you finish writing code for your integration, you must create an application settings file. This file must contain, at a minimum, the following information:
  • The directory that contains your security key
  • The location of the
    Cybersource
    server
See Table 17, "Fields in the Settings File," for a complete list of settings.
You can use the settings files that come with the sample applications as a starting point for your own settings file. See Configuring the Test Applications, for more information.

Using SOAP

This section explains how to request
Cybersource
services by using the Simple Object Access Protocol (SOAP).

Requesting Cybersource Services

To request Cybersource services, write code that:
  • Collects information for the Cybersource services that you will use
  • Assembles the order information into requests
  • Sends the requests to the Cybersource server
    The Cybersource servers do not support persistent HTTP connections.
  • Processes the reply information
The instructions in this section explain how to write C# programs that request CyberSource services. For a list of API fields to use in your requests, see Related Documents.

Creating and Sending the Request

To use any
Cybersource
service, you must create and send a request that includes the required information for that service.
The example that is developed in the following sections shows basic code for requesting
Cybersource
services. In this example, Jane Smith is buying an item for 29.95.
The code in this section’s examples is incomplete. For complete sample programs, see the source code in the client’s
samples\src\soap
directory.

Creating a New Visual Studio .NET Project

To get started, create a new project in Visual Studio .NET. Then you must add a reference to the client library,
CyberSource.Clients.dll
(located in the client’s lib directory). You must also add references to the .NET Framework libraries
System.ServiceModel.dll
and
System.Security.dll
.

Importing the Client Classes

In the code for your application, add the following import statements:
using System; using System.Net; using System.Security.Cryptography; using System.ServiceModel; using System.ServiceModel.Security; using CyberSource.Clients; using CyberSource.Clients.SoapWebReference;

Creating an Empty Request

You next create a RequestMessage object that holds the request fields:
RequestMessage request = new RequestMessage();

Adding the Merchant ID

You next optionally add your merchant ID to the request:
request.merchantID = "infodev";
This value overrides any value you set with the merchantID configuration setting (see Fields in the Settings File). The merchant ID is case sensitive.

Adding Services to the Request

You next indicate the service that you want to use by creating an object for that service in the request, then setting the object’s
run
property to
true
. For example, to request a credit card authorization:
request.ccAuthService = new CCAuthService(); request.ccAuthService.run = "true";

Requesting a Sale

You can request multiple services by creating additional objects. For example, if you fulfill the order immediately, you can request a credit card authorization and capture together (referred to as a “sale”):
request.ccAuthService = new CCAuthService(); request.ccAuthService.run = "true"; request.ccCaptureService = new CCCaptureService(); request.ccCaptureService.run = "true";

Adding Service-Specific Fields to the Request

You next add the fields that are used by the services you are requesting. Most fields are properties of additional objects; for example, a
Card
object contains the consumer’s credit card information.
BillTo billTo = new BillTo(); billTo.firstName = "Jane"; billTo.lastName = "Smith"; request.billTo = billTo; Card card = new Card(); card.accountNumber = "4111111111111111"; request.card = card; // there is one item in this sample request.item = new Item[1]; Item item = new Item(); item.id = "0"; item.unitPrice = "29.95"; request.item[0] = item;
The example above shows only a partial list of the fields you must send. Refer to Related Documents for information about the guides that list all of the fields for the services that you are requesting.

Sending the Request

You next send the request to
Cybersource
, store the reply in a new
ReplyMessage
object, and handle several exceptions that you might receive.
try {   ReplyMessage reply =
SoapClient
.RunTransaction( request );   SaveOrderState();   // Using the Decision and Reason Code describes the ProcessReply   // method.   ProcessReply( reply ); } catch (CryptographicException ce) {   SaveOrderState();   Console.WriteLine( ce.ToString() );   Console.WriteLine( sbe.ToString() ); } catch (WebException we) {   SaveOrderState();   /*    * Some types of WebException indicate that the transaction may have been    * completed by CyberSource. The sample code shows how to identify these exceptions.    * If you receive such an exception, and your request included a payment service,    * you should use the Cybersource transaction search screens to determine whether    * the transaction was processed.    */   Console.WriteLine( we.ToString() ); } private static void SaveOrderState() {   /*    * This is where you store the order state in your system for post-transaction    * analysis. Be sure to store the consumer information, the values of the reply    * fields, and the details of any exceptions that occurred.    */ }
In the preceding example, when an exception occurs, the exception is printed to the console. Your web store should also display a message to the consumer indicating that you were unable to process the order. The sample code for the SOAP client shows you how to provide feedback to the consumer.
Also, if the transaction fails, and the request did not include any payment services, you may be able to resend the transaction. The sample code for the SOAP client shows you how to do this.

Interpreting the Reply

After the
Cybersource
server processes your request, it sends a reply message that contains information about the services you requested. You receive different fields depending on the services you request and the outcome of each service.
To use the reply information, you must integrate it into your system and any other system that uses that data. For example, you can store the reply information in a database and send it to other back office applications.
You must write an error handler to process the reply information that you receive from
Cybersource
. Do not show the reply information directly to consumers. Instead, present an appropriate response that tells consumers the result.
Because we may add reply fields and reason codes at any time, you should parse the reply data according to the names of the fields instead of their order in the reply.
The most important reply fields to evaluate are the following:
  • decision
    : A one-word description of the results of your request. The decision is one of the following:
  • reasonCode
    : A numeric code that provides more specific information about the results of your request.
You also receive a reason code for each service in your request. You can use these reason codes to determine whether a specific service succeeded or failed. If a service fails, other services in your request may not run. For example, if you request a credit card authorization and capture, and the authorization fails, the capture does not run. The reason codes for each service are described in .
We reserve the right to add new reason codes at any time. If your error handler receives a reason code that it does not recognize, it should use the decision to interpret the reply.

Using the Decision and Reason Code

The following example shows how you can use the decision and the reason code to display an appropriate message to the consumer.
private static bool ProcessReply( ReplyMessage reply ) {   string template = GetTemplate( reply.decision.ToUpper() );   string content  = GetContent( reply );   // This example writes the message to the console. Choose an appropriate display   // method for your own application.   Console.WriteLine( template, content ); } private static string GetTemplate( string decision ) {   // Retrieves the text that corresponds to the decision.   if ("ACCEPT".Equals( decision )) {     return( "The order succeeded.{0}" );   }   if ("REJECT".Equals( decision )) {     return( "Your order was not approved.{0}" );   }      // ERROR, or an unknown decision   return( "Your order could not be completed at this time.{0}" +           "\nPlease try again later." ); } private static string GetContent( ReplyMessage reply ) {   /*    * Uses the reason code to retrieve more details to add to the template.    * The messages returned in this example are meant to demonstrate how to retrieve    * the reply fields. Your application should display user-friendly messages.    */   int reasonCode = int.Parse( reply.reasonCode );   switch (reasonCode) {     // Success     case 100:       return( "\nRequest ID: " + reply.requestID );     // Missing field or fields     case 101:       return( "\nThe following required fields are missing: " +               EnumerateValues( reply.missingField ) );     // Invalid field or fields     case 102:       return( "\nThe following fields are invalid: " +               EnumerateValues( reply.invalidField ) );     // Insufficient funds     case 204:       return( "\nInsufficient funds in the account. Please use a " +               "different card or select another form of payment." );     // Add additional reason codes here that you must handle more specifically.     default:       // For all other reason codes, such as unrecognized reason codes or codes       // that do not require special handling, return an empty string.       return( String.Empty );   } } private static string EnumerateValues( string[] array ) {   System.Text.StringBuilder sb = new System.Text.StringBuilder();   foreach (string val in array) {     sb.Append( val + "\n" );   }   return( sb.ToString() ); }

For
Cybersource
Advanced Merchants: Handling
Decision Manager
Reviews

The information in this section applies only to
Cybersource
Advanced merchants.
If you use
Decision Manager
, you may also receive the
REVIEW
value in the
decision
field.
REVIEW
means that
Decision Manager
has marked the order for review based on how you configured the
Decision Manager
rules.
If you will be using
Decision Manager
, you have to determine how to handle the new
REVIEW
value. Ideally, you will update your order management system to recognize the
REVIEW
response and handle it according to your business rules. If you cannot update your system to handle the
REVIEW
response, we recommend that you choose one of these options:
  • If you authorize and capture the credit card payment at the same time, treat the
    REVIEW
    response like a
    REJECT
    response. Rejecting any orders that are marked for review may be appropriate if your product is a software download or access to a Web site. If supported by your processor, you may also want to reverse the authorization.
  • If you approve the order after reviewing it, convert the order status to
    ACCEPT
    in your order management system. You can request the credit card capture without requesting a new authorization.
  • If you approve the order after reviewing it but cannot convert the order status to
    ACCEPT
    in your system, request a new authorization for the order. When processing this new authorization, you must disable
    Decision Manager
    . Otherwise the order will be marked for review again. For details about the API field that disables
    Decision Manager
    , see the .
Alternately, you can specify a custom business rule in
Decision Manager
so that authorizations originating from a particular internal IP address at your company are automatically accepted.
If supported by your processor, you may want to reverse the original authorization.

Requesting Multiple Services

When you request multiple services in one request, Cybersource processes the services in a specific order. If a service fails, Cybersource does not process the subsequent services in the request.
For example, in the case of a sale (a credit card authorization and a capture requested together), if the authorization service fails, Cybersource will not process the capture service. The reply you receive only includes reply fields for the authorization.
Many Cybersource services include “ignore” fields that tell Cybersource to ignore the result from the first service when deciding whether to run the subsequent services. In the case of the sale, even though the issuing bank gives you an authorization code, Cybersource might decline the authorization based on the AVS or card verification results. Depending on your business needs, you might choose to capture these types of declined authorizations anyway. You can set the
businessRules_ignoreAVSResult
field to
"true"
in your combined authorization and capture request:
BusinessRules businessRules = new BusinessRules(); businessRules.ignoreAVSResult = "true"; request.businessRules = businessRules;
This tells Cybersource to continue processing the capture even if the AVS result causes Cybersource to decline the authorization. In this case you would then get reply fields for both the authorization and the capture in your reply.
You are charged only for the services that Cybersource performs.

Retrying When System Errors Occur

You must design your transaction management system to include a way to correctly handle
Cybersource
system errors. Depending on which payment processor is handling the transaction, the error may indicate a valid
Cybersource
system error, or it may indicate a processor rejection because of some type of invalid data. In either case, we recommend that you do not design your system to retry sending a transaction many times in the case of a system error.
Instead, we recommend that you retry sending the request only two or three times with successively longer periods of time between each retry. For example, after the first system error response, wait 30 seconds and then retry sending the request. If you receive the same error a second time, wait one minute before you send the request again. Depending on the situation, you may decide you can retry sending the request after a longer time period. Determine what is most appropriate for your business situation.
If after several retry attempts you are still receiving a system error, the error may actually be caused by a processor rejection, not a
Cybersource
system error. In that case, we suggest one of these actions:
  • Search for the transaction in the
    Business Center
    (depending on which one you normally use), look at the description of the error on the Transaction Detail page, and call your processor to determine if and why the transaction was rejected.
  • Contact
    Cybersource
    Customer Support to confirm whether your error is truly caused by a
    Cybersource
    system issue.
If
TSYS Acquiring Solutions
is your processor, you may want to follow the first suggestion because several common
TSYS Acquiring Solutions
processor responses can be returned as system errors, and only
TSYS Acquiring Solutions
can address these errors.

Creating an Application Settings File

After you finish writing code for your integration, you must create an application settings file. This file must contain at least the directory that contains your security key and the location of the Cybersource server.
See Table 17, "Fields in the Settings File for a complete list of settings. You can use the settings files that come with the sample applications as a starting point for your own settings file. See Configuring the Test Applications for more information.

Setting the Connection Limit

This section explains how to increase the number of simultaneous connections between the client and
Cybersource
.
By default, you can create only two simultaneous connections to an HTTP server. By increasing the number of connections, you can avoid a backlog of requests during times of very high transaction volume. Microsoft recommends for the connection limit a value that is 12 times the number of CPUs. For example, if you have two CPUs, you can set the connection limit to 24. To determine the optimum setting for your application, make sure to run performance tests.

Examples

You can increase the number of connections in many ways, for example by using an application- or server-specific configuration file where you can change the setting for a single or for all hosts. The examples below describe briefly some of the methods that you can use to increase connection limits.

cybs.connectionLimit

When set to a value other than
-1
, the
cybs.connectionLimit
setting in the client increases the limit for the host where you are sending the request by executing these statements on your behalf:
ServicePoint sp = ServicePointManager.FindServicePoint(uri); sp.ConnectionLimit = config.ConnectionLimit;

<connectionManagement>

You can set the connection limit by using .NET's
<connectionManagement>
tag. In this example, the connection limit for
Cybersource
test and production hosts is 12 while the limit for all other hosts is 2:
<system.net> <connectionManagement> <add address = "https://ics2wstesta.ic3.com" maxconnection = "12" /> <add address = "https://ics2wsa.ic3.com" maxconnection = "12" /> <add address = "*" maxconnection = "2" /> </connectionManagement> </system.net>

DefaultConnectionLimit

You can set the connection limit for all hosts to which your application is connected before a connection is made by using the following line in your start-up code:
ServicePointManager.DefaultConnectionLimit = your_value_here;

References

For more information on these and other methods to increase the connection limits, see the following Microsoft documentation:

Sample ASP.NET Code Using Visual Basic

The following sample files illustrate how to use the Name-Value Pair client in ASP.NET using Visual Basic. The
web.config
file is a sample web application configuration file containing sample entries required by the client. The other files are simple web forms and their corresponding code-behind files. The
Checkout.aspx
file contains a pre-filled form. When you press the Submit button, it will post the entered data to
Checkout2.aspx
, which will send the transaction to
Cybersource
.

Listing 1: web.config

<?xml version="1.0"?> <configuration>    <appSettings>       <add key="cybs.merchantID" value="your_merchant_id"/>       <add key="cybs.keysDirectory" value="c:\keys"/>       <add key="cybs.sendToProduction" value="false"/>       <!-- Logging should normally be disabled in production as it would -->       <!-- slow down the processing. Enable it only when troubleshooting -->       <!-- an issue. -->       <add key="cybs.enableLog" value="false"/>       <add key="cybs.logDirectory" value="C:\Program Files\CyberSource Corporation\simapi-net-2.0-5.0.0\logs"/>       <!-- Please refer to the Connection Limit section in the README for -->       <!-- details on this setting and alternate ways to set the -->       <!-- connection limit. When not specified or is set to -1, the -->       <!-- client will implicitly use the connection limit currently in -->       <!-- force, which would be 2 if none of the alternate methods are -->       <!-- used. -->       <add key="cybs.connectionLimit" value="-1"/>    </appSettings> </configuration>

Listing 2: Checkout.aspx

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Checkout.aspx.vb" Inherits="NVP" Debug="true"%> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server">    <title>Name Value Pair - Order Page</title> </head> <body> <form action="Checkout2.aspx" method="post"> Please confirm the information below and click the Submit button to perform the authorization. <br/>    <h3>Billing Information</h3>    First Name:<br/>    <input type="text" name="billTo_firstName" value="John"/>    <br/>Last Name:<br/>    <input type="text" name="billTo_lastname" value="Doe"/>    <br/>Street Address:<br/>    <input type="text" name="billTo_street1" value="1295 Charleston Road"/>    <br/>City:<br/>    <input type="text" name="billTo_city" value="Mountain View"/>    <br/>State:<br/>    <input type="text" name="billTo_state" value="CA"/>    <br/>Postal Code:<br/>    <input type="text" name="billTo_postalCode" value="94043"/>    <br/>Country:<br/>    <input type="text" name="billTo_country" value="US"/>    <br/>    <h3>Credit Card Information</h3>    Amount:<br/>    <input type="text" name="item_0_unitPrice" value="10.00"/>    <br/>Credit Card Number:<br/>    <input type="text" name="card_accountNumber" value="4111111111111111"/>    <br/>Expiration month (mm):<br/>    <input type="text" name="card_expirationMonth" value="12"/>    <br/>Expiration year (yyyy):<br/>    <input type="text" name="card_expirationYear" value="2010"/>    <br/>Email Address:<br/>    <input type="text" name="billTo_email" value="nobody@cybersource.com"/>    <br/><input type="submit" value="Submit"/> </form> </body> </html>

Listing 3: Checkout.aspx.vb

Partial Class NVP    Inherits System.Web.UI.Page End Class

Listing 4: Checkout2.aspx

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Checkout2.aspx.vb" Inherits="NVP2" Debug="true"%> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server">    <title>Name Value Pair - Receipt</title> </head> <body>    <form id="form1" runat="server">    <div>    </div>    </form> </body> </html>

Listing 5: Checkout2.aspx.vb

Imports CyberSource.Clients.NVPClient Partial Class NVP2    Inherits System.Web.UI.Page    Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load       'Declare the request hashtable       Dim oRequest As New Hashtable       'Add non-user input fields       oRequest.Add("ccAuthService_run", "true")       oRequest.Add("merchantReferenceCode", "MRC-5254555")       'Add user input fields from post       oRequest.Add("billTo_firstName", Request.Form("billTo_firstName"))       oRequest.Add("billTo_lastName", Request.Form("billTo_lastName"))       oRequest.Add("billTo_street1", Request.Form("billTo_street1"))       oRequest.Add("billTo_city", Request.Form("billTo_city"))       oRequest.Add("billTo_state", Request.Form("billTo_state"))       oRequest.Add("billTo_postalCode", Request.Form("billTo_postalCode"))       oRequest.Add("billTo_country", Request.Form("billTo_country"))       oRequest.Add("billTo_email", Request.Form("billTo_email"))       oRequest.Add("card_accountNumber", Request.Form("card_accountNumber"))       oRequest.Add("card_expirationMonth", Request.Form("card_expirationMonth"))       oRequest.Add("card_expirationYear", Request.Form("card_expirationYear"))       oRequest.Add("item_0_unitPrice", Request.Form("item_0_unitPrice"))       oRequest.Add("purchaseTotals_currency", "USD")       'Declare the reply hashtable       Dim varReply As New Hashtable       'Run the transaction       varReply = CyberSource.Clients.NVPClient.RunTransaction(oRequest)       'Print reply data to the browser       Response.Write("reasonCode: " & varReply("reasonCode").ToString)       Response.Write("<BR>Decision: " & varReply("decision").ToString)       Response.Write("<BR>RequestID: " & varReply("requestID").ToString)       Response.Write("<BR>Merchant Reference Code: " & varReply("merchantReferenceCode").ToString)    End Sub End Class

Java Client

  • The Java client for the Simple Order API is supported on 64-bit operating systems.
  • If you are building an application to sell to others, see Using the Client Application Fields. This section includes a list of API fields you can use in your request that describe the application, its version, and its user. If you use these fields in your request, you can view their values in the Transaction Search Details page of the
    Business Center
    .

Choosing Your API and Client

API Variations

Choose either of these options of the Simple Order API:
  • Name-value pairs: simpler to use. The test that you run immediately after installing the client uses name-value pairs.
  • XML: requires you to create and parse XML documents
To introduce new API fields and features,
Cybersource
regularly updates the Simple Order API. You can update your existing client to work with the new API version. For the latest version of the server-side API for the
Cybersource
services, go to https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor. For transactions in India, go to https://ics2ws.in.ic3.com/commerce/1.x/transactionProcessor. When configuring the client, indicate the version of the API (not the current version of the client) you want to use in the targetAPIVersion configuration property. For example, to use the 1.18 version of the API, set the property to
1.18
. For more information, see
targetAPIVersion
.

Client Versions

The client version is the version of the client-side code that you use to access the
Cybersource
services. This version is different from the API version.
A direct upgrade path from the 1.5.0 version of the Web Services Client for Java to the most recent version of the client is not available because the client was redesigned starting with the 2.0.0 release.

Sample Code

The client package contains two samples that you can use to test the client:
  • Name-value pairs: See
    AuthCaptureSample.java
    in <main directory>
    /samples/nvp/src/com/cybersource/sample
    .
  • XML: Before implementing your code to process XML requests, we recommend that you examine the name-value pair sample code listed above.
For the XML sample code, see
AuthSample.java
in <main directory>
/samples/xml/src/com/cybersource/sample
.

Basic Java Program Example

The example below shows the primary code required to send a Simple Order API request for credit card authorization and process the reply. The example uses name-value pairs. For a complete example, see the sample program included in the package (see Sample Code). Using Name-Value Pairs, shows you how to create the code.
package com.cybersource.sample; import java.util.*; import com.cybersource.ws.client.*; public class SimpleAuthSample {   public static void main( String[] args )   {     Properties props = Utility.readProperties( args );     HashMap request = new HashMap();     // In this sample, we are processing a credit card authorization.     request.put( "ccAuthService_run", "true" );     // Add required fields     request.put( "merchantReferenceCode", "MRC-14344" );     request.put( "billTo_firstName", "Jane" );     request.put( "billTo_lastName", "Smith" );     request.put( "billTo_street1", "1295 Charleston Road" );     request.put( "billTo_city", "Mountain View" );     request.put( "billTo_state", "CA" );     request.put( "billTo_postalCode", "94043" );     request.put( "billTo_country", "US" );     request.put( "billTo_email", "jsmith@example.com" );     request.put( "card_accountNumber", "4111111111111111" );     request.put( "card_expirationMonth", "12" );     request.put( "card_expirationYear", "2010" );     request.put( "purchaseTotals_currency", "USD" );     // This sample order contains two line items.     request.put( "item_0_unitPrice", "12.34" );     request.put( "item_1_unitPrice", "56.78" );     // Add optional fields here according to your business needs.     // For information about processing the reply,     // see Using the Decision and Reason Code Fields.     try     {         HashMap reply = Client.runTransaction( request, props );     }     catch (ClientException e) {         if (e.isCritical())         {             handleCriticalException( e, request );         }     }     catch (FaultException e) {         if (e.isCritical())         {             handleCriticalException( e, request );         }         }   } }

Installing and Testing the Client

Minimum System Requirements

  • This client is supported on the Windows 2000/XP/2003, Linux, and Solaris platforms.
  • The minimum Java SDK supported are Oracle or IBM Java SDK 1.6 or later. Depending on the package that you choose, you also need one of these:
    • For Oracle Java SDK versions earlier than 1.4.0, you need the Java Secure Socket Extension (JSSE) 1.0.3_02 or later (see http://java.sun.com/products/jsse).
    • For IBM Java SDK, you need IBMJSEE 1.0.2 or later.
  • Maven 3 or later.
  • Unlimited Strength Jurisdiction Policy files from Oracle® (
    US_export_policy.jar
    and
    local_policy.jar
    ), available at: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

Transaction Security Keys

The first thing you must do is create your security key. The client uses the security key to add a digital signature to every request that you send. This signature helps ensure that no one else can use your
Cybersource
account to process orders. You specify the location of your key when you configure the client.
You must generate two transaction security keys—one for the
Cybersource
production environment and one for the test environment. For information about generating and using security keys, see ).
You must protect your security key to ensure that your
Cybersource
account is not compromised.

Installing the Client

The Java SDK is available to install from GitHub: https://github.com/CyberSource/cybersource-sdk-java

Using a Package Manager

We recommend using the Maven Package Manager to install the Java SDK.

Install the JAVA SDK (Maven Package Manager)

  1. Add the dependency to your application pom.xml.

    ADDITIONAL INFORMATION

    <dependency> <groupId>com.cybersource</groupId> <artifactId>cybersource-sdk-java</artifactId> <version>6.0.1</version> </dependency>
  2. Run mvn install.

Install the JAVA SDK (Gradle)

  1. Add the dependency to your build.gradle.

    ADDITIONAL INFORMATION

    dependencies { compile 'com.cybersource:cybersource-sdk-java:6.0.1' }

Install the Files Individually

  1. Download the latest jar file. The current version is
    cybersource-sdk-java-6.0.1.jar
    .
  2. Save the jar file to an appropriate location.
  3. Import the com.cybersource.ws.client package.

Configuring Client Properties

The client requires certain properties to run transactions. The samples provided in the <main directory>
/samples/nvp
and <main directory>
/samples/xml
folders read a file called
cybs.properties
into a Properties object which is passed to the runTransaction() method. Configuration Properties describes the properties that you can set. Note that the default
cybs.properties
file that comes with the client package does not include all of the properties listed in the table. It includes only the ones required to run the sample.
The client also includes additional property configuration capabilities. For example, you can configure for multiple merchants or configure using system properties. For more information, see Advanced Configuration Information.
For Java SDK 1.4.x, the client sets the system properties
https.proxyHost
and
https.proxyPort
to the values of the client properties
proxyHost
and
proxyPort
. If these system properties are defined beforehand, possibly by using the
-D
option in the command line, the system properties will take precedence.
Configuration Properties
Property
Description
merchantID
This client uses this value if you do not specify a merchant ID in the request itself. This value is case sensitive.
keysDirectory
Location of the merchant’s security keys. Although UNC paths are allowed, for faster request processing, we recommend that you store your key locally. You must use forward slashes even in a Windows environment (for example:
c:/keys)
. The client includes a
keys
directory that you can use.
sendToProduction
Flag that indicates whether the transactions for this merchant should be sent to the production server. Use one of these values:
  • false
    : Send to the test server. (default setting)
  • true
    : Send to the production server
targetAPIVersion
Version of the Simple Order API to use, such as
1.18
. For the list of available versions, go to https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor. For transactions in India, go to https://ics2ws.in.ic3.com/commerce/1.x/transactionProcessor. Do not set this property to the current version of the client. See Client Versions, for more information.
keyFilename
Name of the security key file name in the format
<
security_key_name
>
.
p12
.
serverURL
Alternative server URL to use. For more information, see Using Alternate Server Properties. Give the complete URL because it will be used exactly as specified here.
namespaceURI
Alternative namespace URI to use. Give the complete namespace URI because it will be used exactly as specified here. For more information, see Using Alternate Server Properties.
enableLog
Flag directing the client to log transactions and errors. Use one of these values:
  • false
    : Do not enable logging (default setting)
  • true
    : Enable logging
    Logging can cause very large log files to accumulate. Therefore, we recommend that you use logging only when troubleshooting problems. To comply with all Payment Card Industry (PCI) and Payment Application (PA) Data Security Standards regarding the storage of credit card and card verification number data, the logs that are generated contain only masked credit card and card verification number data (CVV, CVC2, CVV2, CID, CVN).
    Follow these guidelines:
  • Use debugging temporarily for diagnostic purposes only.
  • If possible, use debugging only with test credit card numbers.
  • Never store clear text card verification numbers.
  • Delete the log files as soon as you no longer need them.
  • Never send email to
    Cybersource
    containing personal and account information, such as customers' names, addresses, card or check account numbers, and card verification numbers.
    For more information about PCI and PABP requirements, see www.visa.com/cisp.
logDirectory
Directory to which to write the log file. UNC paths are allowed. You must use forward slashes even in a Windows environment, for example:
c:/logs
. The client does not create this directory; instead you must specify an existing directory. The client includes a
logs
directory that you can use.
logFilename
Log file name. The client uses
cybs.log
by default.
logMaximumSize
Maximum size in megabytes for the log file. The default value is
"10"
. When the log file reaches the specified size, it is archived into
cybs.log
.<yyyymmdd
T
hhmmssxxx> and a new log file is started. The xxx indicates milliseconds.
timeout
Ignore this property. Instead set a specific amount of time that is acceptable to your business.
Number of seconds to wait for reply before timing out. Default value is 130. This property does not have an effect if useHttpClient is
false
and you are using
cybsclients14.jar
.
useHttpClient
Flag directing the client to use Apache HttpClient for the HTTPS communication. Use one of these values:
  • false
    : (default setting) Do not use Apache HttpClient. Use built-in HttpURLConnection. The timeout property does not have an effect if useHttpClient is
    false
    and you are using
    cybsclients14.jar
    .
  • true
    : Use Apache HttpClient.
    When useHttpClient is
    true
    , your CLASSPATH must include the three
    commons-*.jar
    files shipped with the package.
proxyHost
Optional host name or IP address of the HTTP proxy server.
proxyPort
Port number of the proxy server. The default is 8080. This property is ignored if you do not specify
proxyHost
.
proxyUser
User name used to authenticate against the proxy server if required.
proxyPassword
Password used to authenticate against the proxy server if required.

Testing the Client

The client tests and samples are configured to run with Maven. Before you test the client, update the client properties with your test merchant credentials (see Configuring Client Properties).

Run the SDK Integration Tests

  1. Configure your merchant credentials in test_cybs.properties (<main directory>/src/test/resources).
  2. Run
    mvn failsafe:integration-test
    from the main directory.

Run the Samples (Java)

  1. Configure your merchant credentials in cybs.properties (<main directory>/samples/nvp or xml).
  2. Run
    mvn exec:java
    from samples directory (<main directory>/samples/nvp or xml).

Going Live

When you finish configuring and testing the client, your deployment is ready to go live.
Make sure that your client is set to send transactions to the production server, not the test server. See the description of
sendToProduction
.

Cybersource
Essentials Merchants

If you use
Cybersource
Essentials services, you can use the
Business Center
site to go live.
You must also configure your client so that it sends transactions to the production server and not the test server. See the description of the
sendToProduction
property in Configuration Properties.
After your deployment goes live, use real card numbers and other data to test every card type you support. Because these are real transactions in which you are buying from yourself, use small monetary amounts to do the tests. Process an authorization, then capture the authorization, and later refund the money. Use your bank statements to verify that money is deposited into and withdrawn from your merchant bank account as expected. If you have more than one merchant ID, test each one separately.

Cybersource
Advanced Merchants

If you use
Cybersource
Advanced services, see Getting Started with Cybersource Advanced for information about going live.
When your deployment goes live, your
Cybersource
account is updated so that you can send transactions to the
Cybersource
production server. If you have not already done so, you must provide your banking information to
Cybersource
so that your processor can deposit funds to your merchant bank account.
After
Cybersource
confirms that your account is live, make sure that you update your system so that it can send requests to the production server (
ics2wsa.ic3.com
or
ics2ws.in.ic3.com
in India) using your security keys for the production environment. The test server (
ics2wstesta.ic3.com
) cannot be used for real transactions. For more information about sending transactions to the production server. see the description of the configuration property
sendToProduction
.
After your deployment goes live, use real card numbers and other data to test every card type, currency, and
Cybersource
application that your integration supports. Because these are real transactions in which you are buying from yourself, use small monetary amounts to do the tests. Use your bank statements to verify that money is deposited into and withdrawn from your merchant bank account as expected. If you have more than one merchant ID, test each one separately.

Using Name-Value Pairs

This section explains how to write Java programs that request
Cybersource
services by using name-value pairs.

Requesting
Cybersource
Services

To request
Cybersource
services, write code that can perform these actions:
  • Collect information for the
    Cybersource
    services that you will use
  • Assemble the order information into requests
  • Send the requests to the
    Cybersource
    server
    The
    Cybersource
    servers do not support persistent HTTP connections.
  • Process the reply information
For the list of API fields that you must add to your requests and will see in the replies, use the guide that describes the service. See Related Documents.
The code in this section’s example is incomplete. For a complete sample program, see the
AuthCaptureSample.java
file in <main directory>
/samples/nvp/src/com/cybersource/sample
directory.
If you make any changes to the
AuthCaptureSample.java
sample, you must rebuild the sample before using it. Use the
compileSample
batch file or shell script provided in the
sample
directory.
If you use Java SDK 1.5 or later, replace
cybsclients14.jar
with
cybsclients15.jar
in the
compileSample
script.

Creating and Sending Requests

To use any
Cybersource
service, you must create and send a request that includes the required information for that service. The example that is developed in the following sections shows basic code for requesting a credit card authorization. In this example, Jane Smith is buying an item for 29.95.

Importing the Client Classes

Add the following import statements:
import java.util.*; import com.cybersource.ws.client.*;
Depending on your application, you might need to add more import statements.

Loading the Configuration File

Load the configuration file:
Properties props = Utility.readProperties( args );
The sample reads the configuration settings from the properties file specified in the command line. If you do not specify a file, the sample looks for the file
cybs.properties
in the current directory.

Creating an Empty Request

Create a hashtable that holds the request fields:
HashMap request = new HashMap();

Adding Services to the Request

Indicate the service that you want to use by adding a field to the request, such as a credit card authorization:
request.put( "ccAuthService_run", "true" );
You can request multiple services by adding additional fields to the request. When you request multiple services in one request,
Cybersource
processes the services in a specific order. If a service fails,
Cybersource
does not process the subsequent services in the request. You are charged only for the services that
Cybersource
performs.
Example: For All Merchants: Requesting Multiple Services
For example, if you fulfill the order immediately, you can request a credit card authorization and capture together, called a
sale.
If the authorization service fails,
Cybersource
does not process the capture service. The reply you receive includes reply fields only for the authorization:
request.put( "ccAuthService_run", "true" ); request.put( "ccCaptureService_run", "true" );
Example: For Merchants Using
Cybersource
Advanced Services:
Requesting Multiple Services
Many
Cybersource
services include fields that tell
Cybersource
to ignore the result from the first service when deciding whether to run the subsequent services. In the case of the sale, even though the issuing bank gives you an authorization code,
Cybersource
may decline the authorization based on the AVS or card verification results. Depending on your business needs, you might choose to capture these declined authorizations. To do so, in your combined authorization and capture request, set the
businessRules_ignoreAVSResult
field to true:
request.put( "businessRules_ignoreAVSResult", "true" );
This line tells
Cybersource
to process the capture even if the AVS result causes
Cybersource
to decline the authorization. In this case, the reply would contain fields for the authorization and the capture.

Adding Service-Specific Fields to the Request

Add the fields that are used by the services you are requesting. If you request multiple services that share fields, add the field only once.
request.put( "billTo_firstName", "Jane" ); request.put( "billTo_lastName", "Smith" ); request.put( "card_accountNumber", "4111111111111111" ); request.put( "item_0_unitPrice", "29.95" );
The example above shows only a partial list of the fields you must send. The developer guides for the service you are using contains a complete list of API request and reply fields available for that service.

Sending the Request

Send the request to
Cybersource
, store the reply in a new hashtable, and interpret the exceptions that you might receive:
try {   HashMap reply = Client.runTransaction( request, props );   //Using the Decision and Reason Code Fields illustrates how you   //might design a ProcessReply() method to handle the reply.   processReply( reply ); } catch (FaultException e) {   System.out.println( e.getLogString() ); } catch (ClientException e) {   System.out.println( e.getLogString() ); }
In the example above, when an exception occurs, the exception is printed to the console. Your web store should also display to the customer a message indicating that you were unable to process the order. Using the Decision and Reason Code Fields shows how to provide feedback to the customer.

Interpreting Replies

After your request is processed by the
Cybersource
server, it sends a reply message that contains information about the services you requested. You receive fields relevant to the services that you requested and to the outcome of each service.
To use the reply information, you must integrate it into your system and any other system that uses that data. For example, you can store the reply information in a database and send it to other back office applications.
You must write an error handler to process the reply information that you receive from
Cybersource
. Do not show the reply information directly to customers. Instead, present an appropriate response that tells customers the result.
Cybersource
may add reply fields and reason codes at any time. If your error handler receives a reason code that it does not recognize, it should use the
decision
to interpret the reply. Parse the reply data according to the names of the fields instead of their order in the reply.
These are the most important reply fields:
  • decision
    : A one-word description of the results of your request. The possible values are as follows:
  • reasonCode
    : A numeric code that provides more specific information about the results of your request.
You also receive a reason code for each service in your request. You can use these reason codes to determine whether a specific service succeeded or failed. If a service fails, other services in your request may not run. For example, if you request a credit card authorization and capture, and the authorization fails, the capture does not run. The reason codes for each service are described in the .

Using the Decision and Reason Code Fields

This example shows how you can use the decision and the reason code to display an appropriate message to the customer.
The processReply() method described below is not included in the sample code in the client package.
private static boolean processReply( HashMap reply )   throws ClientException {     MessageFormat template = new MessageFormat(     getTemplate( (String) reply.get( "decision" ) ) );     Object[] content = { getContent( reply ) };     /*      * This example writes the message to the console. Choose an appropriate display      * method for your own application.      */     System.out.println( template.format( content ) ); } private static String getTemplate( String decision ) {   // Retrieves the text that corresponds to the decision.   if ("ACCEPT".equalsIgnoreCase( decision )) {     return( "Your order was approved.{0}" );   }   if ("REJECT".equalsIgnoreCase( decision )) {     return( "Your order was not approved.{0}" );   }   // ERROR   return( "Your order cannot be completed at this time.{0}" +           "\nPlease try again later." ); } private static String getContent( HashMap reply )   throws ClientException {   /*    * Uses the reason code to retrieve more details to add to the template.    * The strings returned in this sample are meant to demonstrate how to retrieve    * the reply fields. Your application should display user-friendly messages.    */   int reasonCode =     Integer.parseInt( (String) reply.get( "reasonCode" ) );   switch (reasonCode) {     // Success     case 100:       return( "\nRequest ID: " + (String) reply.get( "requestID" );     // Missing field or fields     case 101:       return( "\nThe following required field(s) are missing:\n" +               enumerateValues( reply, "missingField" ) );     // Invalid field or fields     case 102:       return( "\nThe following field(s) are invalid:\n" +                enumerateValues( reply, "invalidField" ) );     // Insufficient funds     case 204:       return( "\nInsufficient funds in the account. Please use a different " +               "card or select another form of payment." );     // Add additional reason codes here that you must handle specifically.     default:       // For all other reason codes (for example, unrecognized reason codes, or       // codes that do not require special handling), return an empty string.       return( "" );   } } private static String enumerateValues( Map reply, String fieldName ) {   StringBuffer sb = new StringBuffer();   String key, val = "";   for (int i = 0; ; ++i) {     key = fieldName + "_" + i;     if (!reply.containsKey( key )) {       break;     }     val = (String) reply.get( key );     if (val != null) {       sb.append( val + "\n" );     }   }   return( sb.toString() ); }

Handling
Decision Manager
Reviews (
Cybersource
Advanced Services Only)

  If you use
Decision Manager
, you may also receive the
REVIEW
value in the
decision
field.
REVIEW
means that
Decision Manager
has marked the order for review based on how you configured the
Decision Manager
rules.
If you will be using
Decision Manager
, you have to determine how to handle the new
REVIEW
value. Ideally, you will update your order management system to recognize the
REVIEW
response and handle it according to your business rules. If you cannot update your system to handle the
REVIEW
response, we recommend that you choose one of these options:
  • If you authorize and capture the credit card payment at the same time, treat the
    REVIEW
    response like a
    REJECT
    response. Rejecting any orders that are marked for review may be appropriate if your product is a software download or access to a Web site. If supported by your processor, you may also want to reverse the authorization.
  • If you approve the order after reviewing it, convert the order status to
    ACCEPT
    in your order management system. You can request the credit card capture without requesting a new authorization.
  • If you approve the order after reviewing it but cannot convert the order status to
    ACCEPT
    in your system, request a new authorization for the order. When processing this new authorization, you must disable
    Decision Manager
    . Otherwise the order will be marked for review again. For details about the API field that disables
    Decision Manager
    , see the .
Alternately, you can specify a custom business rule in
Decision Manager
so that authorizations originating from a particular internal IP address at your company are automatically accepted.
If supported by your processor, you may want to reverse the original authorization.

Handling System Errors

You must design your transaction management system to correctly handle system errors, which occur when you successfully receive a reply, but the
decision
field is ERROR. For more information about the
decision
, see Interpreting Replies. The error may indicate a valid system error or a payment processor rejection because of invalid data.

Offline Transactions

We recommend that you resend the request two or three times only, waiting a longer period of time between each attempt. Determine what is most appropriate for your business situation.
Example Handling System Errors for Offline Transactions
After the first system error response, wait a short period of time, perhaps 30 seconds, before resending the request. If you receive the same error a second time, wait a longer period of time, perhaps 1 minute, before resending the request. If you receive the same error a third time, you may decide to try again after a longer period of time, perhaps 2 minutes.
If you are still receiving a system error after several attempts, the error may be caused by a processor rejection instead of a system error. In this case, we recommend one of these options:
  • Find the transaction in the
    Business Center
    . After looking at the description of the error on the transaction details page, call your processor to determine if and why the transaction was rejected. If your processor is
    TSYS Acquiring Solutions
    , you may want to follow this option because this processor can return several system errors that only it can address.
  • Contact
    Cybersource
    Customer Support to determine whether the error is caused by a
    Cybersource
    system issue.

Online Transactions

For online transactions, inform the customer that an error occurred and request that the customer attempts to resubmit the order.

Using XML

This section explains how to write Java programs that request
Cybersource
services by using XML.

Requesting
Cybersource
Services

To request
Cybersource
services, write code that can perform these actions:
  • Collect information for the
    Cybersource
    services that you will use
  • Assemble the order information into requests
  • Send the requests to the
    Cybersource
    server
    The
    Cybersource
    servers do not support persistent HTTP connections.
  • Process the reply information
For the list of API fields that you must add to your requests and will see in the replies, use the guide that describes the service. See Related Documents.
To understand how to request
Cybersource
services, we recommend that you examine the name-value pair sample code provided in
AuthCaptureSample.java
before implementing your code to process XML requests. The sample code file is located in the <main directory>
/samples/nvp/src/com/cybersource/sample
directory.
The code in this section’s example is incomplete. For a complete sample program, see the
AuthSample.java
file in the <main directory>
/samples/xml/src/com/cybersource/sample
directory.
If you make changes to the
AuthSample.java
sample, you must rebuild the sample before using it by using the
compileSample
batch file or shell script provided in the
xmlsample
directory.
If you use Java SDK 1.5 or later, replace
cybsclients14.jar
with
cybsclients15.jar
in the
compileSample
script.

Creating Requests

The client enables you to create an XML request document by using any application and sending the request to
Cybersource
. For example, if you have a customer relationship management (CRM) application that uses XML to communicate with other applications, you can use your CRM to generate request documents.
You must validate the request document against the XML schema for
Cybersource
transactions. To view the schema, look at the
xsd
file for your version of the Simple Order API.
If the elements in your document do not appear in the correct order, your document will not be validated, and your request will fail.
The example that is developed in the following sections shows a basic XML document for requesting a credit card authorization. In this example, Jane Smith is buying an item for 29.95. The XML document in this example is incomplete. For a complete example, see the
auth.xml
file in the
samples/xml
directory.

Creating an Empty Request

Start with the XML declaration and the root element:
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18"> </requestMessage>
When you construct a request, indicate the namespace for the elements. The namespace must use the same API version that you specify in the configuration settings.
Example: API version:
targetAPIVersion
=
1.18
Namespace: urn:schemas-cybersource-com:transaction-data-
1.18

Adding Services to the Request

Add the services that you want to use by creating an element for that service and setting the element’s
run
attribute to
true
. This example shows a credit card authorization:
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-
1.18">   <ccAuthService run="true"/> </requestMessage>
You can request multiple services by creating additional elements. When you request multiple services in one request,
Cybersource
processes the services in a specific order. If a service fails,
Cybersource
does not process the subsequent services in the request. You are charged only for the services that
Cybersource
performs.
Example For All Merchants: Requesting Multiple Services in a Request
If you fulfill orders immediately, you can request a credit card authorization and capture together, called a sale
.
If the authorization service fails,
Cybersource
does not process the capture service. The reply that you receive contains only authorization reply fields:
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18">   <ccAuthService run="true"/>   <ccCaptureService run="true"/> </requestMessage>
Example for Merchants Using
Cybersource
Advanced Services: Requesting Multiple Services in a Request
Many
Cybersource
services use fields that tell
Cybersource
to ignore the result from the first service when deciding whether to run the subsequent services. In the case of the sale, even though the issuing bank gives you an authorization code,
Cybersource
may decline the authorization based on the address or card verification results. Depending on your business needs, you might choose to capture these declined authorizations. To do so, in your combined authorization and capture request, you must set the
businessRules_ignoreAVSResult
field to true:
<businessRules>     <ignoreAVSResult>true</ignoreAVSResult> </businessRules>
These lines tell
Cybersource
to process the capture even if the address verification result causes
Cybersource
to decline the authorization. In this case, the reply would contain fields for the authorization and the capture.

Adding Service-Specific Fields to the Request

Add the fields that are used by the services you are requesting. Most fields are child elements of container elements. For example, a
<card>
element contains the customer’s credit card information. This example shows a partial list of possible fields. The developer guides for the service you are using contains a complete list of API request and reply fields for that service.
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-
1.18">   <billTo>     <firstName>Jane</firstName>     <lastName>Smith</lastName>   </billTo>   <item id="0">     <unitPrice>29.95</unitPrice>   </item>   <card>     <accountNumber>4111111111111111</accountNumber>   </card>   <ccAuthService run="true"/> </requestMessage>

Sending Requests

Once you have created an XML request document, you can use Java to send the request to
Cybersource
.

Importing the Client Classes

Add the following import statements:
import java.io.*; import java.util.*; import javax.xml.parsers.*; import org.w3c.dom.*; import org.xml.sax.*; import com.cybersource.ws.client.*;
Depending on your application, you might need to add more import statements.

Loading the Configuration File

Load the configuration file:
Properties props = Utility.readProperties( args );
The sample reads the configuration settings from the properties file specified in the command line. If you do not specify a file, the sample looks for the file
cybs.properties
in the current directory.

Sending the Request

Send the request to
Cybersource
, store the reply in a new
Document
object, and interpret the exceptions that you might receive:
try {   Document request = readRequest( props, args );   // The sample reads the files specified in the command line, or if no files are   // specified, the sample looks for cybs.properties and auth.xml in the current   // directory.   Document reply = XMLClient.runTransaction( request, props );   // Using the Decision and Reason Code Fields illustrates how you might   // design a ProcessReply() method to handle the reply.   processReply( reply ); } catch (FaultException e) {   e.printStackTrace();   System.out.println( e.getLogString() ); } catch (ClientException e) {   e.getInnerException().printStackTrace();   System.out.println( e.getLogString() ); }
In the preceding example, when an exception occurs, the exception is printed to the console. Your web store should also display a message to the customer indicating that you were unable to process the order. Using the Decision and Reason Code Fields shows how to provide feedback to the customer.

Interpreting Replies

The XML document that you receive in the reply always uses a prefix of
c:
, for example:
xmlns:c="urn:schemas-cybersource-com:transaction-data-1.18"
. Make sure you use an XML parser that supports namespaces.
After your request is processed by the
Cybersource
server, it sends a reply message that contains information about the services you requested. You receive fields relevant to the services that you requested and to the outcome of each service.
To use the reply information, you must integrate it into your system and any other system that uses that data. For example, you can store the reply information in a database and send it to other back office applications.
You must write an error handler to process the reply information that you receive from
Cybersource
. Do not show the reply information directly to customers. Instead, present an appropriate response that tells customers the result.
We may add reply fields and reason codes at any time. If your error handler receives a reason code that it does not recognize, it should use the
decision
to interpret the reply. Parse the reply data according to the names of the fields instead of their order in the reply.
These are the most important reply fields:
  • decision
    : A one-word description of the results of your request:
  • reasonCode
    : A numeric code that provides more specific information about the results of your request.
You also receive a reason code for each service in your request. You can use these reason codes to determine whether a specific service succeeded or failed. If a service fails, other services in your request may not run. For example, if you request a credit card authorization and capture, and the authorization fails, the capture does not run. The reason codes for each service are described in .

Using the Decision and Reason Code

This example shows how you can use the decision and the reason code to display an appropriate message to the customer.
The processReply() method described below is not included in the sample code in the client package.
private static boolean processReply( Document reply )   throws ClientException {   // The following code allows you to use XPath with the Cybersource schema, which   // uses a non-empty default namespace.   XPathAPI xp = new XPathAPI();   Element nsNode = reply.createElement( "nsNode" );   // The version number (1.20) at the end of the namespaceURI below is an example.   // Change it to the version of the API that you are using.   nsNode.setAttribute("xmlns:cybs", "urn:schemas-cybersource-com:transaction-data 
    -1.20" );   Node replyMessage =     getNode( xp, reply, "cybs:replyMessage", nsNode );   String decision =     getText( xp, replyMessage, "cybs:decision", nsNode );   MessageFormat template =     new MessageFormat( getTemplate( decision ) );   Object[] content = { getContent( xp, replyMessage, nsNode ) };   /*    * This example writes the message to the console. Choose an appropriate display    * method for your own application.    */   System.out.println( template.format( content ) ); }   private static String getTemplate( String decision ){     // Retrieves the text that corresponds to the decision.     if ("ACCEPT".equalsIgnoreCase( decision )) {       return( "Your order was approved.{0}" );     }     if ("REJECT".equalsIgnoreCase( decision )) {       return( "Your order was not approved.{0}" );     }     // ERROR, or unknown decision     return( "Your order cannot be completed at this time.{0}" +             "\nPlease try again later." ); } private static String getContent(   XPathAPI xp, Node ctxNode, Node nsNode )   throws XMLClientException {   /*    * Uses the reason code to retrieve more details to add to the template.    * The strings returned in this sample are meant to demonstrate how to retrieve    * the reply fields. Your application should display user-friendly messages.    */   int reasonCode = Integer.parseInt(     getText( xp, ctxNode, "cybs:reasonCode", nsNode ) );   switch (reasonCode) {     // Success     case 100:       return ( "\nRequest ID: " +         getText( xp, ctxNode, "cybs:requestID", nsNode ) );     // Missing field or fields     case 101:       return( "\nThe following required field(s) are missing:\n" +       enumerateValues( xp, ctxNode, "cybs:missingField", nsNode ) );     // Invalid field or fields     case 102:       return( "\nThe following field(s) are invalid:\n" +       enumerateValues( xp, ctxNode, "cybs:invalidField", nsNode ) );     // Insufficient funds     case 204:       return( "\nInsufficient funds in the account. Please use a " +               "different card or select another form of payment." );     // Add additional reason codes here that you must handle specifically.     default:       // For all other reason codes (for example, unrecognized reason codes, or       // codes that do not require special handling), return an empty string.       return( "" );   } } private static String enumerateValues(   XPathAPI xp, Node ctxNode, String xpath, Node nsNode )   throws TransformerException {   try {     StringBuffer sb = new StringBuffer();     NodeList list =       xp.selectNodeList( ctxNode, xpath + "/text()", nsNode );     if (list != null) {       for (int i = 0, len = list.getLength(); i < len; ++i) {         sb.append( list.item( i ).getNodeValue() + "\n" );       }     }     return( sb.toString() );   } }

Handling
Decision Manager
Reviews (
Cybersource
Advanced Merchants)

If you use
Decision Manager
, you may also receive the
REVIEW
value in the
decision
field.
REVIEW
means that
Decision Manager
has marked the order for review based on how you configured the
Decision Manager
rules.
If you will be using
Decision Manager
, you have to determine how to handle the new
REVIEW
value. Ideally, you will update your order management system to recognize the
REVIEW
response and handle it according to your business rules. If you cannot update your system to handle the
REVIEW
response, we recommend that you choose one of these options:
  • If you authorize and capture the credit card payment at the same time, treat the
    REVIEW
    response like a
    REJECT
    response. Rejecting any orders that are marked for review may be appropriate if your product is a software download or access to a Web site. If supported by your processor, you may also want to reverse the authorization.
  • If you approve the order after reviewing it, convert the order status to
    ACCEPT
    in your order management system. You can request the credit card capture without requesting a new authorization.
  • If you approve the order after reviewing it but cannot convert the order status to
    ACCEPT
    in your system, request a new authorization for the order. When processing this new authorization, you must disable
    Decision Manager
    . Otherwise the order will be marked for review again. For details about the API field that disables
    Decision Manager
    , see the .
Alternately, you can specify a custom business rule in
Decision Manager
so that authorizations originating from a particular internal IP address at your company are automatically accepted.
If supported by your processor, you may want to reverse the original authorization.

Handling System Errors

You must design your transaction management system to correctly handle system errors, which occur when you successfully receive a reply, but the
decision
field is ERROR. For more information about the decision, see Interpreting Replies. The error may indicate a valid system error or a payment processor rejection because of invalid data.

Offline Transactions

We recommend that you resend the request two or three times only, waiting a longer period of time between each attempt. You should determine what is most appropriate for your business situation.
Example:
After the first system error response, wait a short period of time, perhaps 30 seconds, before resending the request. If you receive the same error a second time, wait a longer period of time, perhaps 1 minute, before resending the request. If you receive the same error a third time, you may decide to try again after a longer period of time, perhaps 2 minutes.
If you are still receiving a system error after several attempts, the error may be caused by a processor rejection instead of a
Cybersource
system error. In this case, we recommend one of these options:
  • Find the transaction in the
    Business Center
    . After looking at the description of the error on the transaction details page, call your processor to determine if and why the transaction was rejected. If your processor is
    TSYS Acquiring Solutions
    , you may want to follow this option because this processor can return several system errors that only it can address.
  • Contact
    Cybersource
    Customer Support to determine whether the error is caused by a
    Cybersource
    system issue.

Online Transactions

For online transactions, inform the customer that an error occurred and request that the customer attempts to resubmit the order.

Advanced Configuration Information

Using Alternate Server Properties

Use the serverURL and namespaceURI properties if
Cybersource
changes the convention used to specify the server URL and namespace URI, but has not updated the client yet. With these properties, you will be able to configure your existing client to use the new server and namespace conventions required by the
Cybersource
server.
For example, these are the server URLs and namespace URI for accessing the
Cybersource
services with the Simple Order API 1.18:
  • Test server URLs:
    Internet endpoint:
    https://ics2wstest.ic3.com/commerce/1.x/transactionProcessor
    Akamai endpoint:
    https://ics2wstesta.ic3.com/commerce/1.x/transactionProcessor
  • Production server URLs:
    Internet endpoint:
    https://ics2ws.ic3.com/commerce/1.x/transactionProcessor
    Akamai endpoint:
    https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor
    India endpoint:
    https://ics2ws.in.ic3.com/commerce/1.x/transactionProcessor
  • Namespace URI:
    urn:schemas-cybersource-com:transaction-data-1.18
    .
If you view the above URLs in a web browser, a list of the supported API versions and the associated schema files are displayed.

Configuring for Multiple Merchant IDs

If you have multiple merchant IDs, or if you are a reseller handling multiple merchants, you can set different properties settings for different merchant IDs in the Properties object that you pass to runTransaction(). When using the samples provided in the client package, set the properties in
cybs.properties
file.
To specify the settings for a specific merchant, all the properties except merchantID can be prefixed with "
<merchantID>.
". The merchant ID is case sensitive. To enable logging only for
merchant123
, set the enableLog property to
true
for all requests that have
merchant123
as the merchant ID:
merchant123.enableLog=true enableLog=false
The client disables logging for all other merchants.

Using System Properties

Although the properties in the Properties object passed to runTransaction() normally take precedence over the System properties, you can specify the settings that the client uses with the System properties. A system property will be used only if the Properties object passed to runTransaction() does not already include that property.
To use System properties for
merchant123
, prefix each system property with
cybs.
, for example:
java -Dcybs.enableLog=false -Dcybs.merchant123.enableLog=true myApplication

Resolving Connection Issues

If you are using a Oracle Java SDK version earlier than 1.4.0 or an IBM Java SDK, you may exceptions when attempting to connect to external sites with HTTPS.
If you encounter the following exception message when testing the client, follow the procedure for your SDK:
java.net.MalformedURLException: unknown protocol: https

Oracle Java SDK Version Earlier than 1.4.0

This procedure is only a guideline. For the latest information, consult the Oracle JSSE documentation.
  1. Download the Oracle JSSE from http://java.sun.com/products/jsse/.
  2. Extract the following files from the Oracle JSSE package:

    ADDITIONAL INFORMATION

    jcert.jar
    jnet.jar
    jsse.jar
  3. Copy the
    jar
    files into your Java installation's
    jre/lib/ext
    directory.
  4. Open
    jre/lib/security/java.security
    and locate the following line with the highest value for
    N
    :
    security.provider.N=<some provider class name>
  5. Add the following line where
    NN
    is equal to
    N
    + 1:
    security.provider.NN=com.sun.net.ssl.internal.ssl.Provider
  6. Save and close the file.

IBM Java SDK

This procedure is only a guideline. For the latest information, consult the IBMJSSE documentation.
  1. Download the IBMJSSE from IBM’s web site or obtain it from your IBM development kit CDs.
  2. Extract the
    ibmjsse.jar
    file.
  3. Obtain the
    ibmpkcs.jar
    file. The file should be included in the IBM development kit.
  4. Copy both
    jar
    files into your Java installation's
    jre/lib/ext
    directory.
  5. Open
    jre/lib/security/java.security
    and locate the following line with the highest value for
    N
    :
    security.provider.N=<some provider class name>
  6. Add the following line where
    NN
    is equal to
    N
    + 1:
    security.provider.NN=com.ibm.jsse.JSSEProvider
  7. Save and close the file.

Importing the Root CA Certificate

If you encounter this exception message when testing the client, you must perform the following steps to import the root CA certificate into
cacerts
:
javax.net.ssl.SSLException untrusted server cert chain
  1. At a command prompt, go to the main client directory where the
    entrust_ssl_ca.cer
    file is located.
  2. Type the following text without line breaks:

    ADDITIONAL INFORMATION

    keytool -import -alias entrust_ssl_ca                 -keystore <JAVA_HOME>/jre/lib/security/cacerts                 -file entrust_ssl_ca.cer
    where <JAVA_HOME> is the path to your Java installation.
    Note that keytool is a utility included in the Java SDK.
  3. When prompted, enter the keystore password. The default password is usually
    changeit
    . You have successfully imported the certificate.

PHP Client

  • This section covers the Linux and Windows platforms and uses the Linux convention of forward slashes when path names are listed.
  • The PHP client for the Simple Order API is supported on 32-bit operating systems only.
  • If you are building an application to sell to others, see Using the Client Application Fields. This section includes a list of API fields you can use in your request that describe the application, its version, and its user. If you use these fields in your request, you can view their values in the Transaction Search Details page of the
    Business Center
    .

Using PHP in a Hosted Environment

If you are operating in a hosted environment (with an Internet Service Provider hosting your web store), read this section.
To use the Simple Order API client for PHP, you must register a PHP extension in
php.ini
and modify the LD_LIBRARY_PATH (for Linux) or the system PATH (for Windows) to include the
lib
directory of the
Cybersource
client. The
Cybersource
binaries ensure that your transactions are secure while being sent to
Cybersource
. If you use a hosted environment, you must check with your hosting provider (ISP) to make sure that they support the addition of a PHP extension and editing of the path environment variables.
If you cannot find any documentation related to your hosting provider's support of extensions and new library locations, contact your hosting provider with this statement:
Cybersource
requires modifying php.ini to add their extension and editing of LD_LIBRARY_PATH (for Linux) or the system PATH (for Windows) to add the directory containing the dynamic libraries required by the extension for use by my e-commerce software.
Cybersource
ensures the safety and functionality of these libraries. Please let me know your policy for supporting this implementation.
Because other merchants who use your hosting provider may also use
Cybersource
, your hosting provider may have already installed the
Cybersource
PHP client. In that case, we suggest that you verify with your hosting provider the version of the client they have installed and registered. If the client you want to use is newer, ask them to replace the libraries with the new ones.
If you have any questions regarding the above information or installation of the client, please contact
Cybersource
Customer Support. If you are a
Business Center
user, and you cannot obtain the appropriate access from your ISP to install the client, consider using Secure Acceptance instead of the PHP client. Secure Acceptance is available in two integration types, both of which are available in the
Business Center
.

Choosing Your API and Client

API Variation

With this client package, you can use either of these variations of the Simple Order API:
  • Name-value pairs, which are simpler to use than XML
  • XML, which requires you to create and parse XML documents
The test that you run immediately after installing the client uses name-value pairs.

Client Versions

Cybersource
regularly updates the Simple Order API to introduce new API fields and functionality. To identify the latest version of the server-side API for the
Cybersource
services, go to: https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor.
The Simple Order API Client for PHP also has a version, but it is not the same as the API version. The client version represents the version of the client-side code that you use to access the
Cybersource
services.
When configuring the client, you indicate the version of the API that you want to use. When setting this parameter, do not use the current version of the client; use the current version of the API.

Sample Code

The client contains sample scripts and sample PHP pages that you can use to test the client.

Basic PHP Page Example

The example below shows the primary code required to send a Simple Order API request for credit card authorization. The example uses name-value pairs. For a more complete example, see the sample program and sample PHP pages included in the package (see Sample Code). Using Name-Value Pairs shows you how to create the code.
// Load the configuration settings $config = cybs_load_config( 'cybs.ini' ); // set up the request by creating an array and adding fields to it $request = array(); // We want to do credit card authorization in this example $request['ccAuthService_run'] = "true"; // Add required fields $request['merchantID'] = 'infodev'; $request['merchantReferenceCode'] = 'MRC-14344'; $request['billTo_firstName'] = 'Jane'; $request['billTo_lastName'] = 'Smith'; $request['billTo_street1'] = '1295 Charleston Road'; $request['billTo_city'] = 'Mountain View'; $request['billTo_state'] = 'CA'; $request['billTo_postalCode'] = '94043'; $request['billTo_country'] = 'US'; $request['billTo_email'] = 'jsmith@example.com'; $request['card_accountNumber'] = '4111111111111111'; $request['card_expirationMonth'] = '12'; $request['card_expirationYear'] = '2010'; $request['purchaseTotals_currency'] = 'USD'; // This example has two items $request['item_0_unitPrice'] = '12.34'; $request['item_1_unitPrice'] = '56.78'; // Add optional fields here according to your business needs // Send request $reply = array(); $status = cybs_run_transaction( $config, $request, $reply ); // Handle the reply. See Handling the Return Status

Sample Scripts

The client contains two sample scripts, one for using name-value pairs and one for using XML. See Testing the Client, or see the README file for more information about using the
authCaptureSample.php
script to test the client.
  • Name-value pairs: See
    authCaptureSample.php
    in <installation directory>
    /samples/nvp
    .
  • XML: We suggest that you examine the name-value pair sample code listed above before implementing your code to process XML requests.
For the XML sample code, see
authSample.php
in <installation directory>
/samples/xml
. Also see the
auth.xml
XML document that the script uses.

Sample PHP Pages

The client download package also includes sample PHP pages in the
<installation directory>
/samples/store
directory.
Files in sampleStore Directory
File
Description
util.php
Used by the other PHP pages in the directory.
checkout.php
Displays the contents of the shopping basket and prompts for address and payment information.
checkout2.php
Authorizes the order and displays the result.
store_footer.php
Footer used in the checkout pages.
store_header.php
Header used in the checkout pages.

Use the Sample PHP Pages

If you have files in your web server’s root directory that have the same name as the files listed in Files in sampleStore Directory back up those files. You will be copying the sample store files into the root directory in the next step. For Apache, the root directory is the one specified by
DocumentRoot
in
httpd.conf
.
  1. Copy all of the files in the
    <installation directory>
    /samples/store
    directory into your web server’s root directory.
  2. Modify the
    cybs.ini
    file as appropriate. For more information, see Configuring Client Settings.

    ADDITIONAL INFORMATION

    Use absolute paths for the directories in the
    cybs.ini
    file that you use with the sample store, for example:
    keysDirectory
    =
    c:\keys
    .
    If you encounter problems getting the sample PHP pages to work, you might need to locate your
    cybs.ini
    file outside of the root directory.
  3. Open the
    checkout.php
    file in a text editor and locate the
    cybs_load_config()
    function.
  4. Make sure that the parameter for the
    cybs.ini
    file passed to the function includes the absolute path. For example, make sure the line reads:
    $config = cybs_load_config( 'c:\cybs.ini' );

    ADDITIONAL INFORMATION

    not this line:
    $config = cybs_load_config( 'cybs.ini' );
  5. Restart your web server.

    ADDITIONAL INFORMATION

    If you are using Microsoft Internet Information Services (IIS), you might need to restart your computer for IIS to pick up the new server path.
  6. Open a web browser and type the following URL: http://<your web server name or IP address>/<virtual directory if applicable>/checkout.php

Installing and Testing the Client

Minimum System Requirements For Linux

  • Linux kernel 2.2, LibC6 on an Intel processor (for RedHat users, this currently corresponds to versions 7.1 and 7.2)
  • PHP4 (minimum version 4.2.1) or PHP5 (5.0.0–5.0.3 and 5.1.0-5.1.2)
  • GNU GCC

Minimum System Requirements For Windows

  • Windows XP, 2000, or newer
  • Minimum PHP version 4.2.1
The SDK supports UTF-8 encoding.
Failure to configure your client API host to a unique, public IP address will cause inconsistent transaction results.
The client API request ID algorithm uses a combination of IP address and system time, along with other values. In some architectures this combination might not yield unique identifiers.

Transaction Security Keys

The first thing you must do is create your security key. The client uses the security key to add a digital signature to every request that you send. This signature helps ensure that no one else can use your
Cybersource
account to process orders. You specify the location of your key when you configure the client.
You must generate two transaction security keys—one for the
Cybersource
production environment and one for the test environment. For information about generating and using security keys, see
Creating and Using Security Keys
.
The Simple Order API client for PHP package includes the
ca-bundle.crt
, a bundle of certificate files. The client expects to find the
ca-bundle.crt
file in the same directory as your security keys. If you move it elsewhere, use the sslCertFile configuration parameter to specify the file location. For more information, see the description of the parameter sslCertFile.
You must protect your security key to ensure that your
Cybersource
account is not compromised.

Installing the Client

This section describes the installation steps for Linux and Windows environments.

Install the Client on Linux

  1. Go to the client downloads page on the Support Center.
  2. Download the latest client package. You can save the file in any directory.
  3. Unzip and untar the package. This creates a directory called
    simapi-php-n.n.n
    , where
    n.n.n
    is the client version.

    ADDITIONAL INFORMATION

    The
    simapi-php-n.n.n/lib
    directory contains symbolic links. If you install the client by copying the
    lib
    directory from some other location where you untarred the package, check to see if the symbolic links are still there. If they are not, you must recreate them.
  4. Copy the
    php
    N
    _cybersource.so
    file into the PHP extension directory, where the N is 4 if your PHP version is 4.x.x; 5 if your PHP version is 5.0.0-5.0.2; 503 if your PHP version is 5.0.3.; or 512 if your version is 5.1.0-5.1.2.
  5. The extension directory is the one
    "extension_dir"
    is set to in the
    php.ini
    file. If you do not already have
    "extension_dir"
    set to an explicit directory:
    Create an extension directory (outside of the client installation directory).
    Set
    "extension_dir"
    to that directory.
    Copy the
    php
    N
    _cybersource.so
    file to that directory location.
  6. If you are using an Oracle database, go to Special Installation Instructions for Oracle Users and follow the instructions.

    ADDITIONAL INFORMATION

    Otherwise, in the
    php.ini
    file, locate the “Dynamic Extensions” section and add one of the following lines anywhere before the next section in the file:
    extension=php4_cybersource.so
    (if using PHP 4.x.x) or
    extension=php5_cybersource.so
    (if using PHP 5.0.0-5.0.2)
    extension=php503_cybersource.so
    (if using PHP 5.0.3) or
    extension=php512_cybersource.so
    (if using PHP 5.1.0-5.1.2)
  7. Save the
    php.ini
    file.
  8. Modify the environment variable LD_LIBRARY_PATH to include the
    lib
    directory of the Cybersource client. For example:

    ADDITIONAL INFORMATION

    export LD_LIBRARY_PATH=/baseDir/simapi-php-n.n.n/lib:$LD_LIBRARY_PATH
    where
    /baseDir
    is the directory where you untarred the Cybersource client package.
    If the web server is running as the user "nobody", you must use
    ldconfig
    instead of setting the LD_LIBRARY_PATH. In this case, update the
    /etc/ld.so.conf
    file to include the library path (
    /baseDir/simapi-php-n.n.n/lib
    ), and run
    ldconfig
    to update the configuration.
  9. Configure the client. See Configuring Client Settings below.
  10. Test the client. See Testing the Client.

Install the Client on Windows

  1. Go to the client downloads page on the Support Center.
  2. Download the latest client package. You can save the file in any directory.
  3. Unzip the package. This creates a directory called
    simapi-php-n.n.n
    , where
    n.n.n
    is the client version.
  4. Copy the
    php
    N
    _cybersource.dll
    file into the PHP extension directory, where the N is 4 if your PHP version is 4.x.x, or 5 if your PHP version is 5.x.x.

    ADDITIONAL INFORMATION

    The extension directory is the one
    "extension_dir"
    is set to in the
    php.ini
    file. If you do not already have
    "extension_dir"
    set to an explicit directory:
    Create an extension directory (outside of the client installation directory).
    Set
    "extension_dir"
    to that directory.
    Copy the
    php
    N
    _cybersource.dll
    file to that directory location.
  5. In the
    php.ini
    file, locate the “Windows Extensions” section and add one of the following lines anywhere before the next section in the file:

    ADDITIONAL INFORMATION

    extension=php4_cybersource.dll
    (if using PHP 4.x.x) or
    extension=php5_cybersource.dll
    (if using PHP 5.0.0–5.0.2)
    extension=php503_cybersource.dll
    (if using PHP 5.0.3) or
    extension=php512_cybersource.dll
    (if using PHP 5.1.0-5.1.2)
  6. Save the
    php.ini
    file.
  7. Add the
    lib
    directory of the
    Cybersource
    client package to the system PATH. This makes the DLLs included in the client package available to the
    Cybersource
    PHP extension. The client is installed on your system.
  8. Configure the client. See Configuring Client Settings below.
  9. Test the client. See Testing the Client.

Configuring Client Settings

To run the sample scripts included in the client package, you must set the configuration parameters in the
cybs.ini
file, which is located in the <installation directory>
/samples
directory for Linux, and in the
nvp
,
xml
, and
store
subfolders inside the
samples
directory for Windows. You can also use this file when running transactions in a production environment (see the function descriptions in PHP API for the Client). The following table describes the parameters that you can set. The default
cybs.ini
file that comes with the client package does not include all of the parameters listed in the table. The file includes only the parameters required to run the sample scripts.
If you have multiple merchant IDs, or if you are a reseller handling multiple merchants, you can use different configuration settings depending on the merchant ID. See Configuring Your Settings for Multiple Merchant IDs for more information.
Configuration Settings
Setting
Description
merchantID
Merchant ID. The client uses this value if you do not specify a merchant ID in the request itself.
keysDirectory
Location of the merchant’s security key. The client includes a
keys
directory that you can use. Include the path, for example:
../keys
, or
c:\simapi-php-1.0.0\keys
.
We recommend that you store your key locally for faster request processing.
sendToProduction
Flag that indicates whether the transactions for this merchant should be sent to the production server. Use one of these values:
  • false
    : Do not send to the production server; send to the test server (default setting).
  • true
    : Send to the production server.
    Make sure that if your merchant ID is configured to use the test mode, you send requests to the test server.
targetAPIVersion
Version of the Simple Order API to use.
For a current list of the available versions, go to https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor. For transactions in India, go to https://ics2ws.in.ic3.com/commerce/1.x/transactionProcessor.
keyFilename
Name of the security key file name for the merchant in the format
<
security_key_filename
>
.
p12
.
serverURL
Alternate server URL to use. See Using Alternate Server Configuration Settings for more information. Give the complete URL because it will be used exactly as you specify here.
namespaceURI
Alternate namespace URI to use. See Using Alternate Server Configuration Settings for more information. Give the complete namespace URI because it will be used exactly as you specify here.
enableLog
Flag directing the client to log transactions and errors. Use one of these values:
  • false
    : Do not enable logging (default setting).
  • true
    : Enable logging.
    Logging can cause very large log files to accumulate. Therefore, we recommend that you use logging only when troubleshooting problems. To comply with all Payment Card Industry (PCI) and Payment Application (PA) Data Security Standards regarding the storage of credit card and card verification number data, the logs that are generated contain only masked credit card and card verification number data (CVV, CVC2, CVV2, CID, CVN).
    Follow these guidelines:
  • Use debugging temporarily for diagnostic purposes only.
  • If possible, use debugging only with test credit card numbers.
  • Never store clear text card verification numbers.
  • Delete the log files as soon as you no longer need them.
  • Never send email to
    Cybersource
    containing personal and account information, such as customers' names, addresses, card or check account numbers, and card verification numbers.
    For more information about PCI and PABP requirements, see www.visa.com/cisp.
logDirectory
Directory to which to write the log file. Note that the client will not create this directory for you; you must specify an existing directory. The client includes a
logs
directory that you can use. Include the path, for example:
../logs
, or
c:\simapi-php-1.0.0\logs
.
logFilename
Log file name. The client uses
cybs.log
by default.
logMaximumSize
Maximum size in megabytes for the log file. The default value is
10
. When the log file reaches the specified size, it is archived into
cybs.log
.<yyyymmdd
T
hhmmssxxx> and a new log file is started. The xxx indicates milliseconds.
sslCertFile
The location of the bundled file of CA Root Certificates (
ca-bundle.crt
) which is included in the client download package. The client automatically looks for the file in the directory where your security key is stored (specified by keysDirectory). If you move the file so it does not reside in keysDirectory, use this configuration setting to specify the full path to the file, including the file name.
timeout
Length of time-out in seconds. The default is 110.
proxyServer
Proxy server to use. Allowable formats include:
<http://>server<:port>
<http://>IP address<:port>
The
http://
and
port
are optional.
The default port is 1080. If your proxy server is listening on another port, you must specify a port number.
proxyUsername
Username used to authenticate against the proxy server if required. If the proxy server requires the domain name during authentication, add the domain name and a backslash: <domain>\<username>
proxyPassword
Password used to authenticate against the proxy server, if required.

Testing the Client

After you install and configure the client, test it immediately to ensure that the installation was successful.

Test the Client

  1. Go to the <installation directory>
    /samples/nvp
    directory.
  2. Run the test
    authCaptureSample.php
    script by typing: php authCaptureSample.php

    ADDITIONAL INFORMATION

    where php is the command-line interface (CLI) version. Depending on the PHP version, php may be in the main PHP directory, the
    sapi/cli
    directory, the
    cli
    directory, or it may be named
    php-cli.exe
    or
    php.exe
    .
    For example, for PHP 4.3.0 with Linux, you might have:
    <PHP directory>/sapi/cli/php authCaptureSample.php
    Or for PHP 4.3.8 with Windows, you might have:
    <PHP directory>\cli\php authCaptureSample.php
    or
    <PHP directory>\php.exe authCaptureSample.php
    The results of the test are displayed in the window.
    • If the test is successful, a decision of ACCEPT appears for both the credit card authorization and the follow-on capture.
    • If the test is not successful, a different decision value or an error message appears.

Troubleshoot Client Test Failures

  1. Verify that your
    cybs.ini
    settings are correct.
  2. Run the test again.
  3. If the test still fails, look at the error message and determine the return status value (a numeric value from -1 to 8).
  4. See the descriptions of the status values in Possible Return Status Values, and follow any instructions given there for the error you received.
  5. Run the test again.
  6. If the test still fails, contact Customer Support.

Run the XML Sample

  1. Go to the <installation directory>
    /sample/xml
    directory.
  2. For Windows, modify the
    cybs.ini
    in the folder with your settings (for Linux, make sure the
    samples/cybs.ini
    file is set how you want it).
  3. Run the test
    authSample.php
    script by typing: php authSample.php

    ADDITIONAL INFORMATION

    The results of the test are displayed in the window.
    • If the test is successful, you see a decision of ACCEPT for both the credit card authorization and the follow-on capture.
    • If the test is not successful, you see a different decision value or an error message. See Troubleshoot Client Test Failures to troubleshoot the error.

RESULT

The client is installed and tested. You are ready to create your own code for requesting
Cybersource
services. For information about creating requests, see Using Name-Value Pairs if you plan to use name-value pairs, or Using XML if you plan to use XML.

Going Live

When you complete all of your system testing and are ready to accept real transactions from your customers, your deployment is ready to
go live
.
After your deployment goes live, use real card numbers and other data to test every card type you support. Because these are real transactions in which you are buying from yourself, use small monetary amounts to do the tests. Process an authorization, then capture the authorization, and later refund the money. Use your bank statements to verify that money is deposited into and withdrawn from your merchant bank account as expected. If you have more than one
Cybersource
merchant ID, test each one separately.

Cybersource
Essentials Merchants

If you use
Cybersource
Essentials services, you can use the
Business Center
to go live. For a description of the process of going live, see the “Steps for Getting Started” section in Getting Started with Cybersource Essentials.
Configure your client so that it can send transactions to the production server and not the test server. For more information, see the description of the configuration setting sendToProduction.

Cybersource
Advanced Merchants

If you use
Cybersource
Advanced services, see Getting Started with Cybersource Advanced for information about going live.
When your deployment goes live, your
Cybersource
account is updated so that you can send transactions to the
Cybersource
production server. If you have not already done so, you must provide your banking information to
Cybersource
so that your processor can deposit funds to your merchant bank account.
After
Cybersource
has confirmed that your account is live, make sure that you update your system so that it can send requests to the production server (
ics2wsa.ic3.com
or
ics2ws.in.ic3.com
in India) using your security key for the production environment. The test server (
ics2wstesta.ic3.com
) cannot be used for real transactions. For more information about sending transactions to the production server, see the description of the configuration setting sendToProduction.

Updating the Client to Use a Later API Version

Cybersource
periodically updates the Simple Order API (previously called the Web Services API). You can update your existing client to work with the new API version. Go to https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor for a list of the available API versions. For transactions in India, go to https://ics2ws.in.ic3.com/commerce/1.x/transactionProcessor. Or, if you are in test mode, go to https://ics2wstesta.ic3.com/commerce/1.x/transactionProcessor.
To update the client to use a later API version, update the value for the
targetAPIVersion
configuration parameter in the
cybs.ini
file. For example, to use the 1.18 version of the API, set the property to
1.18
.

Special Installation Instructions for Oracle Users

If you are using Linux and an Oracle database, you must:
  • Load the Oracle extensions dynamically
  • In the
    php.ini
    file, load the
    Cybersource
    extension before the Oracle extensions

Load Oracle Extensions Dynamically After the
Cybersource
Extension

  1. At a command prompt, go to your PHP directory.
  2. Type
    make clean
    .
  3. Execute configure so that you are loading the Oracle extensions dynamically. To do this, include “shared,” before the path to each Oracle extension. For example, you might execute configure as follows:

    ADDITIONAL INFORMATION

    ./configure --prefix=<target PHP directory>
 --with-apxs=/usr/local/apache_1.3.32/bin/apxs
 --with-oracle=shared,/home/u01/app/oracle/product/8.1.7
 --with-oci8=shared,/home/u01/app/oracle/product/8.1.7
 --without-mysql
  4. Type:

    ADDITIONAL INFORMATION

    make make install
  5. In the “Dynamic Extensions” section of the
    php.ini
    file, add the
    Cybersource
    extension before the Oracle extensions:

    ADDITIONAL INFORMATION

    extension=php
    N
    _cybersource.so
    (where N represents the version of PHP: 4, 5, 503, or 512)
    extension = oracle.so
    extension = oci8.so
  6. Save the
    php.ini
    file.
  7. Continue with the original installation instructions (see Step 7 in Installing the Client).

PHP API for the Client

Summary of Functions

The client includes these functions:

cybs_load_config()

cybs_load_config()
Syntax
array cybs_load_config( string filename )
Description
Loads the configuration settings from a file
Returns
An array containing the configuration settings
Parameters
filename
: Name of the configuration file

cybs_run_transaction()

cybs_run_transaction()
Syntax
int cybs_run_transaction( array config, array request, array reply )
Description
Sends the request to the
Cybersource
server and receives the reply
Returns
A value that indicates the status of the request
Parameters
config
: Configuration array to use
request
: 
Array containing one of these:
  • The individual name-value pairs in the request (for name-value pair users)
  • A single key called
    CYBS_SK_XML_DOCUMENT
    whose value is the XML document representing the request (for XML users)
reply
: 
Array containing one of these:
You must create this array before you call cybs_run_transaction().
  • The individual name-value pairs in the reply (for name-value pair users)
  • A single key called
    CYBS_SK_XML_DOCUMENT
    whose value is the XML document representing the reply (for XML users)
  • A combination of the following keys and their values:
      CYBS_SK_ERROR_INFO
      CYBS_SK_RAW_REPLY
      CYBS_SK_FAULT_DOCUMENT
      CYBS_SK_FAULT_CODE
      CYBS_SK_FAULT_STRING
      CYBS_SK_FAULT_REQUEST_ID
    See below for descriptions of these keys.

Reply Key Descriptions

  • CYBS_SK_ERROR_INFO
    : Information about the error that occurred
  • CYBS_SK_RAW_REPLY
    : The server’s raw reply
  • CYBS_SK_FAULT_DOCUMENT
    : The entire, unparsed fault document
  • CYBS_SK_FAULT_CODE
    : The fault code, which indicates where the fault originated
  • CYBS_SK_FAULT_STRING
    : The fault string, which describes the fault
  • CYBS_SK_FAULT_REQUEST_ID
    : The request ID for the request

Possible Return Status Values

The cybs_run_transaction() function returns a status indicating the result of the request. Possible Status Values describes the possible status values, including whether the error is critical. If an error occurs after the request has been sent to the server, but the client cannot determine whether the transaction was successful, then the error is considered critical. If a critical error happens, the transaction may be complete in the
Cybersource
system but not complete in your order system. The descriptions below indicate how to handle critical errors.
The sample scripts display a numeric value for the return status, which is listed in the first column.
Possible Status Values
Numeric Value
(for Sample Scripts)
Value
Description
0
CYBS_S_OK
Critical:
No
Result:
The client successfully received a reply.
For name-value pair users, the
$reply
array has the reply name-value pairs for the services that you requested.
For XML users, the
$reply
array contains the response in XML format.
Manual action to take:
None
-1
CYBS_S_PHP_PARAM_ERROR
Critical:
No
Result:
The request was not sent because there was a problem with one or more of the parameters passed to the cybs_run_transaction() function.
Manual action to take:
Make sure the parameter values are correct.
1
CYBS_S_PRE_SEND_ERROR
Critical:
No
Result:
An error occurred before the request could be sent. This usually indicates a configuration problem with the client.
Error information to read:
$reply[CYBS_SK_ERROR_INFO]
Manual action to take:
Fix the problem described in the error information.
2
CYBS_S_SEND_ERROR
Critical:
No
Result:
An error occurred while sending the request.
Error information to read:
$reply[CYBS_SK_ERROR_INFO]
Manual action to take:
None
A typical send error that you might receive when testing occurs if the
ca-bundle.crt
file is not located in the same directory as your security key. For information about how to fix the problem, see the description of the configuration parameter sslCertFile.
3
CYBS_S_RECEIVE_ERROR
Critical:
Yes
Result:
An error occurred while waiting for or retrieving the reply.
Error information to read:
$reply[CYBS_SK_ERROR_INFO]
$reply[CYBS_SK_RAW_REPLY]
Manual action to take:
Check the Transaction Search screens on the Business Center to verify that the request was processed, and if so, whether it succeeded. Update your transaction database appropriately.
4
CYBS_S_POST_RECEIVE_ERROR
Critical:
Yes
Result:
The client received a reply or a fault, but an error occurred while processing it.
Error information to read:
$reply[CYBS_SK_ERROR_INFO]
$reply[CYBS_SK_RAW_REPLY]
Manual action to take:
Examine the value of
$reply[CYBS_SK_RAW_REPLY]
. If you cannot determine the status of the request, then check the Transaction Search screens on the
Business Center
to verify that the request was processed, and if so, whether it succeeded. Update your transaction database appropriately.
5
CYBS_S_CRITICAL_SERVER_FAULT
Critical:
Yes
Result:
The server returned a fault with
$reply[CYBS_SK_FAULT_CODE]
set to CriticalServerError.
Error information to read:
$reply[CYBS_SK_ERROR_INFO]
$reply[CYBS_SK_FAULT_CODE]
$reply[CYBS_SK_FAULT_STRING]
$reply[CYBS_SK_FAULT_DOCUMENT]
$reply[CYBS_SK_FAULT_REQUEST_ID]
Manual action to take:
Check the Transaction Search screens on the Business Center to verify that the request succeeded. When searching for the request, use the request ID provided by
$reply[CYBS_SK_FAULT_REQUEST_ID]
.
6
CYBS_S_SERVER_FAULT
Critical:
No
Result:
The server returned a fault with $reply[CYBS_SK_FAULT_CODE] set to ServerError, indicating a problem with the
Cybersource
server.
Error information to read:
$reply[CYBS_SK_ERROR_INFO]
$reply[CYBS_SK_FAULT_CODE]
$reply[CYBS_SK_FAULT_STRING]
$reply[CYBS_SK_FAULT_DOCUMENT]
Manual action to take:
None
7
CYBS_S_OTHER_FAULT
Critical:
No
Result:
The server returned a fault with $reply[CYBS_SK_FAULT_CODE] set to a value other than ServerError or CriticalServerError. Indicates a possible problem with merchant status or the security key. Could also indicate that the message was tampered with after it was signed and before it reached the
Cybersource
server.
Error information to read:
$reply[CYBS_SK_ERROR_INFO]
$reply[CYBS_SK_FAULT_CODE]
$reply[CYBS_SK_FAULT_STRING]
$reply[CYBS_SK_FAULT_DOCUMENT]
Manual action to take:
Examine the value of the
$reply[CYBS_SK_FAULT_STRING]
and fix the problem. You might need to generate a new security key, or you might need to contact Customer Support if there are problems with your merchant status.
A typical error that you might receive occurs if your merchant ID is configured for “test” mode but you send transactions to the production server. For information about fixing the problem, see the description of the configuration parameter sendToProduction.
8
CYBS_S_HTTP_ERROR
Critical:
No
Result:
The server returned an HTTP status code other than 200 (OK) or 504 (gateway timeout). Note that if a 504 gateway timeout occurs, then the status=
3
.
Error information to read:
$reply[CYBS_SK_ERROR_INFO]
$reply[CYBS_SK_RAW_REPLY]
Value of varReply:
CYBS_SK_RAW_REPLY
contains the HTTP response body, or if none was returned, the literal
"(no response available)"
.
Manual action to take:
None.
The following table summarizes which reply information you receive for each status value.

Figure:

Reply Information Available for Each Status Value

Using Name-Value Pairs

This section explains how to use the client to request
Cybersource
services by using name-value pairs.

Requesting
Cybersource
Services

To request
Cybersource
services, write code that:
  • Collects information for the
    Cybersource
    services that you will use
  • Assembles the order information into requests
  • Sends the requests to the
    Cybersource
    server
    The
    Cybersource
    servers do not support persistent HTTP connections.
  • Processes the reply information
The instructions in this section explain how to use PHP to request
Cybersource
services. For a list of API fields to use in your requests, see Related Documents.

Creating and Sending the Request

The code in this section’s example is incomplete. For a complete sample program, see the
authCaptureSample.php
file in the
<installation directory>
/samples/nvp
directory, or see the sample PHP pages.
To use any
Cybersource
service, you must create and send a request that includes the required information for that service.
The example that is developed in the following sections shows the basic PHP code for requesting
Cybersource
services. In this example, Jane Smith is buying an item for 29.95.

Loading the Configuration Settings

First load the configuration settings from a file:
$config = cybs_load_config( 'cybs.ini' );
You could instead create an array and add each configuration setting separately. You could also use a combination of the two methods: You could read the settings from a file and then add new settings dynamically with the array to override the settings read from the file.

Creating an Empty Request Array

You next create an array to hold the request fields:
$request = array();

Adding the Merchant ID

You next add the merchant ID to the request. You can let the
Cybersource
PHP extension automatically retrieve the merchant ID from the
$config
array, or you can set it directly in the
$request
array (see below). The
$request
array value overrides the
$config
array value.
$request['merchantID'] = 'infodev';

Adding Services to the Request Array

You next indicate the service you want to use by adding the field to the request. For example, to request a credit card authorization:
$request['ccAuthService_run'] = 'true';

Requesting a Sale

You can request multiple services by adding additional fields to the request. For example, if you fulfill the order immediately, you can request credit card authorization and capture together (referred to as a “sale”):
$request['ccAuthService_run'] = 'true'; $request['ccCaptureService_run'] = 'true';

Adding Service-Specific Fields to the Request Array

You next add the fields that are used by the services that you are requesting. If you request multiple services and they share common fields, you must add the field once only.
$request['merchantReferenceCode'] = '3009AF229L7W'; $request['billTo_firstName'] = 'Jane'; $request['billTo_lastName'] = 'Smith'; $request['card_accountNumber'] = '4111111111111111'; $request['item_0_unitPrice'] = '29.95';
The example above shows only a partial list of the fields you must send. Refer to Related Documents for information about the guides that list all of the fields for the services that you are requesting.

Sending the Request

You next create the array that will hold the reply and send the request:
$reply = array(); $status = cybs_run_transaction( $config, $request, $reply );

Interpreting the Reply

Handling the Return Status

The
$status
value is the handle returned by the cybs_run_transaction() method. The
$status
indicates whether the
Cybersource
server received the request, the client received the reply, or there were any errors or faults during transmission. See Possible Return Status Values for descriptions of each status value. For an example in addition to the following one, see the
authCaptureSample.php
file in the
<installation directory>
/samples/nvp
directory.
if ($status == 0)   // Read the value of the "decision" in the $reply array.   $decision = $reply['decision'];   // If decision=ACCEPT, indicate to the customer that the request was successful.   // If decision=REJECT, indicate to the customer that the order was not approved.   // If decision=ERROR, indicate to the customer that an error occurred and to try   // again later.   // Now get reason code results:   // $strContent = getReplyContent( $reply);   // See Processing the Reason Codes for how to process the   // reasonCode from the reply.   // Note that getReplyContent() is included in this document to help you   // understand how to process reason codes, but it is not included as part of the   // sample scripts or sample PHP pages. else { handleError( $status, $request, $reply ); } //--------------------- function handleError( $status, $request, $reply ) //---------------------   // handleError() shows how to handle the different errors that can occur. {   switch ($status)   {     // There was a problem with the parameters passed to cybs_run_transaction()     case CYBS_S_PHP_PARAM_ERROR:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Notify appropriate internal resources of the error.       break;     // An error occurred before the request could be sent.     case CYBS_S_PRE_SEND_ERROR:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Notify appropriate internal resources of the error.       break;     // An error occurred while sending the request.     case CYBS_S_SEND_ERROR:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       break;     // An error occurred while waiting for or retrieving the reply.     case CYBS_S_RECEIVE_ERROR:       // Critial error.       // Tell customer the order cannot be completed and to try again later.       // Notify appropriate internal resources of the error.       // See the sample code for more information about handling critical errors.       break;     // An error occurred after receiving and during processing of the reply.     case CYBS_S_POST_RECEIVE_ERROR:       // Critical error.       // Tell customer the order could not be completed and to try again later.       // Look at CYBS_SK_RAW_REPLY in $reply for the raw reply.       // Notify appropriate internal resources of the error.       // See the sample code for more information about handling critical errors.       break;     // CriticalServerError fault     case CYBS_S_CRITICAL_SERVER_FAULT:       // Critial error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from the $reply.       // Notify appropriate internal resources of the fault.       // See the sample code for more information about reading fault details and       // handling a critical error.       break;     // ServerError fault     case CYBS_S_SERVER_FAULT:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from the $reply.       // See the sample code for information about reading fault details.       break;     // Other fault     case CYBS_S_OTHER_FAULT:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from the $reply.       // Notify appropriate internal resources of the fault.       // See the sample code for information about reading fault details.       break;     // HTTP error     Case CYBS_S_HTTP_ERROR:       // Non-critical error.       // Tell customer the order cannot be completed and to try again later.       // Look at CYBS_SK_RAW_REPLY in $reply for the raw reply.       break;   } }

Processing the Reason Codes

After the
Cybersource
server processes your request, it sends a reply message that contains information about the services you requested. You receive different fields depending on the services you request and the outcome of each service.
To use the reply information, you must integrate it into your system and any other system that uses that data. For example, you can store the reply information in a database and send it to other back office applications.
You must write an error handler to process the reply information that you receive from
Cybersource
. Do not show the reply information directly to customers. Instead, present an appropriate response that tells customers the result.
Because we might add reply fields and reason codes at any time, you should parse the reply data according to the names of the fields instead of their order in the reply.
The most important reply fields to evaluate are the following:
  • decision
    : A one-word description of the results of your request. The decision is one of the following:
    • ACCEPT
      if the request succeeded
    • REJECT
      if one or more of the services in the request was declined
    • REVIEW
      if you are a
      Cybersource
      Advanced merchant using
      Decision Manager
      and it flags the order for review. See Handling
      Decision Manager
      Reviews,
      for more information.
    • ERROR
      if there was a system error. See Retrying When System Errors Occur, for important information about handling system errors.
  • reasonCode
    : A numeric code that provides more specific information about the results of your request.
You also receive a reason code for each service in your request. You can use these reason codes to determine whether a specific service succeeded or failed. If a service fails, other services in your request may not run. For example, if you request a credit card authorization and capture, and the authorization fails, the capture does not run. The reason codes for each service are described in .
We reserve the right to add new reason codes at any time. If your error handler receives a reason code that it does not recognize, it should use the decision to interpret the reply.
// Note that getReplyContent() is included in this document to help you understand // how to process reason codes, but it is not included as part of the sample scripts // or sample PHP pages. //---------------- function getReplyContent( $reply ) //---------------- {   $reasonCode = $reply['reasonCode']   switch ($reasonCode)   {     // Success     case '100':       return( sprintf(         "Request ID: %s\nAuthorizedAmount: %s\nAuthorization Code: %s,         $reply['requestID'], $reply['ccAuthReply_amount'],         $reply['ccAuthReply_authorizationCode'] ) );         break;     // Insufficient funds     case '204':       return( sprintf(       "Insufficient funds in account. Please use a different card or select another
         form of payment." ) );       break;     // Add other reason codes here that you must handle specifically. For all     // other reason codes, return an empty string, in which case, you should     // display a generic message appropriate to the decision value you received.     default:       return ( '' );   } }

Handling
Decision Manager
Reviews

If you use
Decision Manager
, you may also receive the
REVIEW
value in the
decision
field.
REVIEW
means that
Decision Manager
has marked the order for review based on how you configured the
Decision Manager
rules.
If you will be using
Decision Manager
, you have to determine how to handle the new
REVIEW
value. Ideally, you will update your order management system to recognize the
REVIEW
response and handle it according to your business rules. If you cannot update your system to handle the
REVIEW
response, we recommend that you choose one of these options:
  • If you authorize and capture the credit card payment at the same time, treat the
    REVIEW
    response like a
    REJECT
    response. Rejecting any orders that are marked for review may be appropriate if your product is a software download or access to a Web site. If supported by your processor, you may also want to reverse the authorization.
  • If you approve the order after reviewing it, convert the order status to
    ACCEPT
    in your order management system. You can request the credit card capture without requesting a new authorization.
  • If you approve the order after reviewing it but cannot convert the order status to
    ACCEPT
    in your system, request a new authorization for the order. When processing this new authorization, you must disable
    Decision Manager
    . Otherwise the order will be marked for review again. For details about the API field that disables
    Decision Manager
    , see the .
Alternately, you can specify a custom business rule in
Decision Manager
so that authorizations originating from a particular internal IP address at your company are automatically accepted.
If supported by your processor, you may want to reverse the original authorization.

Requesting Multiple Services

When you request multiple services in one request,
Cybersource
processes the services in a specific order. If a service fails,
Cybersource
does not process the subsequent services in the request.
For example, in the case of a sale (a credit card authorization and a capture requested together), if the authorization service fails,
Cybersource
will not process the capture service. The reply you receive only includes reply fields for the authorization.
This following additional example applies
to
Cybersource
Advanced merchants only.
Many
Cybersource
services include “ignore” fields that tell
Cybersource
to ignore the result from the first service when deciding whether to run the subsequent services. In the case of the sale, even though the issuing bank gives you an authorization code,
Cybersource
might decline the authorization based on the AVS or card verification results. Depending on your business needs, you might choose to capture these types of declined authorizations anyway. You can set the
businessRules_ignoreAVSResult
field to “true” in your combined authorization and capture request:
$request['businessRules_ignoreAVSResult'] = 'true';
This tells
Cybersource
to continue processing the capture even if the AVS result causes
Cybersource
to decline the authorization. In this case you would then get reply fields for both the authorization and the capture in your reply.
You are charged only for the services that
Cybersource
performs.

Retrying When System Errors Occur

You must design your transaction management system to include a way to correctly handle
Cybersource
system errors. Depending on which payment processor is handling the transaction, the error may indicate a valid
Cybersource
system error, or it may indicate a processor rejection because of some type of invalid data. In either case, we recommend that you do not design your system to retry sending a transaction many times in the case of a system error.
Instead, we recommend that you retry sending the request only two or three times with successively longer periods of time between each retry. For example, after the first system error response, wait 30 seconds and then retry sending the request. If you receive the same error a second time, wait one minute before you send the request again. Depending on the situation, you may decide you can retry sending the request after a longer time period. Determine what is most appropriate for your business situation.
If after several retry attempts you are still receiving a system error, it is possible that the error is actually being caused by a processor rejection and not a
Cybersource
system error. In that case, we suggest that you either:
  • Search for the transaction in the
    Business Center
    , look at the description of the error on the Transaction Detail page, and call your processor to determine if and why they are rejecting the transaction.
  • Contact
    Cybersource
    Customer Support to confirm whether your error is truly caused by a
    Cybersource
    system issue.
If
TSYS Acquiring Solutions
is your processor, you may want to follow the first suggestion as there are several common
TSYS Acquiring Solutions
processor responses that are returned to you as system errors and that only
TSYS Acquiring Solutions
can address.

Using XML

This section describes how to request
Cybersource
services using XML.

Requesting
Cybersource
Services

To request
Cybersource
services, write code that:
  • Collects information for the
    Cybersource
    services that you will use
  • Assembles the order information into requests
  • Sends the requests to the
    Cybersource
    server
    The
    Cybersource
    servers do not support persistent HTTP connections.
  • Processes the reply information
The instructions in this section explain how to write the code that requests these services. For a list of API fields to use in your requests, see Related Documents.

Sample Code

We suggest that you examine the name-value pair sample code provided in
authCaptureSample.php
before implementing your code to process XML requests. The sample will give you a basic understanding of how to request
Cybersource
services. The sample code file is located in the <installation directory>
/samples/nvp
directory.
After examining that sample code, read this section to understand how to create code to process XML requests. Note that the code in this section’s example is incomplete. For a complete sample program, see the
authSample.php
file in the <installation directory>
/samples/xml
directory.

Creating a Request Document

The client allows you to create an XML request document using any application, then send the request to
Cybersource
. For example, if you have a customer relationship management (CRM) system that uses XML to communicate with other systems, you can use the CRM system to generate request documents.
The request document must validate against the XML schema for
Cybersource
transactions. To view the schema, go to 
https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor 
and look at the XSD file for the version of the Simple Order API you are using.
Make sure that the elements in your document appear in the correct order. If they do not, your document will not validate, and your request will fail.
The example developed in the following sections shows a basic XML document for requesting
Cybersource
services. In this example, Jane Smith is buying an item for 29.95.
The XML document in this example is incomplete. For a complete example, see the
auth.xml
document in the
samples/xml
directory.

Creating an Empty Request

Add the XML declaration and the document’s root element:
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18"> </requestMessage>
When you construct a request, you must indicate the correct namespace for the elements, and the namespace must use the same API version that you specify in the configuration settings file. For example, if
targetAPIVersion
=
1.18
in the
cybs.ini
file, the namespace must be
urn:schemas-cybersource-com:transaction-data-1.18
.
The XML document that you receive in the reply always uses a prefix of
c:
(for example,
xmlns:c="urn:schemas-cybersource-com:transaction-data-1.18"
). Make sure you use an XML parser that supports namespaces.

Adding the Merchant ID

You next add the merchant ID to the request.
If you specify a merchant ID in the XML document, it overrides the merchant ID you specify in the configuration settings file.
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18">   <merchantID>infodev</merchantID> </requestMessage>

Adding Services to the Request

You next indicate the service that you want to use by creating an element for that service in the request, then setting the element’s
run
attribute to
true
. For example, to request a credit card authorization:
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18">   <merchantID>infodev</merchantID>   <ccAuthService run="true"/> </requestMessage>

Requesting a Sale

You can request multiple services by adding additional elements. For example, if you fulfill the order immediately, you can request a credit card authorization and capture together (referred to as a “sale”):
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18">   <merchantID>infodev</merchantID>   <ccAuthService run="true"/>   <ccCaptureService run="true"/> </requestMessage>

Adding Service-Specific Fields to the Request

You next add the fields that are used by the services you are requesting. Most fields are child elements of container elements; for example, a
<card>
element contains the customer’s credit card information.
<?xml version="1.0" encoding="utf-8"?> <requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.18">   <merchantID>infodev</merchantID>   <billTo>     <firstName>Jane</firstName>     <lastName>Smith</lastName>   </billTo>   <item id="0">     <unitPrice>29.95</unitPrice>   </item>   <card>     <accountNumber>4111111111111111</accountNumber>   </card>   <ccAuthService run="true"/> </requestMessage>
The example above shows only a partial list of the fields you must send. Refer to Related Documents for information about the guides that list all of the fields for the services that you are requesting.

Sending the Request

Once you have created an XML document, you use PHP to send the request to
Cybersource
.

Loading the Configuration Settings

First load the configuration settings from a file:
$config = cybs_load_config( 'cybs.ini' );
The namespace that you specify in the XML document must use the same API version that you specify in the configuration settings file. For example, if
targetAPIVersion
=
1.18
in the file, the namespace must be
urn:schemas-cybersource-com:transaction-data-1.18
. The example code below retrieves the API version from the configuration settings file and places it in the XML document.

Reading the XML Document

// Read the XML document. // See the authSample.php script for // the implementation of getFileContent(). $inputXML = getFileContent( "MyXMLDocument.xml" ); // Retrieve the target API version from the configuration settings // and replace the value in the XML document. $inputXML   = str_replace(   "_APIVERSION_", $config[CYBS_C_TARGET_API_VERSION], $inputXML );

Sending the Request

You next create the request array, add the XML document to the array, and send the request:
$request = array(); $request[CYBS_SK_XML_DOCUMENT] = $inputXML; // send request $reply = array(); $status = cybs_run_transaction( $config, $request, $reply );

Interpreting the Reply

Handling the Return Status

The
$status
value is the handle returned by the cybs_run_transaction() method. The
$status
indicates whether the
Cybersource
server received the request, the client received the reply, or there were any errors or faults during transmission. See Possible Return Status Values for descriptions of each status value. For an example in addition to the following one, see the
authSample.php
file in the client’s
<installation directory>
/samples/xml
directory.
if ($status == CYBS_S_OK)   // Read the value of the "decision" in the oReplyMessage.   // This code assumes you have a method called getField ()   // that retrieves the specified field from the XML document   // in $reply[CYBS_SK_XML_DOCUMENT].   $decision = getField( $reply, "decision" );   // If decision=ACCEPT, indicate to the customer that   // the request was successful.   // If decision=REJECT, indicate to the customer that the   ' order was not approved.   ' If decision=ERROR, indicate to the customer that there   // was an error and to try again later.   ' Now get reason code results:   // $strContent = getReplyContent( $reply );   ' See Processing the Reason Codes for how to process the reasonCode   ' from the reply.   ' Note that getReplyContent() is included in this document to help you understand   ' how to process reason codes, but it is not included as part of the sample   ' scripts or sample PHP pages. else { handleError( $status, $request, $reply ); } //--------------------- function handleError( $status, $request, $reply ) //--------------------- {   switch ($status)   {     // There was a problem with the parameters passed to     // cybs_run_transaction()     case CYBS_S_PHP_PARAM_ERROR:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Notify appropriate internal resources of the error.       break;     // An error occurred before the request could be sent.     case CYBS_S_PRE_SEND_ERROR:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Notify appropriate internal resources of the error.       break;     // An error occurred while sending the request.     case CYBS_S_SEND_ERROR:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       break;     // An error occurred while waiting for or retrieving     // the reply.     case CYBS_S_RECEIVE_ERROR:       // Critial error.       // Tell customer the order could not be completed and to try again later.       // Notify appropriate internal resources of the error.       // See the sample code for more information about handling critical errors.       break;     // An error occurred after receiving and during processing     // of the reply.     case CYBS_S_POST_RECEIVE_ERROR:       // Critical error.       // Tell customer the order could not be completed and to try again later.       // Look at CYBS_SK_RAW_REPLY in $reply for the raw reply.       // Notify appropriate internal resources of the error.       // See the sample code for more information about handling critical errors.       break;     // CriticalServerError fault     case CYBS_S_CRITICAL_SERVER_FAULT:       // Critial error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from the $reply.       // Notify appropriate internal resources of the fault.       // See the sample code for more information about reading fault details and       // handling a critical error.       break;     // ServerError fault     case CYBS_S_SERVER_FAULT:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from the $reply.       // See the sample code for information about reading fault details.       break;     // Other fault     case CYBS_S_OTHER_FAULT:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Read the various fault details from the $reply.       // Notify appropriate internal resources of the fault.       // See the sample code for information about reading fault details.       break;     // HTTP error     Case CYBS_S_HTTP_ERROR:       // Non-critical error.       // Tell customer the order could not be completed and to try again later.       // Look at CYBS_SK_RAW_REPLY in $reply for the raw reply.       break;   } }

Processing the Reason Codes

After the
Cybersource
server processes your request, it sends a reply message that contains information about the services you requested. You receive different fields depending on the services you request and the outcome of each service.
To use the reply information, you must integrate it into your system and any other system that uses that data. For example, you can store the reply information in a database and send it to other back office applications.
You must write an error handler to process the reply information that you receive from
Cybersource
. Do not show the reply information directly to customers. Instead, present an appropriate response that tells customers the result.
Because we may add reply fields and reason codes at any time, you should parse the reply data according to the names of the fields instead of their order in the reply. If your error handler receives a reason code that it does not recognize, it should use the decision to interpret the reply.
The most important reply fields to evaluate are the following:
  • decision
    : A one-word description of the results of your request. The decision is one of the following:
    • ACCEPT
      if the request succeeded
    • REJECT
      if one or more of the services in the request was declined
    • REVIEW
      if you use
      Decision Manager
      and it flags the order for review. See Handling
      Decision Manager
      Reviews
      for more information.
    • ERROR
      if there was a system error. See Retrying When System Errors Occur for important information about handling system errors.
  • reasonCode
    : A numeric code that provides more specific information about the results of your request.
You also receive a reason code for each service in your request. You can use these reason codes to determine whether a specific service succeeded or failed. If a service fails, other services in your request may not run. For example, if you request a credit card authorization and capture, and the authorization fails, the capture does not run. The reason codes for each service are described in
// Note that getReplyContent() is included in this document to help you understand // how to process reason codes, but it is not included as part of the sample // scripts or sample PHP pages. // This code assumes you have a method called getField() that retrieves the // specified field from the XML document in $reply[CYBS_SK_XML_DOCUMENT]. //---------------- function getReplyContent( $reply ) //---------------- {   $reasonCode = $reply['reasonCode']   switch ($reasonCode)   {     // Success     case '100':       return( sprintf(         "Request ID: %s\nAuthorizedAmount:           %s\nAuthorization Code: %s,         getField( $reply, 'requestID' ), getField ($reply,           'ccAuthReply/amount' ),         getField( $reply, 'ccAuthReply/authorizationCode' ) ) );         break;     // Insufficient funds     case '204':       return( sprintf(       "Insufficient funds in account. Please use a different
         card or select another form of payment." ) );       break;     // add other reason codes here that you must handle specifically. For all     // other reason codes, return an empty string, in which case, you should     // display a generic message appropriate to the decision value you received.     default:       return ( '' );   } }

Handling
Decision Manager
Reviews

If you use
Decision Manager
, you may also receive the
REVIEW
value in the
decision
field.
REVIEW
means that
Decision Manager
has marked the order for review based on how you configured the
Decision Manager
rules.
If you will be using
Decision Manager
, you have to determine how to handle the new
REVIEW
value. Ideally, you will update your order management system to recognize the
REVIEW
response and handle it according to your business rules. If you cannot update your system to handle the
REVIEW
response, we recommend that you choose one of these options:
  • If you authorize and capture the credit card payment at the same time, treat the
    REVIEW
    response like a
    REJECT
    response. Rejecting any orders that are marked for review may be appropriate if your product is a software download or access to a Web site. If supported by your processor, you may also want to reverse the authorization.
  • If you approve the order after reviewing it, convert the order status to
    ACCEPT
    in your order management system. You can request the credit card capture without requesting a new authorization.
  • If you approve the order after reviewing it but cannot convert the order status to
    ACCEPT
    in your system, request a new authorization for the order. When processing this new authorization, you must disable
    Decision Manager
    . Otherwise the order will be marked for review again. For details about the API field that disables
    Decision Manager
    , see the .
Alternately, you can specify a custom business rule in
Decision Manager
so that authorizations originating from a particular internal IP address at your company are automatically accepted.
If supported by your processor, you may want to reverse the original authorization.

Requesting Multiple Services

When you request multiple services in one request,
Cybersource
processes the services in a specific order. If a service fails,
Cybersource
does not process the subsequent services in the request.
For example, in the case of a sale (a credit card authorization and a capture requested together), if the authorization service fails,
Cybersource
does not process the capture service. The reply you receive only includes reply fields for the authorization.
This following additional example applies
to
Cybersource
Advanced merchants only.
Many
Cybersource
services include “ignore” fields that tell
Cybersource
to ignore the result from the first service when deciding whether to run the subsequent services. In the case of the sale, even though the issuing bank gives you an authorization code,
Cybersource
might decline the authorization based on the AVS or card verification results. Depending on your business needs, you might choose to capture these types of declined authorizations anyway. You can set the
businessRules_ignoreAVSResult
field to “true” in your combined authorization and capture request:
<businessRules>     <ignoreAVSResult>true</ignoreAVSResult> </businessRules>
This tells
Cybersource
to continue processing the capture even if the AVS result causes
Cybersource
to decline the authorization. In this case you would then get reply fields for both the authorization and the capture in your reply.
You are charged only for the services that
Cybersource
performs.

Retrying When System Errors Occur

You must design your transaction management system to include a way to correctly handle
Cybersource
system errors. Depending on which payment processor is handling the transaction, the error may indicate a valid
Cybersource
system error, or it may indicate a processor rejection because of some type of invalid data. In either case, we recommend that you do not design your system to retry sending a transaction many times in the case of a system error.
Instead, we recommend that you retry sending the request only two or three times with successively longer periods of time between each retry. For example, after the first system error response, wait 30 seconds and then retry sending the request. If you receive the same error a second time, wait one minute before you send the request again. Depending on the situation, you may decide you can retry sending the request after a longer time period. Determine what is most appropriate for your business situation.
If after several retry attempts you are still receiving a system error, it is possible that the error is actually being caused by a processor rejection and not a
Cybersource
system error. In that case, we suggest that you either:
  • Search for the transaction in the
    Business Center
    , look at the description of the error on the Transaction Detail page, and call your processor to determine if and why they are rejecting the transaction.
  • Contact
    Cybersource
    Customer Support to confirm whether your error is truly caused by a
    Cybersource
    system issue.
If
TSYS Acquiring Solutions
is your processor, you may want to follow the first suggestion as there are several common
TSYS Acquiring Solutions
processor responses that are returned to you as system errors and that only
TSYS Acquiring Solutions
can address.

Advanced Configuration Settings

Using Alternate Server Configuration Settings

You use the serverURL and namespaceURI configuration settings if
Cybersource
changes the convention we use to specify the server URL and namespace URI, but we have not updated the client yet.
For example, these are the server URLs and namespace URI for accessing the
Cybersource
services using the Simple Order API version 1.18:
  • Test server URLs:
    Internet endpoint:
    https://ics2wstest.ic3.com/commerce/1.x/transactionProcessor
    Akamai endpoint:
    https://ics2wstesta.ic3.com/commerce/1.x/transactionProcessor
  • Production server URLs:
    Internet endpoint:
    https://ics2ws.ic3.com/commerce/1.x/transactionProcessor
    Akamai endpoint:
    https://ics2wsa.ic3.com/commerce/1.x/transactionProcessor
    India endpoint:
    https://ics2ws.in.ic3.com/commerce/1.x/transactionProcessor
  • Namespace URI:
    urn:schemas-cybersource-com:transaction-data-1.18
    .
If you view the above URLs in a web browser, a list of the supported API versions and the associated schema files are displayed.
If in the future
Cybersource
changes these conventions, but does not provide a new version of the client, you can configure your existing client to use the new server and namespace conventions required by the
Cybersource
server.

Configuring Your Settings for Multiple Merchant IDs

If you have multiple merchant IDs, or if you are a reseller handling multiple merchants, you can have different configuration settings for different merchant IDs. You set these in the configuration object that you pass to the cybs_run_transaction() function. When using the samples provided in the client package, you set the configuration parameters in
cybs.ini
file.
All of the properties except merchantID can be prefixed with
<merchantID>.
to specify the settings for a specific merchant.
Example: Merchant-Specific Properties Settings
If you have a merchant with merchant ID of
merchant123
, and you want enable logging only for that merchant, you can set the enableLog parameter to
true
for all requests that have
merchant123
as the merchant ID:
merchant123.enableLog=true enableLog=false
The client disables logging for all other merchants.

Using the Client Application Fields

This section lists optional client application fields that you can include in your request to describe your client application. Use these fields only if you are building an application to sell to others. For example, a shopping cart application. Do not use the fields if you are only integrating the client with your own web store.
Client Application Fields
Field Name
Description
Data Type and Length
clientApplication
Application or integration that uses the client: for example:
ShoppingCart Pro
or
Web Commerce Server
. Do not include a version number.
String (50)
clientApplicationVersion
Version of the application or integration, for example:
5.0
or
1.7.3
.
String (50)
clientApplicationUser
User of the application or integration, for example:
jdoe
.
String (30)
If you use these fields in your request, you can view their values in the Transaction Search Details page of the
Business Center
.