Client SDK So API

Title Page
CyberSource Simple Order API Client

Developer Guide
CyberSource Contact Information
For general information about our company, products, and services, go to http://www.cybersource.com.
For sales questions about any CyberSource service, email sales@cybersource.com or call 650-432-7350
or 888-330-2300 (toll free in the United States).
For support information about any CyberSource service, visit the Support Center:
http://www.cybersource.com/support
Copyright
© 2020. CyberSource Corporation. All rights reserved. CyberSource Corporation ("CyberSource") furnishes this
document and the software described in this document under the applicable agreement between the reader of
this document ("You") and CyberSource ("Agreement"). You may use this document and/or software only in
accordance with the terms of the Agreement. Except as expressly set forth in the Agreement, the information
contained in this document is subject to change without notice and therefore should not be interpreted in any way
as a guarantee or warranty by CyberSource. CyberSource assumes no responsibility or liability for any errors
that may appear in this document. The copyrighted software that accompanies this document is licensed to You
for use only in strict accordance with the Agreement. You should read the Agreement carefully before using the
software. Except as permitted by the Agreement, You may not reproduce any part of this document, store this
document in a retrieval system, or transmit this document, in any form or by any means, electronic, mechanical,
recording, or otherwise, without the prior written consent of CyberSource.
Restricted Rights Legends

For Government or defense agencies: Use, duplication, or disclosure by the Government or defense agencies
is subject to restrictions as set forth the Rights in Technical Data and Computer Software clause at DFARS
252.227-7013 and in similar clauses in the FAR and NASA FAR Supplement.
For civilian agencies: Use, reproduction, or disclosure is subject to restrictions set forth in subparagraphs (a)
through (d) of the Commercial Computer Software Restricted Rights clause at 52.227-19 and the limitations set
forth in CyberSource Corporation's standard commercial agreement for this software. Unpublished rights
reserved under the copyright laws of the United States.
Trademarks
Authorize.Net, eCheck.Net, and The Power of Payment are registered trademarks of CyberSource Corporation.
CyberSource, CyberSource Payment Manager, CyberSource Risk Manager, CyberSource Decision Manager,
and CyberSource Connect are trademarks and/or service marks of CyberSource Corporation. Visa, Visa
International, CyberSource, the Visa logo, and the CyberSource logo are the registered trademarks of Visa
International in the United States and other countries. All other trademarks, service marks, registered marks, or
registered service marks are the property of their respective owners.
Revision: July 2020
2
CONTENTS
Contents
Recent Revisions to This Document 11
About This Guide 12

Audience 12
Purpose 12
Scope 12
Conventions 13
Note, Important, and Warning Statements 13
Text and Command Conventions 13
Related Documents 14
Client Package Documentation 14
CyberSource Services Documentation 14
Customer Support 14
Chapter 1 Introduction 15
Chapter 2 C/C++ Client 16

Choosing Your API and Client 16
API Variation 16
Client Versions 16
Sample Code 17
Basic C/C++ Page Example 17
Installing and Testing the Client 19
Minimum System Requirements 19
For Linux 19
For Windows 19
Transaction Security Keys 19
Installing the Client 20
Configuring Client Settings 21
Testing the Client 23
Simple Order API Client Developer Guide | 3

Contents
Going Live 24
CyberSource Essentials Merchants 24
CyberSource Advanced Merchants 25
Updating the Client to Use a Later API Version 25
C/C++ API for the Client 26
CybsMap Structure 26
Available Functions 26
cybs_load_config() 26
cybs_create_map() 27
cybs_destroy_map() 27
cybs_set_add_behavior() 27
cybs_get() 28
cybs_get_first() 29
cybs_get_next() 29
cybs_get_count() 30
cybs_create_map_string() 30
cybs_destroy_map_string() 30
cybs_run_transaction() 31
Using Name-Value Pairs 36
Requesting CyberSource Services 36
Sample Code 36
Creating and Sending Requests 36
Adding the Use Statement 36
Loading the Configuration Settings 37
Creating the Empty Request and Reply 37
Adding the Merchant ID 37
Adding Services to the Request Structure 37
Requesting a Sale 37
Adding Service-Specific Fields to the Request 38
Sending the Request 38
Interpreting Replies 39
Handling the Return Status 39
Processing the Reason Codes 42
Handling Decision Manager Reviews 44
Requesting Multiple Services 45
Retrying When System Errors Occur 45
Using XML 46
Sample Code 47
Creating a Request Document 47
Creating an Empty Request 48
Adding Services to the Request 48

Contents

Sending Requests 50
Adding the Use Statement 50
Creating the Empty Request and Reply 50
Reading the XML Document 51
Advanced Configuration Information 60
Using Alternate Server Configuration Settings 60
Configuring for Multiple Merchant IDs 61
Chapter 3 .NET 4.0 or Later Client 62

Choosing an API and Client 62
API Variation 62
Client Versions 63
Basic C# Program Example 63
Using the NuGet Package Manager 66
Installing Individual Files 66
Upgrading from a Previous Version 67
Migrating from .NET Framework 1.x 67
Migrating from .NET Framework 2.x 68
Using the Test Applications 70
Configuring the Test Applications 70
Configuring Your Settings for Multiple Merchants 73
Running the Test Applications 73
Deploying the Client to Another Computer 73
Going Live 74
Name-Value Pair Client 75
SOAP Client 75

Contents
XML Client 76
Creating and Sending the Request 77
Creating a New Visual Studio .NET Project 77
Importing the Client Classes 77
Interpreting the Reply 79
Using the Decision and Reason Code 81
For CyberSource Advanced Merchants: Handling Decision Manager Reviews 83
Creating an Application Settings File 85
Using XML 86
For CyberSource Advanced Merchants: Handling Decision Manager Reviews 95
Using SOAP 98

Contents

For CyberSource Advanced Merchants: Handling Decision Manager
Reviews 105
Setting the Connection Limit 108
Examples 108
References 109
Sample ASP.NET Code Using Visual Basic 110
Chapter 4 Java Client 114

API Variations 114
Client Versions 115
Sample Code 115
Basic Java Program Example 116
Using a Package Manager 119
Installing Individual Files 120
Configuring Client Properties 120
Running the SDK Integration Tests 122
Running the Samples 123
Going Live 123
Creating and Sending Requests 125
Loading the Configuration File 125

Contents

Using the Decision and Reason Code Fields 129
Handling Decision Manager Reviews (CyberSource Advanced Services
Only) 131
Using XML 133
Creating Requests 134
Sending Requests 136
Loading the Configuration File 137
Handling Decision Manager Reviews (CyberSource Advanced Merchants) 141
Handling System Errors 141
Advanced Configuration Information 143
Using Alternate Server Properties 143
Configuring for Multiple Merchant IDs 143
Using System Properties 144
Resolving Connection Issues 144
Oracle Java SDK version earlier than 1.4.0 144
IBM Java SDK 145
Importing the Root CA Certificate 146
Chapter 5 PHP Client 147

Using PHP in a Hosted Environment 147
API Variation 148
Client Versions 148
Sample Code 149
Basic PHP Page Example 149
Sample Scripts 150
Sample PHP Pages 150
For Linux 152
For Windows 152
Configuring Client Settings 156

Contents

Going Live 160
Special Installation Instructions for Oracle Users 161
PHP API for the Client 162
Summary of Functions 162
cybs_load_config() 162
cybs_run_transaction() 163
Reply Key Descriptions 163
Possible Return Status Values 164
Creating an Empty Request Array 169
Adding Services to the Request Array 170
Adding Service-Specific Fields to the Request Array 170
Using XML 178
Sample Code 178
Reading the XML Document 182

Contents

Advanced Configuration Settings 190
Using Alternate Server Configuration Settings 190
Configuring Your Settings for Multiple Merchant IDs 191
Appendix A Using the Client Application Fields 192

REVISIONS
Recent Revisions to This
Document
Release Changes
July 2020 Added endpoints for merchants in India.
September 2019 Deprecated and deleted Perl and ASP sections and removed ASP and Perl
section references from About this Guide and Introduction sections.
April 2019 Updated .NET 4.0 to .NET 4.0 or later.
Updated the types of endpoints:
 C/C++: "Using Alternate Server Configuration Settings," page 60
 Java: "Using Alternate Server Properties," page 143
 PHP: "Using Alternate Server Configuration Settings," page 190
Updated the following sections in the .NET 4.0 or Later chapter:
 "Installing the Client," page 66
 "Testing the Client," page 70
Updated the following sections in the Java chapter:
 "Installing the Client," page 119
 "Testing the Client," page 122
September 2015 Updated the production server URL and the test server URL.
September 2014 Added the new .NET 4.0 client chapter. See ".NET 4.0 or Later Client,"
page 62.
April 2013 Noted that all of the Simple Order API clients except the .NET 4.0 client are
supported only on 32-bit operating systems.
Combined all Simple Order API client documents into this developer guide,
which covers all supported programming languages.

ABOUT GUIDE
About This Guide
Audience
This guide is written for application developers who want to use the CyberSource Simple
Order API client to integrate the following CyberSource services into their order
management system:
 CyberSource Essentials
 CyberSource Advanced
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.
Purpose
This guide describes tasks you must complete to install, test, and use the CyberSource
Simple Order API client software.
Scope
This guide describes how to install, test, and use all available Simple Order API clients. It
does not describe how to implement CyberSource services with the Simple Order API. For
information about how to use the API to implement CyberSource services, see "Related
Documents," page 14.

About This Guide
Conventions
Note, Important, and Warning Statements
A Note contains helpful suggestions or references to material not contained 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.
Text and Command Conventions

Convention Usage
bold  Field and service names; for example:
Include the ics_applications field.
 Items that you are instructed to act upon; for example:
Click Save.
italic  Filenames and pathnames. For example:
Add the filter definition and mapping to your web.xml file.
 Placeholder variables for which you supply particular values.
screen text  XML elements.
 Code examples and samples.
 Text that you enter in an API environment; for example:
Set the davService_run field to true.
The Simple Order API was originally referred to as the Web Services API in
CyberSource documentation. References to the Web Services API may still
appear in some locations.

About This Guide
Related Documents
Client Package Documentation

The following documentation is available in the client package download:
 README file
 CHANGES file
 Sample code files
CyberSource Services Documentation

This guide (Simple Order API Client Developer Guide) contains information about how to:
 Create the request
 Send the request
 Receive the reply
In contrast, CyberSource services documentation listed in Table 1 contains information

about how to:
 Determine what to put in requests sent to CyberSource.
 Interpret what is contained in the reply from CyberSource.
Each type of CyberSource service has associated documentation:
Table 1 CyberSource Services Documentation
Type of Service Available Documentation

CyberSource Essentials  Credit Card Services User Guide (PDF | HTML)
 Electronic Check Services User Guide (PDF | HTML)
CyberSource Advanced  Credit Card Services Using the Simple Order API
(PDF | HTML)
 Reporting User Guide (PDF | HTML)
If you use other CyberSource services, the documentation can be found on the
CyberSource Essentials or CyberSource Advanced (Global Payment Services) sections
of the CyberSource web site.
Customer Support
For support information about any CyberSource service, visit the Support Center:
http://www.cybersource.com/support

CHAPTER
Introduction
1
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 CyberSource 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

CHAPTER
C/C++ Client
2
 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 Appendix A, "Using the Client
Application Fields," on page 192. This appendix has 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 window 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
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
For transactions in India, go to:

https://ics2ws.in.ic3.com/commerce/1.x/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.

Chapter 2 C/C++ Client
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," page 23, 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," page 17). "Using Name-Value Pairs," page 36, 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" );

// 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," page 39.

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)
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 Creating and Using Security
Keys (PDF | HTML).

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," page 22).
You must protect your security key to ensure that your CyberSource account is
not compromised.
Installing the Client
To install the client:
Step 1 Go to the client downloads page on the Support Center.
Step 2 Download the latest client package, and save it in any directory.
Step 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.
Step 4 Configure the client. See "Configuring Client Settings" below.
Step 5 Test the client. See "Testing the Client," page 23.
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," page 36, if you plan to use name-value pairs, or "Using XML,"
page 46, 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," page 26). Table 2 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 Table 2. 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," page 61, for more information.
Table 2 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.
Note CyberSource recommends 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," page 16, 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.
Note See the Simple Order API Release Notes, for information about
what has changed in each version.
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," page 60, 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," page 60, for more information. Give the complete
namespace URI, as it will be used exactly as you specify here.

Table 2 Configuration Settings (Continued)
Setting Description
enableLog Flag directing the client to log transactions and errors. Possible values:
 false: Do not enable logging (default setting).
 true: Enable logging.
Important Logging can cause very large log files to accumulate.
Therefore, CyberSource recommends 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.<yyyymmddThhmmssxxx> 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.
Note The default port is 1080. If your proxy server is listening on another
port, you must specify a port number.

Setting Description
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.
To test the client:
Step 1 At a command prompt, go to the <installation directory>/samples/nvp

directory.
Step 2 Run the sample program by typing

authCaptureSample
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.
To troubleshoot if the test fails:
Step 1 Check to see that your cybs.ini settings are correct.
Step 2 Run the test again.
Step 3 If the test still fails, look at the error message and find the return status value (a numeric
value from 0 to 8).
Step 4 See the descriptions of the status values in "Possible Return Status Values," page 32, and
follow any instructions given there for the error you received.
Step 6 If the test still fails, contact Customer Support.

To run the XML sample:
Step 1 At a command prompt, go to the <installation directory>/samples/xml

directory.
Step 2 Run the sample program by typing

authSample

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. For a description of the process of going live, see the “Steps for Getting Started”
section in 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
sendToProduction setting in Table 2, page 21.
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 the “Steps for Getting Started” chapter in
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," page 21.
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
CyberSource 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 these sections:
"cybs_load_config()," page 26 "cybs_get_first()," page 29

"cybs_create_map()," page 27 "cybs_get_next()," page 29
"cybs_destroy_map()," page 27 "cybs_get_count()," page 30
"cybs_set_add_behavior()," page 27 "cybs_create_map_string()," page 30
"cybs_add()," page 28 "cybs_destroy_map_string()," page 30
"cybs_remove()," page 28 "cybs_run_transaction()," page 31
"cybs_get()," page 28
cybs_load_config()
Table 3 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()," page 27) of the returned map is set to 2
(overwrite). This allows you to use the cybs_add() function ("cybs_add()," page 28) 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(),"
page 27).
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()
Table 4 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(),"
page 27).
Returns Returns a pointer to the new empty CybsMap structure.
Parameters None.
cybs_destroy_map()
Table 5 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()
Table 6 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()
Table 7 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()
Table 8 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()
Table 9 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()
Table 10 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()," page 29).
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()
Table 11 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().
*pszName: Pointer to the first name in the map.
*pszValue: Pointer to the value of the first name in the map.

cybs_get_count()
Table 12 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.
cybs_create_map_string()
Table 13 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.
cybs_destroy_map_string()
Table 14 cybs_destroy_map_string()
Syntax void cybs_destroy_map_string( char *szMapString )

Description Destroys a string created with cybs_create_map_string().
Parameters szMapString: The map string to destroy.

cybs_run_transaction()
Table 15 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 Table 16, "Possible Status Values," for a list of
values).
Parameters pconfig: Pointer to the configuration map structure to use.
pRequest: Pointer to a map  The individual name-value pairs in the request (for name-
structure containing one of these: 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  The individual name-value pairs in the reply (for name-value
a map structure containing one pair users)
of these:
 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.
Note You must later free the *ppReply pointer with cybs_
destroy_map() (see "cybs_destroy_map()," page 27).
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.
Table 16 Possible Status Values
Numeric
Value (for
Value Description
Sample
Code)
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_ Critical: No
PRE_SEND_
Result: An error occurred before the request could be sent. This usually
ERROR
indicates a configuration problem with the client.
Keys in **ppReply: _error_info
Manual action to take: Fix the problem described in the error information.
SEND_
Result: An error occurred while sending the request.
ERROR
Keys in **ppReply: _error_info
Note 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 Table 2,
"Configuration Settings," for information about how to fix the problem.

Table 16 Possible Status Values (Continued)
Numeric
Value (for
Value Description
Sample
Code)
3 CYBS_S_ Critical: Yes
RECEIVE_
Result: An error occurred while waiting for or retrieving the reply.
ERROR
Keys in **ppReply:
_error_info
_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.
POST_
Result: The client received a reply or a fault, but an error occurred while
RECEIVE_
processing it.
ERROR
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
screens on the Business Center to verify that the request was processed, and
if so, whether it succeeded. Update your transaction database appropriately.
CRITICAL_
Result: The server returned a fault with _fault_code set to
SERVER_
CriticalServerError.
FAULT
Keys in **ppReply:
_error_info
_fault_document
_fault_code
_fault_string
_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 _fault_request_id.

Numeric
Value (for
Value Description
Sample
Code)
SERVER_
Result: The server returned a fault with _fault_code set to ServerError,
FAULT
indicating a problem with the CyberSource server.
Keys in **ppReply:
_error_info
_fault_document
_fault_code
_fault_string
OTHER_
Result: The server returned a fault with _fault_code set to a value other
FAULT
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 Creating and Using Security Keys (PDF |
HTML).
Note 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
Table 2, "Configuration Settings," for information about fixing the problem.

Numeric
Value (for
Value Description
Sample
Code)
HTTP_
Result: The server returned an HTTP status code other than 200 (OK) or 504
ERROR
(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,"
page 14.
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:

Loading the Configuration Settings

Next use cybs_load_config() to create a new CybsMap structure and load the
configuration settings from a 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:
Adding the Merchant ID

You next add the CyberSource 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:
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, "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" );
The example above shows only a partial list of the fields you must send. Refer to
"Requesting CyberSource Services," page 36, 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," page 32, 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," page 42 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 :
break;
// An error occurred while waiting for or retrieving the reply.
case CYBS_S_RECEIVE_ERROR :
// Critial 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.
// Look at _raw_reply in pReply for the raw reply.
break;
// CriticalServerError fault
case CYBS_S_CRITICAL_SERVER_FAULT :
// Critial error.
// 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 :
// See the sample code for information about reading fault details.
break;
// Other fault
case CYBS_S_OTHER_FAULT :
// Read the various fault details from pReply.
break;
// HTTP error
case CYBS_S_HTTP_ERROR :
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 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:
 ACCEPT if the request succeeded
 REJECT if one or more of the services in the request was declined
 REVIEW if you are using CyberSource Decision Manager and it flags the order for
review. See "Handling Decision Manager Reviews," page 44, for more
information.
 ERROR if there was a system error. See "Retrying When System Errors Occur,"
page 45, for more information.
 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 Credit Card Services User Guide for
CyberSource Essentials merchants or in the service developer guide for CyberSource
Advanced merchants.
CyberSource reserves 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 CyberSource 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, CyberSource recommends 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 Decision Manager Developer Guide Using the Simple Order API
(PDF | HTML) or the Decision Manager Developer Guide Using the SCMP Order API
(PDF | HTML).
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, CyberSource recommends 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.

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,"
page 14.

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

You next add the CyberSource 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.
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:
1.18">
<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”):
1.18">
<ccCaptureService run="true"/>
</requestMessage>

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.
1.18">
<billTo>
<firstName>Jane</firstName>
<lastName>Smith</lastName>
</billTo>
<item id="0">
<unitPrice>29.95</unitPrice>
</item>
<card>
<accountNumber>4111111111111111</accountNumber>
</card>
</requestMessage>
The example above shows only a partial list of the fields you must send. Refer to

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:

Next use cybs_load_config() to create a new CybsMap structure and load the
configuration settings from a 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:

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 );

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
Return Status Values," page 32, 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=ERROR, indicate to the customer that there was an error and to try
// again later.
reason = cybs_get( pReply, "reasonCode" );
} 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 ) {
case CYBS_S_PRE_SEND_ERROR :
break;
case CYBS_S_SEND_ERROR :

break;
case CYBS_S_RECEIVE_ERROR :
// Critial error.
break;
case CYBS_S_POST_RECEIVE_ERROR :
// Critical error.

break;
case CYBS_S_CRITICAL_SERVER_FAULT :
// Critial error.
case CYBS_S_SERVER_FAULT :
break;
// Other fault
case CYBS_S_OTHER_FAULT :

break;
// HTTP error
case CYBS_S_HTTP_ERROR :
break;
default :
// Unknown error
}
}


order in the reply.

the following:
 REVIEW if you use CyberSource Decision Manager and it flags the order for
information.
page 59, for more information.
Advanced merchants.

// 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") );
}
else if (reason == "204") {

printf(
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.


(PDF | HTML).


<businessRules>
<ignoreAVSResult>true</ignoreAVSResult>
</businessRules>



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/

 Production server URLs:
 Internet endpoint: https://ics2ws.ic3.com/commerce/1.x/

 Akamai endpoint: https://ics2wsa.ic3.com/commerce/1.x/

 India endpoint: https://ics2ws.in.ic3.com/commerce/1.x/

 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

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.

CHAPTER
.NET 4.0 or Later Client
3
 The .NET 4.0 or later client for the Simple Order API is supported on 32-bit and 64-
bit operating systems.
Choosing an API and Client
API Variation
With this client package, you can use any of the three variations of the Simple Order API:
 SOAP (Simple Object Access Protocol) 1.1, which provides an object-oriented
interface

Chapter 3 .NET 4.0 or Later Client
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," page 75.
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," page 98, 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," page 102 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() );
}
}
}
}


 Microsoft Windows 2000 or later
 .NET Framework 4.0 or later
 Microsoft Visual Studio 2010
identifiers.

Keys (PDF | HTML).
not compromised.


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

CyberSource recommends 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
To install the files individually:
Step 1 Download the latest zip file. The current version is cybersource-sdk-dotnet-1.0.0.zip.
Step 2 Extract the contents of the zip file to an appropriate location.
Step 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
Migrating from .NET Framework 1.x
To migrate from a .NET Framework 1.x client:
Step 1 Replace the old DLLs with the ones from this package.
Step 2 In your project, remove references to the previous CyberSource DLLs.
Step 3 Add a reference to CyberSource.Clients.dll.
Step 4 In your request code, make the following changes:
a Replace the referenced CyberSource namespaces with this one:
CyberSource.Clients

b 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 */
Step 5 Follow the instructions for migrating from .NET Framework 2.X.
Migrating from .NET Framework 2.x
To migrate from a .NET Framework 2.x client:
Step 1 Follow the installation instructions in "Installing the Client," page 66.
Step 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.
Step 3 In your project properties, set the target framework to .NET Framework 4.
Step 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.
Step 5 Remove references to System.Web.Services and remove the following namespace from
your code:
using System.Web.Services.Protocols
Step 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:
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 Name-Value Pairs," page 76.
 "Using XML," page 86.
 "Using SOAP," page 98.
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, CyberSource recommends that you use the following new settings
for this and future versions.
Table 17 Fields in the Settings File
Required/
Field Name Description
Optional
cybs.connectionLimit Maximum number of allowed concurrent connections between the Optional
client and CyberSource’s server. For more information on this field
and alternate ways to set the connection limits, see "Setting the
Connection Limit," page 108.
cybs.keysDirectory Directory that contains the pkcs12 security key file. For example: Required
c:\keys\
cybs.merchantID Your CyberSource merchant ID. You can override this value by Optional
providing the merchantID field in the request itself. The merchant ID
is case sensitive.

Table 17 Fields in the Settings File (Continued)
Required/
Optional
cybs. sendToProduction Flag that indicates whether the transactions for this merchant Required
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).
Note Make sure that if your merchant ID is configured to use the
test mode, you send requests to the test server.
cybs.keyFilename Name of the security key file name for the merchant in the format Optional
<security_key_filename>.p12.
cybs.serverURL Alternate server URL to use. For more information, see "Configuring Optional
Your Settings for Multiple Merchants," page 73. Give the complete
URL because it will be used exactly as you specify.
cybs.enableLog Flag directing the client to log transactions and errors. Use one of Optional
these values:
Therefore, CyberSource recommends 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).
 Never send email to CyberSource containing personal and
account information, such as customers' names, addresses, card
or check account numbers, and card verification numbers.
www.visa.com/cisp.
cybs.logDirectory Directory to which to write the log file. Note that the client will not Required if
create this directory for you; you must specify an existing directory. cybs.
The client includes a logs directory that you can use. Include the enableLog
path. For example: is true
c:\simapi-net-2.0.0\logs.
cybs.logFilename Name of the log file. The client uses cybs.log by default. Optional

Table 17 Fields in the Settings File (Continued)
Required/
Optional
cybs.logMaximumSize Maximum size in megabytes for the log file. The default value is 10. Optional
cybs.log.<yyyymmddThhmmssxxx> and a new log file is
started. The xxx indicates milliseconds.
cybs.timeout Length of time-out in seconds. The default is 130. Optional
cybs.proxyURL URL of a proxy server. For example: https:// Optional
proxy.example.com:4909
cybs.proxyUser User name for the proxy server. Optional
cybs.proxyPassword Password for the proxy server. Optional
To test applications:
Step 1 Decide which test application you want to run, such as SoapSample.exe.
Step 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.
Step 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.
Step 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\"/>.
Step 5 Edit other fields as necessary.
See Table 17, "Fields in the Settings File," for a complete list.
Step 6 Save and close the settings file.

Configuring Your Settings for Multiple Merchants

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.
Example 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
To run test applications:
Step 1 Open a Windows command-line shell.
Step 2 Change to the directory where the test application is located.
Step 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

configuration setting "cybs. sendToProduction," page 71.

After CyberSource confirms that your account is live, make sure that you update your
ics2ws.in.ic3.com in India) using your security key for the production environment.
configuration setting "cybs. sendToProduction," page 71.


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:

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.
Name-Value Pair Client
To update a name-value pair client:
Step 1 Load src\CyberSource.Clients.sln in Visual Studio 2010.
Step 2 In the Solution Explorer, locate the Service References folder.
Step 3 Right-click NVPWebReference and choose Configure Service Reference.
Step 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.
Step 5 Build the Release configuration.

Step 6 Save a copy of the original CyberSource.Clients.dll and then replace it with the
newly built CyberSource.Clients.dll.
SOAP Client
To update a SOAP client:
Step 1 Load src\CyberSource.Clients.sln in Visual Studio 2010.
Step 2 In the Solution Explorer, locate the Service References folder.
Step 3 Right-click SoapWebReference and choose Configure Service Reference.

Step 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.
Step 5 Build the Release configuration.
Step 6 Save a copy of the original CyberSource.Clients.dll and then replace it with the
newly built CyberSource.Clients.dll.
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.

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

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

Creating and Sending the Request

The example developed in the following sections shows basic code for requesting
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.ServiceMode1.Security;

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

You next optionally add your CyberSource 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.


You next indicate the service that you want to use by adding a field to the request. For
request.Add( "ccAuthService_run", "true" );
Requesting a Sale
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" );

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

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," page 81 describes the ProcessReply
// method.
ProcessReply( reply );
SaveOrderState();
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.
*/
}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


CyberSource. Do not show the reply information directly to consumers. Instead, present
an appropriate response that tells consumers the result.
order in the reply.
the following:
review. See "For CyberSource Advanced Merchants: Handling Decision Manager
Reviews," page 83, for more information.
page 85, for important information about handling retries in the case of system
errors.
Advanced merchants.

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" ) );
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.
(PDF | HTML).


authorizations anyway. You can set the businessRules_ignoreAVSResult field to
"true" in your combined authorization and capture request:
request.put( "businessRules_ignoreAVSResult", "true" );


error. In that case, CyberSource 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.
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," page 70, for more
information.

Using XML
This section explains how to request CyberSource services by using XML.



The XML client allows you to create an XML request document using any application, then
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.
The XML document in this example is incomplete. For complete examples, see
sample.xml in the client’s samples\bin directory.


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," page 75.
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.


Optionally, you can add the CyberSource merchant ID to the request:

1.17">
</requestMessage>
This value overrides any value that you set with the merchantID configuration setting. For
more information about the merchantID configuration setting, see Table 17, "Fields in the
Settings File," on page 70. The merchant ID is case sensitive.


1.15">
</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

1.17">
</requestMessage>


consumer’s credit card information.

1.15">
<billTo>
</billTo>
<item id="0">
</card>
</item>
<card>
</requestMessage>
The example above shows only a partial list of the fields you must send. Refer to "Related
Documents," page 14, 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#.

programs, see the source code in the client’s samples\src\xml directory.

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.


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();
// method.
SaveOrderState();
} 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() );
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.
*/
}

private static void SaveOrderState() {

/*
*/
}
you were unable to process the order. The sample code for the XML client shows you how
to provide feedback to the consumer.
may be able to resend the transaction. The sample code for the XML client shows you
how to do this.

order in the reply.

the following:
errors.
Advanced merchants.


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 );
}
}
}
}



private static string GetContent(
XmlNode replyMessage, XmlNamespaceManager nsmgr ) {
/*
*
* 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 );
// Success
case 100:
return( "\nRequest ID: " +
replyMessage.SelectSingleNode(
"cybs:requestID/text()", nsmgr ).Value );
case 101:
EnumerateValues( replyMessage.SelectNodes(
"cybs:missingField/text()", nsmgr ) ) );

case 102:
EnumerateValues( replyMessage.SelectNodes(
"cybs:invalidField/text()", nsmgr ) ) );
case 204:
default:
// For all other reason codes (for example, unrecognized reason codes, or
// codes that do not require special handling), return an empty string.
}
}
private static string EnumerateValues( XmlNodeList nodes ) {
foreach (XmlNode node in nodes) {
}
}


Manager Reviews
(PDF | HTML).


<businessRules>
</businessRules>


call your processor to determine if and why they are rejecting the transaction.

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," page 70, for more
information.

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


The example that is developed in the following sections shows basic code for requesting

programs, see the source code in the client’s samples\src\soap directory.

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.


using System;
using System.Net;
using System.Security.Cryptography;
using System.ServiceModel.Security;
using CyberSource.Clients.SoapWebReference;

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

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

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


Requesting a Sale
You can request multiple services by creating additional objects. For example, if you fulfill

request.ccCaptureService = new CCCaptureService();
request.ccCaptureService.run = "true";

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;

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();
// method.
SaveOrderState();
Console.WriteLine( sbe.ToString() );
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.
*/
}
private static void SaveOrderState() {
/*
*/
}

you were unable to process the order. The sample code for the SOAP client shows you
how to provide feedback to the consumer.
may be able to resend the transaction. The sample code for the SOAP client shows you
how to do this.

order in the reply.
the following:
errors.

Advanced merchants.

private static bool ProcessReply( ReplyMessage reply ) {

string template = GetTemplate( reply.decision.ToUpper() );
string content = GetContent( reply );
}

}

}
private static string GetContent( ReplyMessage reply ) {
/*
* The messages returned in this example are meant to demonstrate how to retrieve
*/

int reasonCode = int.Parse( reply.reasonCode );

// Success
case 100:
return( "\nRequest ID: " + reply.requestID );
case 101:
EnumerateValues( reply.missingField ) );
case 102:
EnumerateValues( reply.invalidField ) );
case 204:
default:
// For all other reason codes, such as unrecognized reason codes or codes
// that do not require special handling, return an empty string.
}
}
private static string EnumerateValues( string[] array ) {
foreach (string val in array) {
}
}


Manager Reviews
(PDF | HTML).


BusinessRules businessRules = new BusinessRules();
businessRules.ignoreAVSResult = "true";
request.businessRules = businessRules;


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:
call your processor to determine if and why the transaction was rejected.
because several common TSYS Acquiring Solutions processor responses can be
returned as system errors, and only TSYS Acquiring Solutions can address these errors.

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," page 70, 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's 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:
 Managing Connections in the .Net Framework Developer's Guide (http://

msdn2.microsoft.com/en-us/library/7af54za5.aspx).

Sample ASP.NET Code Using Visual Basic

The following sample files illustrate how to use the CyberSource 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"/>




<add key="cybs.enableLog" value="false"/>
<add key="cybs.logDirectory" value="C:\Program Files\CyberSource
Corporation\simapi-net-2.0-5.0.0\logs"/>






<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

CHAPTER
Java Client
4
 The Java client for the Simple Order API is supported on 64-bit operating systems.
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,"
page 121.

Chapter 4 Java Client
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, CyberSource

recommends 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," page 115). "Using Name-Value Pairs," page 124, 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" );

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" );
// Add optional fields here according to your business needs.

// For information about processing the reply,
// see "Using the Decision and Reason Code Fields," page 129.
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 );
}
}
}
}


 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

Keys (PDF | HTML).
not compromised.


The Java SDK is available to install from GitHub:
https://github.com/CyberSource/cybersource-sdk-java
Using a Package Manager
Maven
CyberSource recommends using the Maven Package Manager to install the Java SDK.
To install the JAVA SDK:
Step 1 Add the dependency to your application pom.xml.
<dependency>
<groupId>com.cybersource</groupId>
<artifactId>cybersource-sdk-java</artifactId>
<version>6.0.1</version>
</dependency>
Step 2 Run mvn install.
Gradle
Add the dependency to your build.gradle.
dependencies {
compile 'com.cybersource:cybersource-sdk-java:6.0.1'
}

Installing Individual Files

The Java SDK jar file is available to download independently from GitHub:
http://search.maven.org/remotecontent?filepath=com/cybersource/cybersource-sdk-
java/6.0.1/cybersource-sdk-java-6.0.1.jar
To install the files individually:
Step 1 Download the latest jar file. The current version is cybersource-sdk-java-6.0.1.jar.
Step 2 Save the jar file to an appropriate location.
Step 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. Table 18, "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," page 143.
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.
Table 18 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, CyberSource recommends 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.

Table 18 Configuration Properties (Continued)
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. Changes in each version are described in the Simple Order
API Release Notes. Do not set this property to the current version of the client. See
"Client Versions," page 115, 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," page 143. 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," page 143.
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
Important Logging can cause very large log files to accumulate. Therefore,
CyberSource recommends 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).
 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.

Table 18 Configuration Properties (Continued)
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.<yyyymmddThhmmssxxx> and a new log file is started. The xxx
indicates milliseconds.
timeout Important 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," page 120).
Running the SDK Integration Tests
To run the SDK integration tests:
Step 1 Configure your merchant credentials in test_cybs.properties (<main directory>/src/test/

resources).
Step 2 Run mvn failsafe:integration-test from the main directory.

Running the Samples
To run the samples:
Step 1 Configure your merchant credentials in cybs.properties (<main directory>/samples/nvp or

xml).
Step 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,"
page 121.

sendToProduction property in Table 18, "Configuration Properties".
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.


After CyberSource confirms that your account is live, make sure that you update your
ics2ws.in.ic3.com in India) using your security keys for the production environment.
information about sending transactions to the production server. see the description of the
configuration property "sendToProduction," page 121.
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

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

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
 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," page 14.
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

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.

Add the following import statements:
import java.util.*;
Depending on your application, you might need to add more import statements.
Loading the Configuration File

Load the configuration file:
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.


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

Indicate the service that you want to use by adding a field to the request, such as a credit
card authorization:
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:

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( "ccCaptureService_run", "true" );
Example For Merchants Using CyberSource Advanced 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.


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" );
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," page 129 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)
{
}
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," page 129,
shows how to provide feedback to the customer.

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.
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:
 ACCEPT if the request succeeded.
 REJECT if one or more of the services in the request was declined.
 REVIEW (Advanced package only) if you use Decision Manager, and the order is
marked for review. For more information, see "Handling Decision Manager
Reviews (CyberSource Advanced Services Only)," page 131.
 ERROR if a system error occurred. For more information, see "Handling System
Errors," page 131.
Advanced merchants

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 ) {

if ("ACCEPT".equalsIgnoreCase( decision )) {
return( "Your order was approved.{0}" );
}
if ("REJECT".equalsIgnoreCase( decision )) {
}
// ERROR
return( "Your order cannot be completed at this time.{0}" +
}
private static String getContent( HashMap reply )
/*
* The strings returned in this sample are meant to demonstrate how to retrieve
*/
int reasonCode =
Integer.parseInt( (String) reply.get( "reasonCode" ) );

// Success
case 100:
return( "\nRequest ID: " + (String) reply.get( "requestID" );
case 101:
return( "\nThe following required field(s) are missing:\n" +
enumerateValues( reply, "missingField" ) );

case 102:
return( "\nThe following field(s) are invalid:\n" +
enumerateValues( reply, "invalidField" ) );
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:
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)
(PDF | HTML).
Handling System Errors
You must design your transaction management system to correctly handle CyberSource
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," page 128.
The error may indicate a valid CyberSource system error or a payment processor rejection
because of invalid data.

Offline Transactions
CyberSource recommends 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 CyberSource system error. In this case, CyberSource
recommends 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.

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
 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," page 14.
To understand how to request CyberSource services, CyberSource recommends 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.
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.

Start with the XML declaration and the root element:

<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


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:

1.18">
</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.
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:

1.18">
</requestMessage>
Example Only 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>
</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.


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.

1.18">
<billTo>
</billTo>
<item id="0">
</item>
<card>
</card>
</requestMessage>
Sending Requests
Once you have created an XML request document, you can use Java to send the request
to CyberSource.

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

Loading the Configuration File

Load the configuration file:
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," page 129 illustrates how you might
// design a ProcessReply() method to handle the reply.
processReply( reply );
}
catch (FaultException e)
{
e.printStackTrace();
}
catch (ClientException e)
{
e.getInnerException().printStackTrace();
}
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,"
page 129, shows how to provide feedback to the customer.

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

 ACCEPT if the request succeeded.
 REJECT if one or more of the services in the request was declined.
 REVIEW (Advanced package only) if you use Decision Manager, and the order is
marked for review. For more information, see "Handling Decision Manager
Reviews (CyberSource Advanced Merchants)," page 141.
 ERROR if a system error occurred. For more information, see "Handling System
Errors," page 141.
Advanced merchants.


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 )

// 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 ){
if ("ACCEPT".equalsIgnoreCase( decision )) {
return( "Your order was approved.{0}" );
}
if ("REJECT".equalsIgnoreCase( decision )) {
}
// ERROR, or unknown decision

return( "Your order cannot be completed at this time.{0}" +
}

private static String getContent(

XPathAPI xp, Node ctxNode, Node nsNode )
throws XMLClientException {
/*
* The strings returned in this sample are meant to demonstrate how to retrieve
*/
int reasonCode = Integer.parseInt(
getText( xp, ctxNode, "cybs:reasonCode", nsNode ) );
// Success
case 100:
return ( "\nRequest ID: " +
getText( xp, ctxNode, "cybs:requestID", nsNode ) );

case 101:
return( "\nThe following required field(s) are missing:\n" +
enumerateValues( xp, ctxNode, "cybs:missingField", nsNode ) );
case 102:
return( "\nThe following field(s) are invalid:\n" +
enumerateValues( xp, ctxNode, "cybs:invalidField", nsNode ) );
case 204:
// Add additional reason codes here that you must handle specifically.
default:
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)
(PDF | HTML).
Handling System Errors

You must design your transaction management system to correctly handle CyberSource
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," page 138.
The error may indicate a valid CyberSource system error or a payment processor rejection
because of invalid data.

Offline Transactions
CyberSource recommends 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, CyberSource
recommends 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.
CyberSource services with the Simple Order API 1.18:





 Namespace URI:
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

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:
enableLog=false
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.
Step 1 Download the Oracle JSSE from http://java.sun.com/products/jsse/.
Step 2 Extract the following files from the Oracle JSSE package:
jcert.jar
jnet.jar
jsse.jar

Step 3 Copy the jar files into your Java installation's jre/lib/ext directory.
Step 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>
Step 5 Add the following line where NN is equal to N + 1:

security.provider.NN=com.sun.net.ssl.internal.ssl.Provider
Step 6 Save and close the file.
IBM Java SDK

This procedure is only a guideline. For the latest information, consult the IBMJSSE
documentation.
Step 1 Download the IBMJSSE from IBM’s web site or obtain it from your IBM development kit
CDs.
Step 2 Extract the ibmjsse.jar file.
Step 3 Obtain the ibmpkcs.jar file.

The file should be included in the IBM development kit.
Step 4 Copy both jar files into your Java installation's jre/lib/ext directory.
Step 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>
Step 6 Add the following line where NN is equal to N + 1:

security.provider.NN=com.ibm.jsse.JSSEProvider
Step 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
Step 1 At a command prompt, go to the main client directory where the entrust_ssl_ca.cer
file is located.
Step 2 Type the following text without line breaks:

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.
Step 3 When prompted, enter the keystore password.

The default password is usually changeit. You have successfully imported the certificate.

CHAPTER
PHP Client
5
 This chapter 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.
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 CyberSource 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

Chapter 5 PHP Client
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 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. See Secure Acceptance Hosted
Checkout Integration Guide and Secure Acceptance Checkout API Integration Guide.
API Variation
With this client package, you can use either of these variations of the Simple Order API:
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," page 149). "Using Name-Value Pairs," page 168, 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";
$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';
// 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," page 171.

Sample Scripts
The client contains two sample scripts, one for using name-value pairs and one for using
XML. See "Testing the Client," page 158, 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.
Table 19 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 used in the checkout pages.

footer.php
store_ Header used in the checkout pages.
header.php
To use the sample PHP pages:
Step 1 If you have files in your web server’s root directory that have the same name as the files
listed in Table 19, "Files in sampleStore Directory," on page 150, 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.
Step 2 Copy all of the files in the <installation directory>/samples/store directory into
your web server’s root directory.

Step 3 Modify the cybs.ini file as appropriate. For more information, see "Configuring Client
Settings," page 156.
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.
Step 4 Open the checkout.php file in a text editor and locate the cybs_load_config()
function.
Step 5 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' );
not this line:
Step 6 Restart your web server.

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.
Step 7 Open a web browser and type the following URL:

http://<your web server name or IP address>/<virtual directory if
applicable>/checkout.php

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
For Windows
 Windows XP, 2000, or newer
 Minimum PHP version 4.2.1
The SDK supports UTF-8 encoding.
identifiers.


Keys (PDF | HTML).
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," page 157.
not compromised.

This section describes the installation steps for Linux and Windows environments.
To install the client on Linux:
Step 2 Download the latest client package. You can save the file in any directory.
Step 3 Unzip and untar the package.

This creates a directory called simapi-php-n.n.n, where n.n.n is the client version.
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.

Step 4 Copy the phpN_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.
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:
a Create an extension directory (outside of the client installation directory).
b Set "extension_dir" to that directory.
c Copy the phpN_cybersource.so file to that directory location.
Step 5 If you are using an Oracle database, go to "Special Installation Instructions for Oracle
Users," page 161, and follow the instructions.
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)
Step 6 Save the php.ini file.
Step 7 Modify the environment variable LD_LIBRARY_PATH to include the lib directory of the
CyberSource client. For example:
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.
Step 8 Configure the client. See "Configuring Client Settings," page 156, below.

To install the client on Windows:
Step 2 Download the latest client package. You can save the file in any directory.
Step 3 Unzip the package.

This creates a directory called simapi-php-n.n.n, where n.n.n is the client version.
Step 4 Copy the phpN_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.
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:
a Create an extension directory (outside of the client installation directory).
b Set "extension_dir" to that directory.
c Copy the phpN_cybersource.dll file to that directory location.
Step 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:
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)
Step 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.
Step 8 Configure the client. See "Configuring Client Settings," page 156, below.

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," page 162). 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.
can use different configuration settings depending on the merchant ID. See "Configuring
Your Settings for Multiple Merchant IDs," page 191, for more information.
Table 20 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.
Note 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).
Note 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.
Note 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. For information about what has changed in each
version, see the Simple Order API Release Notes.
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," page 190, for more information. Give the complete URL
because it will be used exactly as you specify here.

Setting Description
namespaceURI Alternate namespace URI to use. See "Using Alternate Server
Configuration Settings," page 190, 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:
Therefore, CyberSource recommends 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).
 Never send email to CyberSource containing personal and account
information, such as customers' names, addresses, card or check
account numbers, and card verification numbers.
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.
logMaximumSize Maximum size in megabytes for the log file. The default value is 10.
cybs.log.<yyyymmddThhmmssxxx> 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.

Setting Description
proxyServer Proxy server to use. Allowable formats include:
 <http://>server<:port>
 <http://>IP address<:port>
The http:// and port are optional.

Note 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.
To test the client:
Step 1 Go to the <installation directory>/samples/nvp directory.
Step 2 Run the test authCaptureSample.php script by typing:

php authCaptureSample.php
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


To troubleshoot client test failures:
Step 1 Verify that your cybs.ini settings are correct.
Step 3 If the test still fails, look at the error message and determine the return status value (a
numeric value from -1 to 8).
Step 4 See the descriptions of the status values in "Possible Return Status Values," page 164,
and follow any instructions given there for the error you received.
Step 6 If the test still fails, contact Customer Support.
To run the XML sample:
Step 1 Go to the <installation directory>/sample/xml directory.
Step 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).
Step 3 Run the test authSample.php script by typing:

php authSample.php
 If the test is successful, you see a decision of ACCEPT for both the credit card
 If the test is not successful, you see a different decision value or an error message.
See "To troubleshoot client test failures:," page 159, to troubleshoot the error.
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," page 168, if you plan to use name-value pairs, or "Using XML," page 178, 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

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

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.


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
To load Oracle extensions dynamically after the CyberSource

extension:
Step 1 At a command prompt, go to your PHP directory.
Step 2 Type the following:

make clean
Step 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:
./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
Step 4 Type the following:

make
make install

Step 5 In the “Dynamic Extensions” section of the php.ini file, add the CyberSource extension
before the Oracle extensions:
extension=phpN_cybersource.so (where N represents the version of PHP: 4, 5,
503, or 512)
extension = oracle.so
extension = oci8.so
Step 7 Continue with the original installation instructions (see Step 7 in "Installing the Client,"
page 153).
PHP API for the Client
Summary of Functions
The client includes these functions:
 cybs_load_config()
 cybs_run_transaction()
cybs_load_config()
Table 21 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()
Table 22 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:  The individual name-value pairs in the request (for name-
Array containing one of these: value pair users)
 A single key called CYBS_SK_XML_DOCUMENT whose
value is the XML document representing the request (for
XML users)
reply: Note You must create this array before you call cybs_run_
Array containing one of these: 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.
Table 23, "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.
Table 23 Possible Status Values
Numeric
Value
Value Description
(for Sample
Scripts)
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.
-1 CYBS_S_PHP_ Critical: No
PARAM_ERROR
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_ Critical: No
ERROR
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.

Numeric
Value
Value Description
(for Sample
Scripts)
2 CYBS_S_SEND_ Critical: No
ERROR
Result: An error occurred while sending the request.
Note 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," page 157.
3 CYBS_S_RECEIVE_ Critical: Yes
ERROR
Result: An error occurred while waiting for or retrieving the reply.
$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_ Critical: Yes
RECEIVE_ERROR
Result: The client received a reply or a fault, but an error occurred
while processing it.
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.

Numeric
Value
Value Description
(for Sample
Scripts)
5 CYBS_S_CRITICAL_ Critical: Yes
SERVER_FAULT
Result: The server returned a fault with $reply[CYBS_SK_
FAULT_CODE] set to CriticalServerError.
$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_ Critical: No
FAULT
FAULT_CODE] set to ServerError, indicating a problem with the
CyberSource server.

Numeric
Value
Value Description
(for Sample
Scripts)
7 CYBS_S_OTHER_ Critical: No
FAULT
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.
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.
Note 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,"
page 156.
8 CYBS_S_HTTP_ Critical: No
ERROR
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.
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.

Table 24 summarizes which reply information you receive for each status value.
Table 24 Reply Information Available for Each Status Value

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

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," page 14.

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.
The example that is developed in the following sections shows the basic PHP code for

First load the configuration settings from a file:
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();

You next add the CyberSource 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
$request['ccAuthService_run'] = 'true';
Requesting a Sale
if you fulfill the order immediately, you can request credit card authorization and capture
$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';
Sending the Request

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


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
Return Status Values," page 164, 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=ERROR, indicate to the customer that an error occurred and to try
// again later.
// $strContent = getReplyContent( $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:
break;

case CYBS_S_PRE_SEND_ERROR:

break;

case CYBS_S_SEND_ERROR:
break;
case CYBS_S_RECEIVE_ERROR:
// Critial error.
// Tell customer the order cannot be completed and to try again later.
break;

case CYBS_S_POST_RECEIVE_ERROR:
// Critical error.
// Look at CYBS_SK_RAW_REPLY in $reply for the raw reply.
break;
case CYBS_S_CRITICAL_SERVER_FAULT:
// Critial error.
// Read the various fault details from the $reply.
break;
case CYBS_S_SERVER_FAULT:
break;
// Other fault
case CYBS_S_OTHER_FAULT:
break;

// HTTP error
Case CYBS_S_HTTP_ERROR:
// Tell customer the order cannot be completed and to try again later.
break;
}
}

order in the reply.
the following:
 REVIEW if you are a CyberSource Advanced merchant using CyberSource
Decision Manager and it flags the order for review. See "Handling Decision
Manager Reviews," page 175, for more information.
page 177, for important information about handling system errors.

Advanced merchants.
The following is an example:
// 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;
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 ( '' );
}
}


(PDF | HTML).


$request['businessRules_ignoreAVSResult'] = 'true';



Using XML
This section describes how to request CyberSource services using XML.

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," page 14.
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.


The client allows you to create an XML request document using any application, then
transactions. To view the schema, go to
and look at the XSD file for the version of the Simple Order API you are using.

The example developed in the following sections shows a basic XML document for
The XML document in this example is incomplete. For a complete example, see the
auth.xml document in the samples/xml directory.


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.


You next add the CyberSource 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.

1.18">
</requestMessage>


1.18">
</requestMessage>
Requesting a Sale
You can request multiple services by adding additional elements. For example, if you fulfill

1.18">
</requestMessage>


customer’s credit card information.

1.18">
<billTo>
</billTo>
<item id="0">
</item>
<card>
</card>
</requestMessage>
Sending the Request

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

First load the configuration settings from a 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.

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();


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
Return Status Values," page 164, 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," page 173 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:
break;

case CYBS_S_PRE_SEND_ERROR:
break;
case CYBS_S_SEND_ERROR:
break;
// An error occurred while waiting for or retrieving

// the reply.
case CYBS_S_RECEIVE_ERROR:
// Critial error.
break;
// An error occurred after receiving and during processing

// of the reply.
case CYBS_S_POST_RECEIVE_ERROR:
// Critical error.
break;
case CYBS_S_CRITICAL_SERVER_FAULT:
// Critial error.
break;
case CYBS_S_SERVER_FAULT:
break;

// Other fault
case CYBS_S_OTHER_FAULT:
break;
// HTTP error
Case CYBS_S_HTTP_ERROR:
break;
}
}

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 following:
information.

page 189 for important information about handling system errors.
Advanced merchants.
The following is an example:
// 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;
case '204':
return( sprintf(
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 ( '' );
}
}

(PDF | HTML).


<businessRules>
</businessRules>



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.
CyberSource services using the Simple Order API version 1.18:





 Namespace URI:
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

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:
enableLog=false

APPENDIX
Using the Client Application
Fields
A
This appendix 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.
Table 25 Client Application Fields
Data Type
and Length
clientApplication Application or integration that uses the String (50)
client: for example: ShoppingCart
Pro or Web Commerce Server. Do
not include a version number.
clientApplicationVersion Version of the application or integration, String (50)
for example: 5.0 or 1.7.3.
clientApplicationUser User of the application or integration, for String (30)
example: jdoe.
If you use these fields in your request, you can view their values in the Transaction Search

Client SDK So API

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

Client SDK So API

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Client SDK So API

Uploaded by

Copyright:

Available Formats

Title Page

CyberSource Simple Order API Client

Restricted Rights Legends

Revision: July 2020

Recent Revisions to This Document 11

About This Guide 12

Chapter 2 C/C++ Client 16

Simple Order API Client Developer Guide | 3

Simple Order API Client Developer Guide | 4

Adding Service-Specific Fields to the Request 49

Chapter 3 .NET 4.0 or Later Client 62

Simple Order API Client Developer Guide | 5

Simple Order API Client Developer Guide | 6

Requesting a Sale 100

Chapter 4 Java Client 114

Simple Order API Client Developer Guide | 7

Interpreting Replies 128

Chapter 5 PHP Client 147

Simple Order API Client Developer Guide | 8

Testing the Client 158

Simple Order API Client Developer Guide | 9

Handling Decision Manager Reviews 187

Appendix A Using the Client Application Fields 192

Simple Order API Client Developer Guide | 10

Simple Order API Client Developer Guide | 11

Simple Order API Client Developer Guide | 12

Note, Important, and Warning Statements

A Note contains helpful suggestions or references to material not contained in

An Important statement contains information essential to successfully

A Warning contains information or instructions, which, if not heeded, can result

Text and Command Conventions

Simple Order API Client Developer Guide | 13

Client Package Documentation

CyberSource Services Documentation

In contrast, CyberSource services documentation listed in Table 1 contains information

Each type of CyberSource service has associated documentation:

Table 1 CyberSource Services Documentation

Type of Service Available Documentation

Simple Order API Client Developer Guide | 14

The Simple Order API is a good choice for businesses who:

Simple Order API Client Developer Guide | 15

Choosing Your API and Client

For transactions in India, go to:

Simple Order API Client Developer Guide | 16

 Name-value pairs: See authCaptureSample.c in <installation

For the XML sample code, see authSample.c in <installation directory>/

Basic C/C++ Page Example

// Load the configuration settings

const char CYBS_CONFIG_INI_FILE[] = "../cybs.ini";

// Set up the request by creating an empty CybsMap and add fields to it

// We want to do credit card authorization in this example

cybs_add( pRequest, "ccAuthService_run", "true" );

Simple Order API Client Developer Guide | 17

// Add required fields

cybs_add( pRequest, "merchantID", "infodev" );

// This example has two items

cybs_add( pRequest, "item_0_unitPrice", "12.34" );

Syntax CybsMap cybs_load_config( const char szFilename )

Syntax void cybs_remove( CybsMap pRequest, const char szName )

Syntax const char cybs_get( CybsMap pMap, const char *szName )

Syntax char cybs_create_map_string( CybsMap pMap )