Electronic_Payment_Integration_Developer_s_Reference_Guide

PeopleSoft Developer’s Reference Guide
Campus Solutions 9.0 Electronic Payment

Integration
Developer's Reference Guide
Authors: Brian Hunnicut, Cindy Maladaga
November 2009
Electronic Payment Integration Developer’s Reference Guide 11/19/2009
Copyright © 2009, Oracle. All rights reserved.
The information contained in this document is proprietary and confidential to Oracle.
No part of this document may be reproduced or transmitted in any form or by any

means, electronic or mechanical, including photocopying and recording, for any
purpose without the express written permission of Oracle.
This document is provided for information purposes only and the contents hereof are
subject to change without notice. This document is not warranted to be error-free, nor
subject to any other warranties or conditions, whether expressed orally or implied in
law, including implied warranties and conditions of merchantability or fitness for a
particular purpose. We specifically disclaim any liability with respect to this document
and no contractual obligations are formed either directly or indirectly by this document.
This document may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation

and/or its affiliates. Other names may be trademarks of their respective owners.
© Copyright Oracle Corporation 2009. All rights reserved. 2

Table of Contents
TABLE OF CONTENTS ................................................................................................................................................ 3
INTRODUCTION .......................................................................................................................................................... 5
Structure of this Developer’s Reference Guide ............................................................................................................. 5
Related Materials .......................................................................................................................................................... 5
ELECTRONIC PAYMENT OVERVIEW ........................................................................................................................ 7

Traditional vs. Hosted Payment Models ........................................................................................................................ 7
Traditional Model.............................................................................................................................................. 8
Hosted Model ................................................................................................................................................... 8
ARCHITECTURE OF THE EPAYMENT API ................................................................................................................ 9

Process Flow Diagram ..................................................................................................................................... 9
Process Flow Narrative .................................................................................................................................... 9
Components of the ePayment API ................................................................................................................... 10
ARCHITECTURE OF THE HOSTED PAYMENT FRAMEWORK .............................................................................. 11

Third Party Integration Requirements for Hosted Payment ........................................................................................ 15
IMPLEMENTING THE TRADITIONAL PAYMENT MODEL ....................................................................................... 16

Traditional Model Using Business Interlinks ............................................................................................................... 16
Step 1: Pre-Requisite Setup.......................................................................................................................... 16
Verify Business Interlinks Setup ...................................................................................................................... 16
Step 2: Create the Payment Merchant .......................................................................................................... 17
Step 3: Test the Integration ........................................................................................................................... 20
Traditional Model Using Integration Broker ................................................................................................................. 21
Map Integration Broker Message Structure to your Payment Provider’s Message Structure .......................... 21
Develop Transformations using Application Engine ........................................................................................ 21
Step 2: Create Integration Broker-Related Objects ...................................................................................... 22
Identify your Default Local Node ...................................................................................................................... 22
Create the External Integration Broker Node for your Payment Provider ........................................................ 23
Update the Existing Service Operation and Create the Required Routing ...................................................... 23
IMPLEMENTING THE HOSTED PAYMENT MODEL ................................................................................................ 27

Hosted Model Setup and Configuration for the ePayment API ................................................................................... 27
Map Integration Broker Message Structure to your Payment Provider’s Message Structure .......................... 27
Develop Transformations using Application Engine ........................................................................................ 28
Step 2: Create Integration Broker Related Objects ....................................................................................... 28
Identify your Default Local Node ...................................................................................................................... 29
Create the External Integration Broker Node for your Payment Provider ........................................................ 29
Update the Existing Service Operation and Create the Required Routing ...................................................... 29
© Copyright PeopleSoft Corporation 2009. All rights reserved. 3


Hosted Model Setup and Configuration for the Hosted Payment Framework ............................................................ 33
Step 2: Selecting a Hosted Payment Adapter ............................................................................................... 33
Step 3: Review the Payment Merchant Setup .............................................................................................. 34
Step 4: Configuring the Hosted Payment Adapters ...................................................................................... 34
Provide security for Hosted Payment iScripts .................................................................................................. 34
Create Third Party URL Definition .................................................................................................................... 36
Create an HTML Definition ............................................................................................................................... 37
Configuring the Hosted Payment Adapter Settings ......................................................................................... 38
APPENDIX .................................................................................................................................................................. 41
Appendix A: Request Message Structure and Properties .......................................................................................... 41
Appendix B: Response Message Structure and Properties ....................................................................................... 52
Appendix C: Creating a Transformation Program using Application Engine (Request) ............................................ 61
Appendix D: Creating a Transformation Program using Application Engine (Response) .......................................... 63
Appendix E: Creating an Integration Broker Node for Your Payment Provider .......................................................... 65
Appendix F: Updating the Existing Service Operation and Creating the Required Routing....................................... 68
Appendix G: Transaction Class ................................................................................................................................. 72
Appendix H: Payment Manager Class ....................................................................................................................... 83
Appendix I: Adapter Registry...................................................................................................................................... 84
Appendix J: Payment Merchant ................................................................................................................................. 86
Appendix K: Adapters for the ePayment API ............................................................................................................. 90
Appendix L: Business Interlink Adapter Mappings ..................................................................................................... 93
Appendix M: Integration Broker Adapter Mappings ................................................................................................... 96
Appendix N: Testing the ePayment API ................................................................................................................... 103
Appendix O: ePayment Return Codes and Associated Messages .......................................................................... 108
Appendix Z: Code Samples ..................................................................................................................................... 111
Request Sample 1: Request Transformation PeopleCode .......................................................................... 111
Request Sample 2: Request Transformation PeopleCode .......................................................................... 120
Request Sample 3: Request Transformation PeopleCode (Hosted Payment Transactions Only) .............. 126
Response Sample 1: Response Transformation PeopleCode ................................................................... 130
Response Sample 2: Response Transformation PeopleCode ................................................................... 139
Response Sample 3: Response Transformation PeopleCode (Hosted Payment Transactions Only) ...... 147

Introduction
This Developer‟s Reference Guide is a practical guide for technical users, installers, system administrators, and programmers
who implement, maintain, or develop applications for your PeopleSoft Campus Solutions system. In this Developer‟s Guide we
will document how to develop and implement traditional and hosted payment integrations to payment providers.
STRUCTURE OF THIS DEVELOPER’S REFERENCE GUIDE

This Developer‟s Reference Guide is intended to be the first place for implementers to look for technical details on integrating
Campus Solutions with payment providers for purposes of transmitting payment transactions and for hosted payment services.
The document also provides a brief overview and architecture of the feature. Having insight into the feature‟s architecture will
ensure more efficient and defect-free implementations and customizations.
PeopleSoft updates this document as needed so that it reflects the most current feedback we receive from our customers,
partners, and support organization. Therefore, the structure, headings, content, and length of this document are likely to vary
with each posted version. To see if the document has been updated since you last downloaded it, compare the date of your
version to the date of the version posted on My Oracle Support.
RELATED MATERIALS
This document is not intended to be a general introduction to environment tuning and we assume that the targeted readers are
experienced IT professionals with a good understanding of PeopleSoft‟s Internet Architecture and related Integration
Technologies. To take full advantage of the information covered in this document, we recommend that the reader have a basic
understanding of Internet Architecture, web services, and how to use PeopleSoft Application suite.
Many of the fundamental concepts related to PIA and Integration Broker are discussed in the following PeopleSoft
PeopleBooks:
 Enterprise PeopleTools 8.49 PeopleBook: Internet Technology
This PeopleBook provides an understanding of PeopleTools Internet technology.
Refer to http://download.oracle.com/docs/cd/E13292_01/pt849pbr0/eng/psbooks/tprt/book.htm
 Enterprise PeopleTools 8.49 PeopleBook: PeopleSoft Integration Broker
This PeopleBook describes the process for using PeopleSoft Integration Broker to develop and administer web service
based integrations.
Refer to http://download.oracle.com/docs/cd/E13292_01/pt849pbr0/eng/psbooks/tibr/book.htm
 Enterprise PeopleTools 8.49 PeopleBook: PeopleCode API Reference (Internet Script Classes)
This PeopleBook chapter describes how Internet Script Classes (iScript) work in your application, how to create an
iScript, and the Internet Script classes that you use in your PeopleCode.
Refer to http://download.oracle.com/docs/cd/E13292_01/pt849pbr0/eng/psbooks/tpcr/book.htm
 Enterprise PeopleTools 8.49 PeopleBook: System and Server Administration (specifically the sections relating to
Importation of Keys and Certificates into Keystores)
This PeopleBook describes how to implement SSL keys and certificates in your web server.
© Copyright PeopleSoft Corporation 2009. All rights reserved. 5

Refer to http://download.oracle.com/docs/cd/E13292_01/pt849pbr0/eng/psbooks/tsvt/book.htm
It is also recommended that you read any documentation provided by your payment provider or prospective payment provider
concerning their integration requirements, transactional formats, and related integration technologies.
Warning: This Developer‟s Reference Guide has not been submitted for any formal testing process and has not undergone
rigorous review. The material here is published as is. Oracle assumes no responsibility for its accuracy or completeness. The
use of this information or the implementation of any of these techniques is a customer responsibility and depends upon the
customer's ability to evaluate and integrate these techniques into their operational environments.

Electronic Payment Overview
Campus Solutions has historically integrated to payment providers using only a Business Interlink-based integration
(CREDITCARD_TRANSACTION and ECHECK_TRANSACTION). Due to our need to expand our functional offerings, we
have developed a new ePayment integration interface (called the ePayment API) and a new hosted payment framework. The
ePayment API will provide support for sending traditional ePayment transactions (Authorize, Bill/Capture, Credit, eCheck
Payments, etc.) and new hosted payment transactions (Get Token, Authorize, and Credit) to external third party payment
processors. The Hosted Payment framework allows transactions to be captured and key data stored externally to the Campus
Solutions system.
TRADITIONAL VS. HOSTED PAYMENT MODELS

The illustration below is intended to highlight the differences between the Traditional vs. Hosted Payment models.

Traditional Model
The traditional payment model above depicts a standard transaction originating in Campus Solutions by the student and being
interfaced to the payment provider. Note that the collection, transmission, and storage of sensitive payment data are all
performed within the school‟s or institution‟s window of responsibility. In previous releases, the integration to the payment
provider using the traditional model occurred via the use of Business Interlinks. Supported transactions included credit card
authorize, credit card authorize and bill (capture), credit card bill (capture), credit card credit, eCheck payment, and eCheck
credit. Now, with the release of the ePayment update in Campus Solutions release 9.0, transactions will be submitted via the
new ePayment API. The existing ePayment transactions will continue to be supported by way of the new ePayment API.
Support for new hosted payment transactions has been added (Get Ticket, Authorize, and Perform Credit).
Hosted Model
The hosted model above depicts a hosted transaction originating in Campus Solutions by the student. Note that the student is
transferred to a payment provider‟s hosted site to enter the sensitive payment-related data. With the hosted model, the school or
institution is no longer responsible for the collection, transmission, and storage of sensitive payment data.

Architecture of the ePayment API
The new ePayment API is an application class-based interface that uses an adapter construct to insulate the application code
from the specifics of the underlying integration technology and the payment provider‟s processing requirements. Adapters that
work with Business Interlinks as well as Integration Broker have been delivered. The sections “Implementing the Traditional
Payment Model” and “Implementing the Hosted Payment Model” will document how to build and configure Traditional and
Hosted integrations with a third party payment provider using the Campus Solutions-delivered adapters.
Process Flow Diagram
Process Flow Narrative
1. The application code (Cashiering, Self-Service Make a Payment, Miscellaneous Purchases, etc…) instantiates the
Payment Manager and Transaction application classes. Once instantiated, the application code populates the request
section of the Transaction application class with details of the ePayment transaction.
2. The application code then will use the Payment Manager application class to process the electronic payment
transaction. Data will be passed in and out of the Payment Manager class using the Transaction application class.
3. The Payment Manager application class operates as the transaction controller. It will take the data from the
Transaction class and use it to retrieve Payment Merchant setup data. The Payment Manager uses this data to set the
third party merchant ID property on the transaction and to determine the appropriate ePayment adapter needed to
execute the transaction.
4. The Payment Manager will instantiate the appropriate ePayment adapter as documented in the Payment Manager
setup. Once the proper adapter has been instantiated by the Payment Manager, the transaction is off-loaded to the
adapter for processing.

5. The ePayment adapter will validate the transaction and use the Payment Merchant setup data to set transactional-
related defaults (such as AVS, Risk Thresholds, and ACH Class).
6. Once the transaction values have been validated and defaults have been set, the ePayment adapter will marshal the
transaction data into the appropriate underlying integration technology for interfacing to the payment provider.
7. The underlying integration technology (Business Interlink or Integration Broker) will pass the transaction to the
payment provider for processing.
8. The payment provider then processes the transaction and returns a response back through the underlying integration
technology.
9. The ePayment adapter then interprets the response information returned from the payment provider and populates the
transaction response section of the Transaction class.
10. The ePayment adapter returns control back to the Payment Manager.
11. The Payment Manager then completes the transaction by passing control and the processed transaction back to the
calling application code.
12. The application code will then review the transaction results and message appropriately to the user.
Components of the ePayment API
 Transaction class (see “Appendix G: Transaction Class” for more information)
 Payment Manager class (see “Appendix H: Payment Manager Class” for more information)
 Setup-related data
o Adapter Registry (see “Appendix I: Adapter Registry” for more information)
o Payment Merchant (see “Appendix J: Payment Merchant” for more information)
 ePayment Adapters (see “Appendix K: Adapters for the ePayment API” for more information)
 Integration Technologies (Business Interlinks and Integration Broker)

Architecture of the Hosted Payment Framework
The new Hosted Payment framework facilitates the transition between Campus Solutions and a third party hosted payment
provider for the purpose of collecting sensitive payment information outside of the Campus Solutions application. The
framework consists of iScripts, a Hosted Payment Manager, Hosted Payment adapters, Payment Application adapters, and some
setup data.
The Hosted Payment framework leverages two sets of adapters with two distinct functions:
1. Hosted Payment adapters: The Hosted Payment adapter‟s function is to address all third party-specific integration
requirements. Hosted Payment adapters determine whether web service callouts are necessary before or after
transitioning to the third party host site. The delivered adapters are responsible for creating the form that gets auto
form posted to the third party. They also parse the HTTP Request coming back from the third party to get the payment
details after control is passed back to Campus Solutions. Note that these adapters do not directly perform the form
post or receive the response. iScripts are utilized for this purpose. There are two delivered adapters, Model1A and
Model1B.
2. Payment Application adapters: A Payment Application represents a feature or an application. Components utilizing
the Hosted Payment framework are registered as a Payment Application and have an assigned Payment Application
ID. Each Payment Application has an associated Payment Application adapter. These adapters are responsible for
retrieving, validating, and updating the application‟s transaction data. Each Payment Application is required to have
its own unique identifier for the transaction that will be used by the Hosted Payment framework to communicate with
the adapter. This is referred to in this document as the Payment Application key. The framework requires the
Payment Application key and ID be passed to and received back from the third party in order to correctly identify and
process the transaction.

The following illustration demonstrates the interaction between Campus Solutions and the third party hosted payment provider
required to display the third party‟s credit card or eCheck page.
Informational: The interaction between Campus Solutions and the third party is determined by the Hosted Payment adapters.
This diagram specifically illustrates how the delivered Hosted Payment adapters work by requiring a token returned by the third
party (through a Get Token web service callout) before transferring control to the third party. It is possible for the school or a
third party to create its own Hosted Payment adapter, which does not issue web service callouts before this transition.
1. The payer (student, cashier, etc.) initiates the transaction in a Campus Solutions application (Cashiering Student
Payment, Cashiering Corp Payment, Self Service Make a Payment, Miscellaneous Purchases, etc) by providing the
payment amount, picking a tender (when applicable), and submitting the payment. The Campus Solutions application
saves the transaction and creates the application‟s unique identifier for the transaction.
2. The application invokes the Hosted Payment framework.
3. The iScript will instantiate the Hosted Payment Manager. The Hosted Payment Manager marshals data between the
Hosted Payment adapter and Payment Application adapter using the Transaction Request and Response classes (see

“Appendix G: Transaction Class” for additional information on the Transaction Request and Transaction Response
application classes).
4. The Hosted Payment Manager will instantiate the Payment Application classes using Payment Application ID and key.
The Payment Application adapter will retrieve and validate its transaction data based on the Payment Application key.
The Payment Application adapter will fill the Transaction Request class with its transaction data, such as the payment
amount and the Payment Merchant ID. It will also retrieve any payment defaults, such as the name, address, phone,
etc. For ACH transactions, it will retrieve the shared secret based on the SF Merchant setup.
5. The Transaction Request class is passed back to the Hosted Payment Manager.
6. The Hosted Payment Manager instantiates the Hosted Payment adapter associated with the Payment Merchant ID in
the Transaction Request class.
7. The delivered Hosted Payment adapter instantiates the ePayment API to perform a Get Token web service callout
using the Transaction Request data passed in from the Payment Application adapter.
8. The ePayment API performs the web service callout to the third party.
9. The third party responds with a token.
10. The ePayment API interprets the results of the web service callout and passes the response back to the Hosted Payment
adapter.
11. The delivered Hosted Payment adapter receives the token. It creates the HTML form using the Adapter Settings setup
data. This string is passed back to the Hosted Payment Manager.
12. The Hosted Payment Manager returns control back to the iScript.
13. The iScript performs the form post.
14. In response to the form post, the third party will display a page to the browser, prompting for the payment details.
Because of the previous Get Token web service callout, the third party now has the transaction information, such as
name, amount, address, etc. The third party will display the page with this information.

After the payer provides the payment details on the third party payment provider hosted page, the third party hosted payment
provider will process the payment and transfer control back to Campus Solutions.
1. The payer inputs the payment details (credit card or eCheck) on the third party page and clicks on Continue or Submit.
2. The third party payment provider receives and validates the payment details and performs a redirect or auto form post
back to Campus Solutions. The target URL maps to one of three iScripts defined in the Hosted Payment Adapter
Settings in Campus Solutions (Success, Error, Cancel).
3. Campus Solutions receives the HTTP Request through the iScript. The iScript performs a lookup on the Hosted
Payment Adapter Settings to determine the Hosted Payment Adapter ID. The iScript instantiates the Hosted Payment
Manager.
4. The Hosted Payment Manager instantiates the Hosted Payment adapter. The adapter will parse the HTTP Request
using the Inbound Parameters on the Hosted Payment Adapter Settings. It will populate the Transaction Response
class with the HTTP Request parameters.
5. The Transaction Response class is passed back to the Hosted Payment Manager.

6. The Hosted Payment Manager instantiates the Payment Application classes. The application tables are updated with
the third party payment provider‟s unique token for the transaction. This token will be used later by the application
component to authorize the transaction.
7. The Payment Application adapter will pass the component URL back to the Hosted Payment Manager.
8. The Hosted Payment Manager passes back the return component URL to the iScript.
9. The iScript redirects to the component.
10. The component processes the transaction, retrieves the updated transaction tables, and displays the last four digits of
the account number. The user will submit the transaction. The component will invoke the ePayment API directly to
perform a web service callout to authorize the transaction.
THIRD PARTY INTEGRATION REQUIREMENTS FOR HOSTED PAYMENT

In order to integrate with Campus Solutions in a hosted mode, the third party payment provider‟s hosted solution should have
the following capabilities:
1. Campus Solutions requires control and sole determination of the tender type for each transaction. All Campus
Solutions applications determine the type of tender before transitioning to the third party, either through school setup,
application restrictions, or user selection. The third party solution should have the capability of receiving the tender
type with each transaction. Alternatively, the third party may set up merchants to be restricted to one tender. Since
each transaction can only have one merchant, and this merchant is communicated to the third party host with each
transaction, this will have the effect of restricting the transaction to a tender type. In this case, the school is required to
set up one payment merchant correspondingly to each third party merchant.
2. The third party hosted site should not allow the payer to change the amount in the third party pages. The amount is
determined at Campus Solutions. Allowing the payer to change this value at the third party site may result in data
integrity issues.

Implementing the Traditional Payment Model
The traditional model supports sending the ePayment transactions to an external payment processor using either the Business
Interlinks or Integration Broker. This section will discuss how to implement the traditional model of processing ePayment
transactions using the ePayment API and the delivered Business Interlink and Integration Broker adapters.
Supported Transactions for the Traditional Model:
Credit Card
 Authorize Only
 Authorize/Bill (Capture)
 Bill (Capture) Only
 Credit Only
eCheck (ACH)
 Make Payment (Debit)
 Apply Credit
TRADITIONAL MODEL USING BUSINESS INTERLINKS

This section of the document will discuss how to implement the traditional model of processing ePayment transactions using the
Campus Solutions-supplied Business Interlink adapter.
Informational: Existing customers who are currently using Business Interlinks for ePayment transaction processing should
already have a working integration using the Business Interlinks. These customers may skip the pre-requisite setup step as the
Business Interlinks should already be working properly. Also note that these same customers should not need to perform any
additional setup-related activities assuming they have run the ePayment merchant conversion program (UPD795777_A1).
Customers who have run the ePayment merchant conversion program may skip to “Step 3: Test the Integration”.
Step 1: Pre-Requisite Setup
Verify Business Interlinks Setup
Verify that the business interlinks (CREDITCARD_TRANSACTION and ECHECK_TRANSACTION) are setup properly and
are operational. Please see the Business Interlink install documentation found here for instructions on how to properly set up
the ePayment Business Interlinks (Electronic Payment Interface for Campus Solutions 8.9 and 9.0 (Doc ID 702489.1)). Testing
the Business Interlink setup can be done using the Perform Interlink Test component (Set Up SACR > Product Related >
Student Financials > Perform Interlink Test).

Step 2: Create the Payment Merchant
1. Log in to Campus Solutions using PIA.
2. Navigate to the Payment Merchant Setup component (Set Up SACR > Common Definitions > Payment Merchant).
3. Click on “Add a New Value” tab.
4. Enter the value that you wish to use to uniquely identify this Payment Merchant in the “Merchant Setup ID” field and
click the “Add” button.
5. Enter values in the various Payment Merchant fields:
a. Description: Enter a Valid Description.
b. Service Provider: Select your service provider from the dropdown. If your payment provider is not listed,
then select “unsupported”. This field is for informational purposes only so don‟t be concerned about
selecting the “unsupported” option if your vendor is not listed.
c. 3rd party Merchant ID: Enter the merchant id that you use to uniquely identify your account with the third
party payment provider (this value comes directly from your payment provider).
d. Hosted Payment Provider: Leave this field unchecked.
e. Service Operation: Leave this field blank as Service Operations are only relevant for Integration Broker-
based integrations.
f. Adapter: Select the “SCC_BUS_INTERLINK” value from the dropdown list.
g. Supported Transactions: Enter values 1-6 as appropriate in this grid, depending on whether your institution
will support credit card, eCheck, or both types of transactions.
h. Verification Level: Select a default value for this field. The value here acts as a default if the transaction
does not contain a valid value (this field is optional).
i. Settlement Method: Select a default value for this field. The value here acts as a default if the transaction
j. ACH Class: Leave this field blank as this field is not used for Business Interlink integrations since it is not
represented on the ECHECK_TRANSACTION Business Interlink.
k. CVV Supported: This field should be unchecked as the Security Code (CVV, CSC, etc.) is not currently
supported by the CREDITCARD_TRANSACTION Business Interlink.

l. Address Verification Flag: Select a default value for this field. The value here acts as a default if the
transaction does not contain a valid value (this field is optional).
m. Process Server: This field is used to override the server_host property of the Business Interlinks
(CREDITCARD_TRANSACTION and ECHECK_TRANSACTION). This field should be filled in for
Business Interlink integrations.

6. Save the page (Payment Merchant setup is complete).

Step 3: Test the Integration
Navigate to the ePayment test page (Set Up SACR > Common Definitions > Electronic Payments > Electronic Payment Test)
and execute test transactions to verify that your new integration is working and that you can pass ePayment transactions to your
payment provider (see “Appendix N: Testing the ePayment API”).

TRADITIONAL MODEL USING INTEGRATION BROKER

This section of the document will discuss how to implement the traditional model of processing ePayment transactions using the
Campus Solutions supplied Integration Broker adapter.
Map Integration Broker Message Structure to your Payment Provider’s Message

Structure
You will need to map the Integration Broker message structure to your payment provider‟s message structure. This will need to
be done for both the request message (SCC_EPAY_SYNC) and the response message (SCC_EPAY_RESPONSE).
Informational: Some payment providers may be able to help you with the development of the required Integration Broker
transformation programs and logic needed to build a working interface using the Campus Solutions ePayment API. Please
contact your payment provider to confirm that they support the Campus Solutions ePayment API using Integration Broker.
Request Message Structure (SCC_EPAY_SYNC)
A good understanding of the request message structure will be required to properly map the Campus Solutions-delivered
request message to your payment provider‟s request message structure. See “Appendix A: Request Message and Structure” for
information about the request message structure and properties.
Response Message Structure (SCC_EPAY_RESPONSE)
A good understanding of the response message structure will be required to properly map the Campus Solutions-delivered
response message to your payment provider‟s response message structure. See “Appendix B: Response Message and
Structure” for information about the response message and structure.
Informational: Schema (XSD) files of the SCC_EPAY_SYNC and SCC_EPAY_RESPONSE messages can be generated at
PeopleTools > Integration Broker > Integration Utilities > Message Schema Builder. This step is not required but may be
helpful when mapping elements of the request and response messages to the payment provider‟s message schemas.
Return Codes and Response Messages
Campus Solutions has defined a set of return codes and associated messages that will need to be understood so that a
meaningful integration with your payment provider can be developed. You will need to map your payment provider‟s return
codes to the set of Campus Solutions return codes as described in “Appendix O: Campus Solutions ePayment Return Codes
and Associated Messages”.
Develop Transformations using Application Engine
To get a working integration with a third party payment provider, you will need to be able to send and receive messages to and
from the payment provider. Transformations will be required to translate the messages generated by the Campus Solutions
system into a format that is accepted by your payment provider. PeopleSoft uses the Integration Broker tool for interfacing with
external third parties. For transformations occurring in Integration Broker, you will need to develop both a request and a
response transformation program using the Application Engine development tool. Other options exist for transforming message
structures (such as gateway-based transformations), but they will not be discussed in this document.

Sample Request Transformation Program
(See “Appendix C: Creating a Transformation Program using Application Engine (Request) ” for instructions on how to create
a sample request transformation program for use with Integration Broker.)
Sample Response Program
(See “Appendix D: Creating a Transformation Program using Application Engine (Response)” for instructions on how to
create a sample response transformation program for use with Integration Broker.)
Step 2: Create Integration Broker-Related Objects
This step will discuss how to create the Integration Broker-related objects that you will need to create a working integration
using the Integration Broker-based ePayment adapter.
Required Objects are:
 A Node for your Campus Solutions environment (the default local node).
 A Node for your payment provider (external node).
 A Service Operation and Routing.
Identif y your Default Local Node
You will need to identify your default local node. A working default local node must already exist within your system. To
determine what your default local node is, navigate to the Nodes component under Integration Broker Setup (PeopleTools >
Integration Broker > Integration Setup > Nodes) and look for your “Default Local Node” as shown below. Note that this node
will be needed when creating the Service Operation Routing discussed later in this chapter.

Create the External Int egration Broker Node for your Payment Provider
You will need to create an Integration Broker Node for your payment provider. This Node will be used by Integration Broker
to help with the routing of the transaction to the payment provider. See “Appendix E: Creating an Integration Broker Node for
Payment Provider” for general instructions on how to create an Integration Broker Node for your payment provider.
Update the Existing Service Operation and Create the Required Routin g
Once you have located your default local Node and defined and external Node for your payment provider, you will need to
update the existing Service Operation and add a valid Routing definition to it. See “Appendix F: Updating the Existing Service
Operation and Creating the Required Routing” for general instructions on how to update the SCC_EPAYMENT_SYNC
Service Operation and create the required Routing so that transactions can be sent and received between your institution and
your payment provider.
1. Login to Campus Solutions using PIA.
3. Click “Add a New Value” tab.
b. Service Provider: Select your payment provider from the dropdown, if your payment provider is not listed then
select “unsupported”. This field is for informational purposes only so don‟t be concerned about selecting the
“unsupported” option if your vendor is not listed.
c. 3rd Party Merchant ID: Enter the merchant id that you use to uniquely identify your account with the third party
payment provider (this value comes directly from your payment provider).
d. Hosted Payment Provider: Leave this field unchecked if you are only using this Payment Merchant for the
Traditional Integration Model as described above (not using Hosted Payment).
e. Service Operation: Select the appropriate Service Operation. For the purposes of this guide, we will be selecting
the SCC_EPAYMENT_SYNC Service Operation. We are using this Service Operation primarily because it uses
the SCC_EPAY_SYNC and SCC_EPAY_RESPONSE messages that are referenced by the SCC_INT_BROKER

adapter (see next field). Customers can create their own Service Operations to use with the ePayment API. If
you choose to do so, ensure it works with the adapter you have selected. The delivered Integration Broker adapter
expects that the SCC_EPAY_SYNC and SCC_EPAY_RESPONSE messages will be used by the Service
Operation.
f. Adapter: Select the “SCC_INT_BROKER” value from the dropdown list.
g. Security Key Setup: This section is used to document any security key or token that may be required by your
payment provider. It is passed along in the Integration Broker-based transaction and can be accessed in the
transformation where it can be incorporated into WS security for SOAP transactions if needed.
1. Key ID: Enter a Key ID here to help you identify the key that is stored here. This field is for
informational purposes only.
2. Expiration Date: Populate the expiration date of the key if one is available. This field is for
3. Key: This field holds the actual value of the passkey or token that may be needed for certain
providers. It can be used in the transformation program to create the WS security section of the
SOAP transaction header. The field could also potentially be used for other security-related
constructs.
h. Supported Transactions: Enter values 1-6 as appropriate in this grid, depending on whether your institution will
support credit card, eCheck, or both types of transactions.
i. Verification Level: Select a default value for this field. The value here acts as a default if the transaction does not
contain a valid value. This field is optional.
j. Settlement Method: Select a default value for this field. The value here acts as a default if the transaction does
not contain a valid value. This field is optional.
k. ACH Class: Select a value for this field from the dropdown list. This field is sometimes needed for certain
eCheck transactions.
l. CVV Supported: This field should be unchecked if your payment provider does not support sending the Security
Code field. Check this field if your payment provider supports sending the Security Code value with credit card
transactions and you wish to collect and send the Security Code field in your credit card transactions to your
payment provider.
m. Address Verification Flag: Select a default value for this field. The value here acts as a default if the transaction
n. Process Server: This field is used to override the server_host property of the Business Interlinks. This field is
required for Business Interlink-based integrations.




Implementing the Hosted Payment Model
HOSTED MODEL SETUP AND CONFIGURATION FOR THE EPAYMENT API

The Hosted Payment model as implemented by Campus Solutions also uses the ePayment API to pass payment transactions to
the hosted payment provider. The setup here is very similar to the setup that the ePayment API requires for the traditional
model of ePayment integration. The ePayment API for the hosted model supports a different set of transactions than does the
ePayment API for the traditional model. There are also differences between models in how the Payment Merchant is defined.
The ePayment API for the hosted model supports sending the hosted payment transactions to an external payment processor
using only the Integration Broker-based adapter. This section will discuss how to implement the hosted model of processing
ePayment transactions using the Integration Broker-based adapter.
Supported Transactions for the Hosted Model:
Hosted Transactions
 Get Token: This transaction sends various data to the hosted payment provider site. It is used to initiate a hosted
payment transaction. The hosted payment vendor returns a token, which is used to identify the hosted payment
transaction and the payer (student, cashier, etc.).
 Authorize: This transaction is used to authorize both credit card and eCheck transactions collected at the hosted
payment provider‟s site.
 Process Credit: This transaction is used to credit authorized credit card and eCheck transactions collected at the
hosted payment provider‟s site.
Map Integration Broker Message Structure to your Payment Provider’s Message

Structure
You will need to map the Integration Broker message structure to your payment provider‟s message structure. This will need to
be done for both the request message (SCC_EPAY_SYNC) and the response message (SCC_EPAY_RESPONSE).
Informational: Some payment providers may be able to help you with the development of the required Integration Broker
transformation programs and logic needed to build a working interface using the Campus Solutions ePayment API. Please
contact your vendor to confirm that they support the Campus Solutions ePayment API using Integration Broker.
Request Message Structure (SCC_EPAY_SYNC)
A good understanding of the request message structure will be required to properly map the Campus Solutions delivered request
message to your payment provider‟s request message structure. See “Appendix A: Request Message and Structure” for
information about the request message structure and properties.

Response Message Structure (SCC_EPAY_RESPONSE)
A good understanding of the response message structure will be required to properly map the Campus Solutions delivered
response message to your payment provider‟s response message structure. See “Appendix B: Response Message and
Structure” for information about the response message and structure.
Informational: Schema (XSD) files of the SCC_EPAY_SYNC and SCC_EPAY_RESPONSE messages can be generated using
a PeopleSoft-supplied utility located at PeopleTools > Integration Broker > Integration Utilities > Message Schema Builder.
This step is not required but may be helpful when mapping elements of the request and response messages to the payment
provider‟s message schemas.
Return Codes and Response Messages
Campus Solutions has defined a set of return codes and associated messages that will need to be understood so that a
meaningful integration with your payment provider can be developed. You will need to map your payment provider‟s return
codes to the set of Campus Solutions return codes as described in “Appendix O: Campus Solutions ePayment Return Codes
and Associated Messages”.
Develop Transformations using Application Engine
To get a working integration with a third party payment provider, you need the ability to send and receive messages to and from
the payment provider. Transformations will be required to translate the messages generated by the Campus Solutions system
into a format that is accepted by your payment provider. PeopleSoft uses the Integration Broker tool for interfacing with
external third parties. For transformations occurring in Integration Broker you need to develop both a request and a response
transformation program using the Application Engine development tool. Other options exist for transforming message
structures (such as gateway-based transformations), but they will not be discussed in this document.
Sample Request Transformation Program
(See “Appendix C: Creating a Transformation Program using Application Engine (Request) ” for instructions on how to create
a sample request transformation program for use with Integration Broker.)
Sample Response Program
(See “Appendix D: Creating a Transformation Program using Application Engine (Response)” for instructions on how to
create a sample response transformation program for use with Integration Broker.)
Step 2: Create Integration Broker Related Objects
This step will discuss how to create the Integration Broker-related objects that you will need to create a working integration
using the Integration Broker-based ePayment adapter.
Required Objects are:
 A Node for your Campus Solutions environment (the default local node).
 A Node for your payment provider (external node).
 A Service Operation and Routing.

Identify your Default Local Node
You will need to identify your default local node. A working default local node must already exist within your system. To
determine what your default local node is, navigate to the Nodes component under Integration Broker Setup (PeopleTools >
Integration Broker > Integration Setup > Nodes) and look for your “Default Local Node” as shown below. Note that this node
will be needed when creating the Service Operation Routing discussed later in this chapter.
Create the External Integration Broker Node for your Payment Provider
to help with the routing of the transaction to the payment provider. See “Appendix E: Creating an Integration Broker Node for
Payment Provider” for general instructions on how to create an Integration Broker Node for your payment provider.
Update the Existing Service Operation and Create the Required Routing
Once you have located your default local Node and defined an external Node for your payment provider, you will need to
update the existing Service Operation and add a valid Routing definition to it. See “Appendix F: Updating the Existing Service
Operation and Creating the Required Routing” for general instructions on how to update the SCC_EPAYMENT_SYNC
Service Operation and create the required Routing so that transactions can be sent and received between your institution and
your payment provider.
1. Login to Campus Solutions using PIA.
3. Click “Add a New Value” tab.

b. Service Provider: Select your payment provider from the dropdown, if your payment provider is not listed
then select “unsupported”. This field is for informational purposes only so don‟t be concerned about
selecting the “unsupported” option if your provider is not listed.
c. 3rd Party Merchant ID: Enter the merchant id that you use to uniquely identify your account with the third
party payment provider (this value comes directly from your payment provider).
d. Hosted Payment Provider: Check this field as this is a Hosted Payment Merchant. Checking this field will
unhide additional Hosted Payment options.
e. Hosted Payment Setup: This section is visible only when the Hosted Payment Provider checkbox is checked.
i. Adapter: Pick the correct Hosted Payment Adapter based on your third party‟s hosted payment
solution (either SCC_MODEL1A or SCC_MODEL1B).
ii. Browser Requirements Message: This field is used to message browser requirements to users prior
to them being transferred to the hosted payment provider‟s site.
iii. Browser Requirements Detail: This field is used to message browser requirements to users prior to
them being transferred to the hosted payment provider‟s site.
f. Service Operation: Select the appropriate Service Operation. For the purposes of this guide, we will be
selecting the SCC_EPAYMENT_SYNC Service Operation since this is the delivered Service Operation. The
SCC_EPAYMENT_SYNC Service Operation uses the SCC_EPAY_SYNC and SCC_EPAY_RESPONSE
messages that are referenced by the SCC_INT_BROKER adapter (see next field). You can create your own
Service Operation. If you choose to do so, ensure it works with the adapter you have selected. The delivered
Integration Broker adapter expects that the SCC_EPAY_SYNC and SCC_EPAY_RESPONSE messages will
be used by the Service Operation.
g. Adapter: Select the “SCC_INT_BROKER” value from the dropdown list.
h. Security Key Setup (not shown in the example page below): This section is used to document any required
security key or token that MAY be needed by your payment provider. It is passed along in the Integration
Broker-based transaction and can be accessed in the transformation where it can be incorporated into WS
security for SOAP transactions if needed.
i. Key ID: Enter a Key ID here to help you identify the key that is stored here. This field is for

ii. Expiration Date: Populate the expiration date of the key if one is available. This field is for
iii. Key: This field holds the actual value of the pass-key or token that may be needed for certain
payment providers. It can be used in the transformation program to create the WS security section
of the SOAP transaction header or other security related constructs.
i. Supported Transactions: Enter values 91, 92, and 93 in this grid. These 3 transactions are specifically
designed for our Hosted Payment solution and should work for a variety of third party hosted payment
providers.
i. Get Token (91): This transaction sends various data to the hosted payment provider site. It is used
to initiate a hosted payment transaction. The hosted payment vendor returns a token, which is used
to identify the hosted payment transaction and the payer (student, cashier, etc.).
ii. Authorize Only (92): This transaction is used to authorize both credit card and eCheck transactions
collected at the hosted payment provider‟s site.
iii. Credit Only (93): This transaction is used to credit both credit card and eCheck transactions (once
they have been authorized) collected at the hosted payment provider‟s site.
j. Verification Level: Select a default value for this field. The value here acts as a default if the ePayment
transaction does not contain a valid value. This field is optional and may not be used by all payment
providers.
k. Settlement Method: Select a default value for this field. The value here acts as a default if the transaction
does not contain a valid value. This field is optional and may not be used by all payment providers.
l. ACH Class: Select a value for this field from the dropdown list. This field us used by some eCheck
transactions. This value is often established at the hosted payment provider‟s site and is generally not
required to process hosted payment eCheck transactions.
m. CVV Supported: This field is hidden for hosted payment providers because display of the Security Code
(CVV, CSC, etc.) is controlled at the hosted payment vendor‟s site, and credit card transactions are not
entered using the Campus Solutions system if the hosted payment option is being leveraged.



HOSTED MODEL SETUP AND CONFIGURATION FOR THE HOSTED PAYMENT

FRAMEWORK
Before you start, you will need to work with your third party payment provider to understand their form post requirements and
map the Transaction classes to your third party payment provider‟s post parameters:
 Transaction Request Class: The Transaction Request class is used by the Hosted Payment framework to create an
array of hidden form elements for the http post to the third party site. Certain parameters are required by your third
party to properly identify the transaction being form posted to their site, such as the third party merchant ID. These
values should be in the Transaction Request class. Please refer to “Appendix G: Transaction Class” for detailed
information about the properties of the Transaction Request class.
 Transaction Response Class: The Transaction Response class needs to be mapped to the return form post elements
from the third party provider. The Transaction Response class properties will be used to update the transaction tables
with the third party provider‟s unique identifier to the transaction, as well as payment details such as the last four digits
of the account number. Please refer to “Appendix G: Transaction Class” for detailed information about the properties
of the Transaction Response class.
Step 2: Selecting a Hosted Payment Adapter
There are two delivered Hosted Payment adapters, SCC_MODEL1A and SCC_MODEL1B. The adapter you choose will
depend on how many user-defined elements your third party provider allows.
In order to process a transaction correctly, the Hosted Payment framework requires both the Payment Application ID
(Transaction Source) and the Payment Application Key (Merchant Reference). The Payment Application ID allows the Hosted
Payment framework to instantiate the Payment Application adapter while the Payment Application Key allows the adapter to
retrieve, validate and update the transaction. These data elements must be passed to the third party payment provider, and the
third party payment provider must pass it back to Campus Solutions.

Third party solutions allow one or more elements to be allocated as user-defined. This allows their partners to pass back and
forth some data useful in identifying the transaction.
If your third party hosted provider allocates only one element as user-defined, the school must use SCC_MODEL1A as its
Hosted Payment adapter. This adapter will concatenate the Payment Application ID and Payment Application key into the
Transaction Request Class‟ merchantRef property. The merchantRef can then be passed to the third party through the Get
Token web service call. The third party must pass this value back as part of the form post to Campus Solutions. This adapter
expects that the Inbound Parameters in the Hosted Payment Adapter Settings will include the merchantRef. The adapter will
then parse the value into separate properties in the Transaction Response class.
Your institution may use SCC_MODEL1B if the third party payment provider is capable of accepting two or more data
elements as user defined. The Payment Application ID and Payment Application Key must be passed to the third party
payment provider using the TransactionSource and merchantRef properties of the Transaction Request class. The third party
payment provider may either pass these values through the Get Token web service call, or by mapping them using the Outbound
Parameters grid of the Hosted Payment Adapter Setting. The school must also map the merchantRef and TransactionSource
properties of the Transaction Response class to these elements in the Inbound Parameters grid of the Hosted Payment Adapter
Setting. This will allow the framework to correctly associate the transaction to the originating application when transitioning
back to Campus Solutions.
Step 3: Review the Payment Merchant Setup
The Payment Merchant should have been setup in Step 3 of “Hosted Model Setup and Configuration of the ePayment API”
section. It may be necessary to create separate Payment Merchants for each tender the school accepts (one for credit card
processing and one for eCheck processing). This depends on whether your hosted payment provider supports accepting the
payment type (credit card or eCheck) in the initial Get Token transaction and then locking the payment type so that the payer
cannot change it when entering the payment details – allowing the payer to change this value at the third party site may result in
data integrity issues. If your hosted payment provider does not support the sending and locking of the payment type (credit card
or eCheck), then you will be required to create separate Payment Merchants, each pointing to a different hosted site at the
hosted payment provider (assuming the hosted payment provider can configure each site to accept only credit card transactions
or only eCheck transactions).
If necessary, create one payment merchant for credit card and another for ACH (see instructions in Step 3 of “Hosted Model
Setup and Configuration of the ePayment API” section).
Step 4: Configuring the Hosted Payment Adapters
Provide security for Hosted Payment iScripts
iScripts are an important part of the Hosted Payment framework and require a permission list update. .
To add permission list security for iScripts:
1. Navigate to the Permission Lists component (PeopleTools > Security > Permission & Roles > Permission Lists).
2. Select the appropriate permission list related to the Cashiering and/or Student Financials Self Service applications.
3. Click on the “Web Libraries” tab.
4. Add the following Web Libraries:

5. Click on the “Edit” link for WEBLIB_SCC_HPAY.
6. Add Full Access to the function below:
7. Click on OK.
8. Click on the “Edit” link for WEBLIB_SCC_HPTP.
9. Add Full Access to the functions below:
For more details, please refer to the iScript Security section of the Enterprise PeopleTools 8.49 PeopleBook: PeopleCode API
Reference (Internet Script Classes).

Create Third Party U RL Definition
If you are using the delivered Hosted Payment adapters, you will need to define the third party‟s URL before setting up the
Hosted Payment Adapter Settings. This URL will be used by the Hosted Payment Adapter as the target for the redirect to your
Hosted Payment Provider site.
1. Navigate to the URL Maintenance component (PeopleTools > Utilities > Administration > URLs).
2. Click “Add a New Value”.
3. Enter the value you wish to uniquely identify as your hosted third party site:
4. Click on the “Add” button.
5. Enter your Hosted Payment Provider‟s URL:
The URL is later tied to the Hosted Payment Adapter.

Create an HTML Definition
The delivered Hosted Payment adapters require a user-defined HTML Definition. Later, you will tie this HTML Definition to
the Hosted Payment Adapter Setting for the Hosted Payment adapter you have chosen to use..
The delivered Hosted Payment adapters expect two bind parameters in the HTML. The first bind parameter will be populated
with the hosted site‟s URL. The delivered adapters will create an array of hidden input elements based on the Hosted Payment
Adapter Setting Outbound grid for the second bind parameter.
To create an HTML Definition:
1. In the PeopleTools Application Designer, select File > New.
2. Pick “HTML” from the list.
3. Input your HTML.
4. Save.

Configuring the Hosted Payment Adapter Settings
The Hosted Payment Adapter Settings are used by the delivered Hosted Payment Adapters to create the form to be posted to the
third party site, as well as to parse the HTTP Request from the third tarty in order to retrieve the payment details.
To create the Hosted Payment Adapter Setting for the delivered Hosted Payment adapters:
1. Navigate to Setup SACR>Common Definitions>Electronic Payments>Hosted Payment Adapter Setting.
2. Select the adapter you have chosen for your Payment Merchant.
3. Fill in the appropriate values in the tab Hosted Payment Adapter:
a) HTML Definition: Select the HTML Definition you defined in the earlier section.
b) Third Party URL: Select the Third Party URL you defined in an earlier section. This URL is used as input to
the HTML Definition.

c) Record Name: Select record “WEBLIB_SCC_HPTP”. This record contains the delivered iScripts for
navigating back to Campus Solutions. This record contains the delivered Weblib functions that allow the
third party to navigate back in.
d) Field Name: Select the field “SCC_HPAY_THRD_PRTY”.
e) Fill in the grid as shown above. These iScripts are delivered and can be used with any Third Party.
Informational: You third party payment provider will require return URLs in order to navigate the payer back to Campus
Solutions after processing the transaction. These URLs are either passed to the third party as part of the initial web service call,
or defined in the third party site. There are typically three return URLs required, one for each processing result (Cancel,
Success, Error). These return URLs should correspond to the Weblib functions defined in the grid above. The URL
corresponding the Weblib defined above is assembled as follows:
“https://server/servlet_name/SiteName/PortalName/NodeName/ content_type/
WeblibRecord.Weblib.FieldName.Event.Function”. For example, the success URL can be defined as
“https://schoolserver/psc/ps/EMPLOYEE/HRMS/s/WEBLIB_SCC_HPTP.SCC_HPAY_THRD_PRTY.FieldFormula.IScript_
Successful_Payment_TP”. For more details on how to assemble the return URL, please refer to Details of an iScript URL in
the Enterprise PeopleTools 8.49 PeopleBook: PeopleCode API Reference (Internet Script Classes).
4. Click on the “Parameters” tab.
5. Fill in the parameters as per your third party provider‟s instructions.

a) Outbound Parameters: These parameters are used by the Hosted Payment adapters SCC_MODEL1A and
SCC_MODEL1B to create an array of hidden input elements for the html form to be posted to the third party site.
Mapping these data elements will allow the delivered Hosted Payment adapters to fill in the values from the
Transaction Request class properties properly. Please refer to “Appendix G: Transaction Class” for detailed
information about the properties of the Transaction Request class.
b) Inbound Parameters: These values are passed back by the third party to Campus Solutions through the HTTP
Request. For institutions using SCC_MODEL1A, the Inbound Parameters should include at least the
merchantRef. For institutions using SCC_MODEL1B, the TransactionSource and merchantRef should be listed in
the InboundParemeters grid. Mapping these properties will allow the delivered Hosted Payment adapters to
populate the Transaction Response class with values passed back from the third party. The Transaction Response
class is used later by the Hosted Payment framework to update the transaction tables. Please refer to “Appendix
G: Transaction Class” for detailed information about the properties of the Transaction Response class.

Appendix
APPENDIX A: REQUEST MESSAGE STRUCTURE AND PROPERTIES

Request Message Structure (relevant records are highlighted in yellow):
Sample Request Message:
<?xml version="1.0"?>
<SCC_EPAY_SYNC>
<FieldTypes>
<SCC_EPAY_XMLPAY class="R">
<SCC_EPAY_UNIQUE_ID type="CHAR"/>
</SCC_EPAY_XMLPAY>
<SCC_EPAY_ADDR1 class="R"/>
<SCC_EPAY_ADDR2 class="R">
<ADDRESS1 type="CHAR"/>
<CITY type="CHAR"/>
<STATE type="CHAR"/>
<POSTAL type="CHAR"/>
<COUNTRY type="CHAR"/>

</SCC_EPAY_ADDR2>
<SCC_EPAY_BILLFM class="R"/>
<SCC_EPAY_BILLTO class="R">
<SCC_EPAY_CUSTID type="CHAR"/>
<SCC_EPAY_FNAME type="CHAR"/>
<SCC_EPAY_LNAME type="CHAR"/>
<SCC_EPAY_FULLNAME type="CHAR"/>
<SCC_EPAY_EMAIL type="CHAR"/>
<PHONE type="CHAR"/>
<FAX type="CHAR"/>
<SCC_EPAY_DL_NO type="CHAR"/>
<SCC_EPAY_DL_STATE type="CHAR"/>
</SCC_EPAY_BILLTO>
<SCC_EPAY_SHIPFM class="R"/>
<SCC_EPAY_SHIPTO class="R"/>
<SCC_EPAY_ITEM class="R"/>
<SCC_EPAY_INV class="R">
<SCC_EPAY_TOTAL_AMT type="NUMBER"/>
<SCC_EPAY_COMMENT type="CHAR"/>
<CURRENCY_CD type="CHAR"/>
</SCC_EPAY_INV>
<SCC_EPAY_TRANS class="R">
<SCC_EPAY_TRANS_REF type="CHAR"/>
<SCC_EPAY_MERCH_REF type="CHAR"/>
<SCC_MERCH_CONNECT type="CHAR"/>
<SCC_EPAY_RQST_ID type="CHAR"/>
<SCC_EPAY_SESSIONID type="CHAR"/>
<SCC_EPAY_RQST_TOKN type="CHAR"/>
<SCC_PMT_APPL type="CHAR"/>
<SCC_EPAY_SEC_KEY type="CHAR"/>
<SCC_EPAY_MISC_LONG type="CHAR"/>
</SCC_EPAY_TRANS>
<SCC_EPAY_CARD class="R">
<SCC_EPAY_TYPE type="CHAR"/>
<SCC_EPAY_NUMBER type="CHAR"/>
<SCC_EPAY_EXPYR type="CHAR"/>
<SCC_EPAY_EXPMO type="CHAR"/>
<SCC_EPAY_CVNUM type="CHAR"/>
<SCC_EPAY_MAGDATA type="CHAR"/>
</SCC_EPAY_CARD>
<SCC_EPAY_ACCT class="R">
<SCC_EPAY_ACCT_TYPE type="CHAR"/>
<SCC_EPAY_BANK_CD type="CHAR"/>
<SCC_EPAY_ACCT_NBR type="CHAR"/>
<SCC_EPAY_CHECK_NBR type="NUMBER"/>
</SCC_EPAY_ACCT>

<SCC_EPAY_SUBSCR class="R">
<SCC_EPAY_SUB_ID type="CHAR"/>
<SCC_EPAY_DISBLAATH type="CHAR"/>
<SCC_EPAY_SUBCRSRVC type="CHAR"/>
<SCC_EPAY_EVENTACTN type="CHAR"/>
<SCC_EPAY_EVENTSRVC type="CHAR"/>
<SCC_EPAY_GETSRVC type="CHAR"/>
<SCC_EPAY_UPDSRVC type="CHAR"/>
<SCC_EPAY_APPROVAL type="CHAR"/>
<SCC_EPAY_AUTORENEW type="CHAR"/>
<SCC_EPAY_BILLPAY type="CHAR"/>
<SCC_EPAY_RECUR_AMT type="NUMBER"/>
<SCC_EPAY_SETUP_AMT type="NUMBER"/>
<SCC_EPAY_EAPPR_BY type="CHAR"/>
<SCC_EPAY_EVENT_NBR type="NUMBER"/>
<SCC_EPAY_EVNT_FREQ type="CHAR"/>
<SCC_EPAY_NBR_PYMNT type="NUMBER"/>
<SCC_EPAY_STARTDATE type="DATE"/>
<SCC_EPAY_END_DT type="DATE"/>
<SCC_EPAY_STATUS type="CHAR"/>
<SCC_EPAY_SUB_METHD type="CHAR"/>
<SCC_EPAY_SUB_TITLE type="CHAR"/>
</SCC_EPAY_SUBSCR>
<SCC_EPAY_TRNTYP class="R">
<SCC_EPAY_TRANSACT type="CHAR"/>
<SCC_EPAY_AVS_DECL type="CHAR"/>
<SCC_EPAY_AVSFLAG type="CHAR"/>
<SCC_EPAY_DECSN_MGR type="CHAR"/>
<EC_SETTLE_METHOD type="CHAR"/>
<EC_VERIFICATION type="CHAR"/>
<SCC_EPAY_ACH_CLASS type="CHAR"/>
<SCC_EPAY_IP_ADDR type="CHAR"/>
<SCC_EPAY_SECRET type="CHAR"/>
<SCC_EPAY_SECRETVAL type="CHAR"/>
<SCC_EPAY_DECRYPT type="CHAR"/>
<SCC_EPAY_PARAMCHK type="CHAR"/>
<SCC_EPAY_SETTLENOW type="CHAR"/>
<SCC_EPAY_FSRISK type="CHAR"/>
<SCC_EPAY_FSTHRES type="NUMBER"/>
<SCC_EPAY_FSCMOD type="CHAR"/>
<SCC_EPAY_FSCGIFT type="CHAR"/>
<SCC_EPAY_FSCLNGTRM type="CHAR"/>
<SCC_EPAY_FSCTIME type="CHAR"/>
<SCC_EPAY_FSHOSTHDG type="CHAR"/>
<SCC_EPAY_FSTIMEHDG type="CHAR"/>
<SCC_EPAY_FSVELHDG type="CHAR"/>
<SCC_EPAY_AGREE_NBR type="CHAR"/>

<AGREEMENT_DT type="DATE"/>
<AGREEMENT_TEXT type="CHAR"/>
</SCC_EPAY_TRNTYP>
<SCC_EPAY_PAYDAT class="R"/>
<SCC_EPAY_TENDER class="R">
<SCC_EPAY_PAYMETHOD type="CHAR"/>
</SCC_EPAY_TENDER>
<SCC_EPAY_RQST class="R">
<SCC_EPAY_MERCHANT type="CHAR"/>
<SCC_EPAY_PARTNER type="CHAR"/>
</SCC_EPAY_RQST>
<PSCAMA class="R">
<LANGUAGE_CD type="CHAR"/>
<AUDIT_ACTN type="CHAR"/>
<BASE_LANGUAGE_CD type="CHAR"/>
<MSG_SEQ_FLG type="CHAR"/>
<PROCESS_INSTANCE type="NUMBER"/>
<PUBLISH_RULE_ID type="CHAR"/>
<MSGNODENAME type="CHAR"/>
</PSCAMA>
</FieldTypes>
<MsgData>
<Transaction>
<SCC_EPAY_XMLPAY class="R">
<SCC_EPAY_UNIQUE_ID IsChanged="Y">ded44c21-d2d6-11de-8c1c-c27032a87a52</SCC_EPAY_
UNIQUE_ID>
<SCC_EPAY_RQST class="R">
<SCC_EPAY_MERCHANT IsChanged="Y">peoplesofttest</SCC_EPAY_MERCHANT>
<SCC_EPAY_PARTNER IsChanged="Y">01</SCC_EPAY_PARTNER>
<SCC_EPAY_TRANS class="R">
<SCC_EPAY_TRANS_REF IsChanged="Y">20091116000008</SCC_EPAY_TRANS_REF>
<SCC_EPAY_MERCH_REF IsChanged="Y">ded44c21-d2d6-11de-8c1c-c27032a87a52</SCC_
EPAY_MERCH_REF>
<SCC_MERCH_CONNECT/>
<SCC_EPAY_RQST_ID IsChanged="Y">20091116000008</SCC_EPAY_RQST_ID>
<SCC_EPAY_SESSIONID/>
<SCC_EPAY_RQST_TOKN/>
<SCC_PMT_APPL IsChanged="Y">TEST</SCC_PMT_APPL>
<SCC_EPAY_SEC_KEY IsChanged="Y">MuauMgZDDN/eQo2WDXANpLONh7vhL3xH28foDCX3m2QEoi8
FmUPVsjWbtJ3QYdtLRUQyN/7ETWt2Uhu9cMEC24LWPkUd9Dqr5Fudkd4Aw34nxmthBr+tco1QPCx5/
XGMItC2myOWECqOb2KTTYGrAMeEO93XJYgTILvHl8oJyg3hwSa0ytpSmPfNf+dXcA2ks42Hu+EvfEf
bx+gMJfebZASiLwWZQ9WyNZu0ndBh20tFRDI3/sRNa3ZSG71wwQLbgtY+RR30OqvkW52R3gDDfifGa
2EGv61yjVA8LHn9cYwi0LabI5YQKo5vYpNNgasAx4Q73dcliBMgu8eXygnKDQ==</SCC_EPAY_SEC_
KEY>
<SCC_EPAY_MISC_LONG/>
<SCC_EPAY_TRNTYP class="R">
<SCC_EPAY_TRANSACT IsChanged="Y">1</SCC_EPAY_TRANSACT>
<SCC_EPAY_AVS_DECL/>

<SCC_EPAY_AVSFLAG/>
<SCC_EPAY_DECSN_MGR/>
<SCC_EPAY_COMMENT/>
<EC_SETTLE_METHOD/>
<EC_VERIFICATION/>
<SCC_EPAY_ACH_CLASS IsChanged="Y">POP</SCC_EPAY_ACH_CLASS>
<SCC_EPAY_IP_ADDR/>
<SCC_EPAY_SECRET IsChanged="Y"> </SCC_EPAY_SECRET>
<SCC_EPAY_SECRETVAL IsChanged="Y"> </SCC_EPAY_SECRETVAL>
<SCC_EPAY_DECRYPT/>
<SCC_EPAY_PARAMCHK/>
<SCC_EPAY_SETTLENOW IsChanged="Y"> </SCC_EPAY_SETTLENOW>
<SCC_EPAY_FSRISK/>
<SCC_EPAY_FSTHRES IsChanged="Y">0</SCC_EPAY_FSTHRES>
<SCC_EPAY_FSCMOD/>
<SCC_EPAY_FSCGIFT/>
<SCC_EPAY_FSCLNGTRM/>
<SCC_EPAY_FSCTIME/>
<SCC_EPAY_FSHOSTHDG/>
<SCC_EPAY_FSTIMEHDG/>
<SCC_EPAY_FSVELHDG/>
<SCC_EPAY_AGREE_NBR/>
<AGREEMENT_DT IsChanged="Y">2009-11-16</AGREEMENT_DT>
<AGREEMENT_TEXT IsChanged="Y">Sample Agreement Text used for testing only.</
AGREEMENT_TEXT>
<SCC_EPAY_PAYDAT class="R">
<SCC_EPAY_INV class="R">
<SCC_EPAY_TOTAL_AMT IsChanged="Y">100</SCC_EPAY_TOTAL_AMT>
<SCC_EPAY_COMMENT/>
<CURRENCY_CD IsChanged="Y">USD</CURRENCY_CD>
<SCC_EPAY_CUSTID/>
<SCC_EPAY_FNAME IsChanged="Y">Joe</SCC_EPAY_FNAME>
<SCC_EPAY_LNAME IsChanged="Y">Smith</SCC_EPAY_LNAME>
<SCC_EPAY_FULLNAME/>
<SCC_EPAY_EMAIL IsChanged="Y">js@ps.com</SCC_EPAY_EMAIL>
<PHONE IsChanged="Y">818/922-2275</PHONE>
<FAX/>
<SCC_EPAY_DL_NO/>
<SCC_EPAY_DL_STATE/>
<ADDRESS1 IsChanged="Y">15821 Ventura Blvd</ADDRESS1>
<ADDRESS2 IsChanged="Y">ADDRESS2</ADDRESS2>
<CITY IsChanged="Y">Encino</CITY>
<STATE IsChanged="Y">CA</STATE>
<POSTAL IsChanged="Y">91346</POSTAL>

<COUNTRY IsChanged="Y">USA</COUNTRY>
</SCC_EPAY_ADDR2>
<PSCAMA class="R">
<AUDIT_ACTN>A</AUDIT_ACTN>
</PSCAMA>
</SCC_EPAY_BILLTO>
<PSCAMA class="R">
</PSCAMA>
</SCC_EPAY_INV>
<PSCAMA class="R">
</PSCAMA>
</SCC_EPAY_PAYDAT>
<PSCAMA class="R">
</PSCAMA>
<SCC_EPAY_PAYMETHOD/>
<SCC_EPAY_TYPE IsChanged="Y">VI</SCC_EPAY_TYPE>
<SCC_EPAY_NUMBER IsChanged="Y">4111-1111-1111-1111</SCC_EPAY_NUMBER>
<SCC_EPAY_EXPYR IsChanged="Y">2010</SCC_EPAY_EXPYR>
<SCC_EPAY_EXPMO IsChanged="Y">10</SCC_EPAY_EXPMO>
<SCC_EPAY_CVNUM/>
<SCC_EPAY_MAGDATA/>
</SCC_EPAY_CARD>
<PSCAMA class="R">
</PSCAMA>
<SCC_EPAY_ACCT_TYPE IsChanged="Y">C</SCC_EPAY_ACCT_TYPE>
<SCC_EPAY_BANK_CD IsChanged="Y">121042882</SCC_EPAY_BANK_CD>
<SCC_EPAY_ACCT_NBR IsChanged="Y">4100</SCC_EPAY_ACCT_NBR>
<SCC_EPAY_CHECK_NBR IsChanged="Y">0</SCC_EPAY_CHECK_NBR>
</SCC_EPAY_ACCT>
<PSCAMA class="R">
</PSCAMA>
<SCC_EPAY_SUBSCR class="R">
<SCC_EPAY_SUB_ID/>
<SCC_EPAY_DISBLAATH/>
<SCC_EPAY_SUBCRSRVC IsChanged="Y">T</SCC_EPAY_SUBCRSRVC>
<SCC_EPAY_EVENTACTN/>
<SCC_EPAY_EVENTSRVC IsChanged="Y">T</SCC_EPAY_EVENTSRVC>
<SCC_EPAY_GETSRVC IsChanged="Y">T</SCC_EPAY_GETSRVC>
<SCC_EPAY_UPDSRVC IsChanged="Y">T</SCC_EPAY_UPDSRVC>
<SCC_EPAY_APPROVAL/>

<SCC_EPAY_AUTORENEW/>
<SCC_EPAY_BILLPAY/>
<SCC_EPAY_RECUR_AMT IsChanged="Y">0</SCC_EPAY_RECUR_AMT>
<SCC_EPAY_SETUP_AMT IsChanged="Y">0</SCC_EPAY_SETUP_AMT>
<SCC_EPAY_EAPPR_BY/>
<SCC_EPAY_EVENT_NBR IsChanged="Y">0</SCC_EPAY_EVENT_NBR>
<SCC_EPAY_EVNT_FREQ/>
<SCC_EPAY_NBR_PYMNT IsChanged="Y">0</SCC_EPAY_NBR_PYMNT>
<SCC_EPAY_STARTDATE/>
<SCC_EPAY_END_DT/>
<SCC_EPAY_STATUS/>
<SCC_EPAY_SUB_METHD/>
<SCC_EPAY_SUB_TITLE/>
</SCC_EPAY_SUBSCR>
<PSCAMA class="R">
</PSCAMA>
</SCC_EPAY_TENDER>
<PSCAMA class="R">
</PSCAMA>
</SCC_EPAY_TRNTYP>
<PSCAMA class="R">
</PSCAMA>
</SCC_EPAY_TRANS>
<PSCAMA class="R">
</PSCAMA>
</SCC_EPAY_RQST>
<PSCAMA class="R">
</PSCAMA>
</SCC_EPAY_XMLPAY>
<PSCAMA class="R">
<LANGUAGE_CD>ENG</LANGUAGE_CD>
<BASE_LANGUAGE_CD>ENG</BASE_LANGUAGE_CD>
<MSG_SEQ_FLG/>
<PROCESS_INSTANCE>0</PROCESS_INSTANCE>
<PUBLISH_RULE_ID/>
<MSGNODENAME/>
</PSCAMA>
</Transaction>
</MsgData>
</SCC_EPAY_SYNC>

The table below shows relevant fields of the Integration Broker Request Message structure. Message properties that are
currently referenced in application code via the Transaction Request application class are highlighted in YELLOW and marked
with an “(A)”. Properties that are defaulted via the ePayment adapter using values from the Payment Merchant setup are in
AQUA and marked with a “(D)”.
IB Message (IntegrationBrokerAdapter) Property Definition
SCC_EPAY_SYNC
SCC_EPAY_TRNTYP.SCC_EPAY_TRANSACT (A) The transaction code property is used to identify the type of transaction that is
being processed.
Current valid values:

* 1 (Authorize Only - CC)
* 2 (Authorize and Bill - CC)
* 3 (Bill Only - CC)
* 4 (Credit Only - CC)
* 5 (Make Payment - ACH)
* 6 (Apply Credit - ACH)
* 91 (Get Token - HPay)
* 92 (Authorize Only - HPay)
* 93 (Credit Only - HPay)
This property must be set by the invoking application code.
SCC_EPAY_RQST.SCC_EPAY_MERCHANT (A) This property holds the actual Merchant ID that is used when integrating with
the payment provider (MERCHANT_ID). It is defaulted in by code in the
abstractAdapter class. This property should not be set by the invoking
application code.
SCC_EPAY_TRANS.SCC_EPAY_MERCH_REF (A) This property holds the unique reference ID used to track transactions in the
SCC_EPAY_XMLPAY.SCC_EPAY_UNIQUE_ID (A) third party vendor's site and must be set by the invoking application code.
SCC_EPAY_TRANS.SCC_EPAY_TRANS_REF (A) This property is used to identify a prior transaction for follow-on transaction
or reporting purposes.
SCC_EPAY_TRANS.SCC_EPAY_RQST_ID (A) Request ID property is used to identify a prior transaction for follow-on
transaction purposes.
SCC_EPAY_TRANS.SCC_EPAY_RQST_TOKN (A) Request Token property is used to identify a prior transaction for follow-on
SCC_EPAY_TRANS.SCC_EPAY_SEC_KEY (D) Transaction security token is used to hold any security-related token that may
be required by a payment provider for transaction processing purposes.
SCC_EPAY_TRANS.SCC_EPAY_SESSIONID (A) The Session ID property is used as the unique session identifier for Hosted
Payment transactions. It is needed for most Hosted Payment transactions to
identify the specific session that was used to enter the ePayment transaction on
the third party hosted payment vendor's site.
SCC_EPAY_TRNTYP.SCC_EPAY_SETTLENOW This property is sometimes used on credit card capture transactions to request
an immediate settlement for a batch. This property may not be supported by
all payment providers.
SCC_EPAY_TRNTYP.SCC_EPAY_AVSFLAG (A) This property can be used by credit card authorization transactions to request
optional address verification services. This property is defaulted in from the

SCC_EPAY_SYNC
Payment Manager setup if not filled in. This property does not need to be set
by the invoking application code.
SCC_EPAY_TRNTYP.EC_VERIFICATION (D) This property can be used to set the verification level for eCheck (ACH)
transactions. It may not be used by all payment providers.
SCC_EPAY_TRNTYP.EC_SETTLE_METHOD (D) This property can hold the settle method needed for eCheck (ACH)
transactions to identify the desired settlement delivery method.
SCC_EPAY_TRNTYP.SCC_EPAY_SECRET (A) This property can hold the description of the shared secret. It can be used for
Hosted Payment transactions to help authenticate or verify the identity of the
person entering credit card or eCheck transaction information on an externally
hosted third party hosted payment vendor's site.
SCC_EPAY_TRNTYP.SCC_EPAY_SECRETVAL (A) This property can hold the value of the shared secret. It can be used for
SCC_EPAY_TRNTYP.SCC_EPAY_ACH_CLASS (D) Can be used to relate the class of the ACH or eCheck transaction.
SCC_EPAY_TRNTYP.SCC_EPAY_IP_ADDR (D) Can be used to send ip address-related information. It is sometimes needed to

identify the ip address of the client where the eCheck (ACH) transaction
originated as a fraud detection mechanism by the payment provider.
SCC_EPAY_TRANS.SCC_PMT_APPL (A) Can be used to identify the source of the transaction. It is currently used to
hold application id for hosted payment transactions.
SCC_EPAY_TRANS.SCC_EPAY_MISC_LONG Can be used to hold miscellaneous data that cannot be sent in any of the other
properties.
SCC_EPAY_TRANS.SCC_EPAY_AGREE_NBR This property is designed to hold the agreement id that is sometimes needed
for eCheck transactions.
SCC_EPAY_TRANS.AGREEMENT_DT (A) This property is designed to hold the agreement data that is sometimes needed
SCC_EPAY_TRANS.AGREEMENT_TEXT (A) This property is designed to hold the agreement text that is sometimes needed
SCC_EPAY_TENDER.SCC_EPAY_PAYMETHOD Can be used to identify the payment method (such as credit card or eCheck) of
the transaction.
SCC_EPAY_TRNTYP.SCC_EPAY_COMMENT Can be used to send comments associated with the ePayment transaction.
SCC_EPAY_TRNTYP.SCC_EPAY_FSRISK (A) Can be used to hold data that can be used by CyberSource's Decision Manager
Advanced Fraud Screen feature.
SCC_EPAY_TRNTYP.SCC_EPAY_FSTHRES (A) Can be used to hold data that can be used by CyberSource's Decision Manager
SCC_EPAY_TRNTYP.SCC_EPAY_FSCMOD Can be used to hold data that can be used by CyberSource's Decision Manager

SCC_EPAY_SYNC
SCC_EPAY_TRNTYP.SCC_EPAY_FSCGIFT Can be used to hold data that can be used by CyberSource's Decision Manager
SCC_EPAY_TRNTYP.SCC_EPAY_FSCLNGTRM Can be used to hold data that can be used by CyberSource's Decision Manager
SCC_EPAY_TRNTYP.SCC_EPAY_FSCTIME Can be used to hold data that can be used by CyberSource's Decision Manager
SCC_EPAY_TRNTYP.SCC_EPAY_FSHOSTHDG Can be used to hold data that can be used by CyberSource's Decision Manager
SCC_EPAY_TRNTYP.SCC_EPAY_FSTIMEHDG Can be used to hold data that can be used by CyberSource's Decision Manager
SCC_EPAY_TRNTYP.SCC_EPAY_FSVELHDG Can be used to hold data that can be used by CyberSource's Decision Manager
SCC_EPAY_BILLTO.SCC_EPAY_FNAME (A) This property holds the first name of the account owner (credit card or eCheck
account).
SCC_EPAY_BILLTO.SCC_EPAY_LNAME (A) This property holds the last name of the account owner (credit card or eCheck
account).
SCC_EPAY_BILLTO.SCC_EPAY_FULLNAME This property holds the full name of the account owner (credit card or eCheck
account).
SCC_EPAY_BILLTO.SCC_EPAY_EMAIL (A) This property holds the email address of the account owner (credit card or
eCheck account).
SCC_EPAY_BILLTO.PHONE (A) This property holds the phone number of the account owner (credit card or
eCheck account).
SCC_EPAY_INV.SCC_EPAY_TOTAL_AMT (A) This property holds the amount of the transaction.
SCC_EPAY_INV.CURRENCY_CD (A) This property holds the currency code of the transaction.
SCC_EPAY_ADDR2.ADDRESS1 (A) This property holds the first line of the address for the owner of the account
(credit card or eCheck account)
SCC_EPAY_ADDR2.ADDRESS2 (A) This property holds the second line of the address for the owner of the account
SCC_EPAY_ADDR2.ADDRESS3 (A) This property holds the third line of the address for the owner of the account
SCC_EPAY_ADDR2.ADDRESS4 (A) This property holds the fourth line of the address for the owner of the account
SCC_EPAY_ADDR2.CITY (A) This property holds the city portion of the address for the owner of the account

SCC_EPAY_SYNC
SCC_EPAY_ADDR2.STATE (A) This property holds the state code portion of the address for the owner of the
account (credit card or eCheck account)
SCC_EPAY_ADDR2.POSTAL (A) This property holds the zip code portion of the address for the owner of the
SCC_EPAY_ADDR2.COUNTRY (A) This property holds the country code portion of the address for the owner of
the account (credit card or eCheck account)
SCC_EPAY_CARD.SCC_EPAY_TYPE (A) This property holds the type of credit card.
SCC_EPAY_CARD.SCC_EPAY_NUMBER (A) This property holds the credit card account number.
SCC_EPAY_CARD.SCC_EPAY_EXPYR (A) This property holds the expiration year of the credit card.
SCC_EPAY_CARD.SCC_EPAY_EXPMO (A) This property holds the expiration month of the credit card.
SCC_EPAY_CARD.SCC_EPAY_CVNUM (A) This property holds the Security code (CVV, CSC, etc.) value of the credit
card.
SCC_EPAY_ACCT.SCC_EPAY_BANK_CD (A) This property holds the bank code for the eCheck transaction.
SCC_EPAY_ACCT.SCC_EPAY_ACCT_TYPE (A) This property holds the account type for the eCheck transaction.
SCC_EPAY_ACCT.SCC_EPAY_ACCT_NBR (A) This property holds the bank account for the eCheck transaction.
SCC_EPAY_ACCT.SCC_EPAY_CHECK_NBR This property holds the check number for the eCheck transaction.
SCC_EPAY_BILLTO.SCC_EPAY_DL_NO This property holds the drivers license number sometimes used in ePayment
transactions.
SCC_EPAY_BILLTO.SCC_EPAY_DL_STATE This property holds the drivers license state code sometimes used in ePayment
transactions.

APPENDIX B: RESPONSE MESSAGE STRUCTURE AND PROPERTIES
Sample Response Message:
<?xml version="1.0"?>
<SCC_EPAY_RESPONSE>
<FieldTypes>
<SCC_EPAY_XMLRSP class="R">
<SCC_EPAY_UNIQUE_ID type="CHAR"/>
</SCC_EPAY_XMLRSP>
<CITY type="CHAR"/>
<STATE type="CHAR"/>
<POSTAL type="CHAR"/>
<COUNTRY type="CHAR"/>
</SCC_EPAY_ADDR2>
<SCC_EPAY_TRRSLT class="R">
<SCC_EPAY_TRANSACT type="CHAR"/>
<SCC_EPAY_TRANS_REF type="CHAR"/>
<SCC_EPAY_TRANSTYPE type="CHAR"/>
<SCC_EPAY_RQST_ID type="CHAR"/>
<SCC_PMT_APPL type="CHAR"/>
<SCC_EPAY_RESULT type="NUMBER"/>
<SCC_EPAY_ORIGRSLT type="NUMBER"/>
<SCC_EPAY_RET_MSG type="CHAR"/>
<SCC_EPAY_AUTHCD type="CHAR"/>
<SCC_EPAY_DECISION type="CHAR"/>
<SCC_EPAY_TRSTAT type="NUMBER"/>
<SCC_EPAY_TRSTATMSG type="CHAR"/>
<SCC_EPAY_RESP_CD type="CHAR"/>

<SCC_EPAY_REASON_CD type="CHAR"/>
<SCC_EPAY_HOSTCODE type="CHAR"/>
<SCC_EPAY_HOST_URL type="CHAR"/>
<SCC_EPAY_AVS type="CHAR"/>
<SCC_EPAY_RAWAVS type="CHAR"/>
<SCC_EPAY_CVRESULT type="CHAR"/>
<SCC_EPAY_TOTAL_AMT type="NUMBER"/>
<SCC_EPAY_CR_AMT type="NUMBER"/>
<SCC_EPAY_DB_AMT type="NUMBER"/>
<CURRENCY_CD type="CHAR"/>
<SCC_EPAY_RESP_MTHD type="CHAR"/>
<SCC_EPAY_AUTHDTTM type="CHAR"/>
<SCC_EPAY_BANK_NAME type="CHAR"/>
<SCC_EPAY_BANKADDR type="CHAR"/>
<SCC_EPAY_BANKCSZ type="CHAR"/>
<SCC_EPAY_RECEIPT type="CHAR"/>
<SCC_EPAY_STAT_CD type="CHAR"/>
<SCC_EPAY_STAT_DSCR type="CHAR"/>
<SCC_EPAY_SESSIONID type="CHAR"/>
<SCC_EPAY_FSFACTORS type="CHAR"/>
<SCC_EPAY_FSHOSTSEV type="CHAR"/>
<SCC_EPAY_FS_RCODE type="CHAR"/>
<SCC_EPAY_FS_RFLAG type="CHAR"/>
<SCC_EPAY_FS_RMSG type="CHAR"/>
<SCC_EPAY_FSSCORE type="CHAR"/>
<SCC_EPAY_FSSCORETM type="CHAR"/>
<SCC_EPAY_AGREE_NBR type="CHAR"/>
<AGREEMENT_DT type="DATE"/>
<AGREEMENT_TEXT type="CHAR"/>
<SCC_EPAY_RQST_TOKN type="CHAR"/>
<SCC_EPAY_MISC_LONG type="CHAR"/>
</SCC_EPAY_TRRSLT>
<SCC_EPAY_TYPE type="CHAR"/>
<SCC_EPAY_NUMBER type="CHAR"/>
<SCC_EPAY_EXPYR type="CHAR"/>
<SCC_EPAY_EXPMO type="CHAR"/>
<SCC_EPAY_CVNUM type="CHAR"/>
<SCC_EPAY_MAGDATA type="CHAR"/>
</SCC_EPAY_CARD>
<SCC_EPAY_ACCT_TYPE type="CHAR"/>
<SCC_EPAY_BANK_CD type="CHAR"/>
<SCC_EPAY_ACCT_NBR type="CHAR"/>
<SCC_EPAY_CHECK_NBR type="NUMBER"/>
</SCC_EPAY_ACCT>
<SCC_EPAY_AVRSLT class="R">

<SCC_EPAY_MATCH_ST type="CHAR"/>
<SCC_EPAY_MATCH_ZIP type="CHAR"/>
</SCC_EPAY_AVRSLT>
<SCC_EPAY_PAYMETHOD type="CHAR"/>
</SCC_EPAY_TENDER>
<SCC_EPAY_CUSTID type="CHAR"/>
<SCC_EPAY_FNAME type="CHAR"/>
<SCC_EPAY_LNAME type="CHAR"/>
<SCC_EPAY_FULLNAME type="CHAR"/>
<SCC_EPAY_EMAIL type="CHAR"/>
<PHONE type="CHAR"/>
<FAX type="CHAR"/>
<SCC_EPAY_CUSTCODE type="CHAR"/>
<SCC_EPAY_PO_NUM type="CHAR"/>
<SCC_EPAY_TAXEXEMPT type="CHAR"/>
<SCC_EPAY_DL_NO type="CHAR"/>
<SCC_EPAY_DL_STATE type="CHAR"/>
</SCC_EPAY_BILLTO>
<SCC_EPAY_SUBRSP class="R">
<SCC_EPAY_SUB_ID type="CHAR"/>
<SCC_EPAY_REASON_CD type="CHAR"/>
<SCC_EPAY_UPDSUB_ID type="CHAR"/>
<SCC_EPAY_TRANSTYPE type="CHAR"/>
<SCC_EPAY_APPROVAL type="CHAR"/>
<SCC_EPAY_EAPPR_BY type="CHAR"/>
<SCC_EPAY_AUTORENEW type="CHAR"/>
<SCC_EPAY_BILLPAY type="CHAR"/>
<SCC_EPAY_EVENT_NBR type="NUMBER"/>
<SCC_EPAY_CUST_ID type="CHAR"/>
<SCC_EPAY_END_DT type="DATE"/>
<SCC_EPAY_EVNT_FREQ type="CHAR"/>
<SCC_EPAY_STATUS type="CHAR"/>
<SCC_EPAY_RECUR_AMT type="NUMBER"/>
<SCC_EPAY_SETUP_AMT type="NUMBER"/>
<SCC_EPAY_GETSTAT type="CHAR"/>
<SCC_EPAY_SUB_TITLE type="CHAR"/>
<SCC_EPAY_NBR_PYMNT type="NUMBER"/>
<SCC_EPAY_STARTDATE type="DATE"/>
</SCC_EPAY_SUBRSP>
<SCC_EPAY_RSPNS class="R">
<SCC_EPAY_MERCHANT type="CHAR"/>
<SCC_EPAY_PARTNER type="CHAR"/>
</SCC_EPAY_RSPNS>

<PSCAMA class="R">
<LANGUAGE_CD type="CHAR"/>
<AUDIT_ACTN type="CHAR"/>
<BASE_LANGUAGE_CD type="CHAR"/>
<MSG_SEQ_FLG type="CHAR"/>
<PROCESS_INSTANCE type="NUMBER"/>
<PUBLISH_RULE_ID type="CHAR"/>
<MSGNODENAME type="CHAR"/>
</PSCAMA>
</FieldTypes>
<MsgData>
<Transaction>
<SCC_EPAY_XMLRSP class="R">
<SCC_EPAY_UNIQUE_ID/>
<SCC_EPAY_RSPNS class="R">
<SCC_EPAY_MERCHANT/>
<SCC_EPAY_PARTNER/>
<SCC_EPAY_TRRSLT class="R">
<SCC_EPAY_TRANSACT/>
<SCC_EPAY_TRANS_REF IsChanged="Y">68131302V1YXBMS7</SCC_EPAY_TRANS_REF>
<SCC_EPAY_TRANSTYPE/>
<SCC_EPAY_RQST_ID IsChanged="Y">2583931401590008402433</SCC_EPAY_RQST_ID>
<SCC_EPAY_MERCH_REF/>
<SCC_PMT_APPL/>
<SCC_EPAY_RESULT>0</SCC_EPAY_RESULT>
<SCC_EPAY_ORIGRSLT IsChanged="Y">100</SCC_EPAY_ORIGRSLT>
<SCC_EPAY_RET_MSG IsChanged="Y">Transaction was successful.</SCC_EPAY_RET_MSG>
<SCC_EPAY_AUTHCD IsChanged="Y">888888</SCC_EPAY_AUTHCD>
<SCC_EPAY_DECISION IsChanged="Y">Success</SCC_EPAY_DECISION>
<SCC_EPAY_TRSTAT>0</SCC_EPAY_TRSTAT>
<SCC_EPAY_TRSTATMSG IsChanged="Y">Transaction was successful.</SCC_EPAY_
TRSTATMSG>
<SCC_EPAY_RESP_CD IsChanged="Y">100</SCC_EPAY_RESP_CD>
<SCC_EPAY_REASON_CD IsChanged="Y">100</SCC_EPAY_REASON_CD>
<SCC_EPAY_HOSTCODE/>
<SCC_EPAY_HOST_URL/>
<SCC_EPAY_AVS IsChanged="Y">X</SCC_EPAY_AVS>
<SCC_EPAY_RAWAVS IsChanged="Y">I1</SCC_EPAY_RAWAVS>
<SCC_EPAY_CVRESULT/>
<SCC_EPAY_TOTAL_AMT>0</SCC_EPAY_TOTAL_AMT>
<SCC_EPAY_CR_AMT>0</SCC_EPAY_CR_AMT>
<SCC_EPAY_DB_AMT>0</SCC_EPAY_DB_AMT>
<CURRENCY_CD/>
<SCC_EPAY_RESP_MTHD/>
<SCC_EPAY_AUTHDTTM IsChanged="Y">2009-11-16-09.39.01.000000</SCC_EPAY_
AUTHDTTM>
<SCC_EPAY_IP_ADDR/>
<SCC_EPAY_BANK_NAME/>

<SCC_EPAY_BANKADDR/>
<SCC_EPAY_BANKCSZ/>
<SCC_EPAY_RECEIPT/>
<SCC_EPAY_STAT_CD/>
<SCC_EPAY_STAT_DSCR/>
<SCC_EPAY_SESSIONID/>
<SCC_EPAY_FSFACTORS/>
<SCC_EPAY_FSHOSTSEV/>
<SCC_EPAY_FS_RCODE/>
<SCC_EPAY_FS_RFLAG/>
<SCC_EPAY_FS_RMSG/>
<SCC_EPAY_FSSCORE/>
<SCC_EPAY_FSSCORETM/>
<SCC_EPAY_AGREE_NBR/>
<AGREEMENT_DT/>
<AGREEMENT_TEXT/>
<SCC_EPAY_RQST_TOKN IsChanged="Y">Ahj/7wSRGCaA3vtLVqQCIkGzhizYs2DKsxs2IU2m3TZH
7g5rACmyP3BzWNIHTiEjRDJbpgFrLiC4E5EYJoDe+0tWpAIA9AxC</SCC_EPAY_RQST_TOKN>
<SCC_EPAY_MISC_LONG/>
</SCC_EPAY_TRRSLT>
</SCC_EPAY_RSPNS>
</SCC_EPAY_XMLRSP>
<PSCAMA class="R">
<LANGUAGE_CD>ENG</LANGUAGE_CD>
<AUDIT_ACTN/>
<BASE_LANGUAGE_CD>ENG</BASE_LANGUAGE_CD>
<MSG_SEQ_FLG/>
<PROCESS_INSTANCE>0</PROCESS_INSTANCE>
<PUBLISH_RULE_ID/>
<MSGNODENAME/>
</PSCAMA>
</Transaction>
</MsgData>
</SCC_EPAY_RESPONSE>

The table below shows relevant fields of the Integration Broker Response Message structure with message properties that are
currently referenced in application code via the Transaction Response application class are highlighted in YELLOW and
marked with an “(A)”.
SCC_EPAY_RESPONSE
SCC_EPAY_TRRSLT.SCC_EPAY_RESULT (A) Return Code property will contain a PeopleSoft specific return value
based on the response from the payment provider..
Values are:
0 (Success)
100-199 (Declined, OK to display to on-line users)
200-299 (Declined, not OK to display to on-line users.)
300-399 (Connection Error: ETIMEOUT - Internal error)
700-799 (PeopleSoft Error)
SCC_EPAY_TRRSLT.SCC_EPAY_ORIGRSLT The raw return code property will contain the return code returned
from the payment provider.
SCC_EPAY_TRRSLT.SCC_EPAY_REASON_CD The reason code property contains the reason code if one is returned
from the payment provider.
SCC_EPAY_TRRSLT.RET_MSG The return message property will contain a general description of the
return code (returnCode) property.
Example: "Required card data was not present or failed verification

check (CyberSource Return Code: -1702).";
SCC_EPAY_TRRSLT.SCC_EPAY_DECISION The decision property will contain a single word result for the
transaction (Success, Declined, Error).
SCC_EPAY_TRRSLT.SCC_EPAY_TRSTATMSG The transaction status message property (rtStatusMsg) will contain a

short undetailed explanation of the results(Transaction was successful,
Transaction was declined, or Processing error).
SCC_EPAY_TRRSLT.SCC_EPAY_AUTHCD (A) This property will contain the authorization code as returned by the
payment provider.
SCC_EPAY_TRRSLT.SCC_EPAY_AUTHDTTM This property will contain the authorization date time value as a string.
SCC_EPAY_TRRSLT.SCC_EPAY_AVS (A) This property will contain the returned AVS code.
SCC_EPAY_TRRSLT.SCC_EPAY_RAWAVS This property will contain the raw AVS code as returned by the
payment provider.
SCC_EPAY_AVRSLT.SCC_EPAY_MATCH_ZIP This property can hold zip code specific AVS processing codes if
available.
SCC_EPAY_AVRSLT.SCC_EPAY_MATCH_ST This property can hold street specific AVS processing codes if
available.
This property holds the merchant reference property that was sent with
the original request.

SCC_EPAY_RESPONSE
SCC_EPAY_TRRSLT.SCC_EPAY_TRANSID (A) This property is used to identify a prior transaction for follow-on
transaction or reporting purposes.
SCC_EPAY_TRRSLT.SCC_EPAY_RQST_ID (A) Request ID property is used to identify a prior transaction for follow-
on transaction purposes.
SCC_EPAY_TRRSLT.SCC_EPAY_RQST_TOKN (A) Request Token property is used to identify a prior transaction for
follow-on transaction purposes.
SCC_EPAY_TRRSLT.SCC_EPAY_DB_AMT This property can hold the debit amount.
SCC_EPAY_TRRSLT.SCC_EPAY_CR_AMT This property can hold the credit amount.
SCC_EPAY_TRRSLT.SCC_EPAY_CVRESULT (A) This property holds the result of processing the Security Code (CVV,
CSC, etc.).
SCC_EPAY_TRRSLT.SCC_EPAY_BANK_NAME This property holds the bank name from eCheck (ACH) transactions.
SCC_EPAY_TRRSLT.SCC_EPAY_BANKADDR This property holds the bank address from eCheck (ACH) transactions.
SCC_EPAY_TRRSLT.SCC_EPAY_BANKCSZ This property holds the bank city, state, and zip code from eCheck
(ACH) transactions.
SCC_EPAY_TRRSLT.SCC_EPAY_AGREE_NBR This property holds the agreement ID used for some eCheck
transactions.
SCC_EPAY_TRRSLT.AGREEMENT_TEXT This property holds the agreement text used for some eCheck
transactions.
SCC_EPAY_TRRSLT.AGREEMENT_DT This property holds the agreement date used for some eCheck
transactions.
SCC_EPAY_TRRSLT.SCC_EPAY_IP_ADDR This property can hold the ip address.
SCC_EPAY_TRRSLT.SCC_EPAY_STAT_CD This property can hold the status code of an ePayment transaction.
SCC_EPAY_TRRSLT.SCC_EPAY_STAT_DSCR This property can hold a description of the status code of an ePayment
transaction.
SCC_EPAY_TRRSLT.SCC_EPAY_SESSIONID (A) This property can hold the session id for hosted payment transactions.
SCC_EPAY_TRRSLT.SCC_EPAY_RESP_MTHD This property can hold the settle method used for eCheck transactions.
SCC_EPAY_TRRSLT.SCC_PMT_APPL Can be used to identify the source of the transaction. It is currently

used to hold application id for hosted payment transactions.
SCC_EPAY_TRRSLT.SCC_EPAY_MISC_LONG This is a general field that can be used to transmit general data that can
not be placed in other properties.
SCC_EPAY_TRRSLT.SCC_EPAY_FSFACTORS Can be used to hold data returned by CyberSource's Decision Manager

SCC_EPAY_TRRSLT.SCC_EPAY_FSHOSTSEV Can be used to hold data returned by CyberSource's Decision Manager

SCC_EPAY_RESPONSE
SCC_EPAY_TRRSLT.SCC_EPAY_FS_RCODE Can be used to hold data returned by CyberSource's Decision Manager

SCC_EPAY_TRRSLT.SCC_EPAY_FS_RFLAG Can be used to hold data returned by CyberSource's Decision Manager

SCC_EPAY_TRRSLT.SCC_EPAY_FS_RMSG Can be used to hold data returned by CyberSource's Decision Manager

SCC_EPAY_TRRSLT.SCC_EPAY_FSSCORE Can be used to hold data returned by CyberSource's Decision Manager

SCC_EPAY_TRRSLT.SCC_EPAY_FSSCORETM Can be used to hold data returned by CyberSource's Decision Manager

SCC_EPAY_BILLTO.SCC_EPAY_FNAME This property holds the first name of the account owner (credit card or
eCheck account).
SCC_EPAY_BILLTO.SCC_EPAY_LNAME This property holds the last name of the account owner (credit card or
eCheck account).
SCC_EPAY_BILLTO.SCC_EPAY_FULLNAME This property holds the full name of the account owner (credit card or
eCheck account).
SCC_EPAY_BILLTO.SCC_EPAY_EMAIL This property holds the email address of the account owner (credit card
or eCheck account).
SCC_EPAY_BILLTO.PHONE This property holds the phone number of the account owner (credit
card or eCheck account).
SCC_EPAY_TRRSLT.SCC_EPAY_TOTAL_AMT This property holds the amount of the transaction.
SCC_EPAY_TRRSLT.CURRENCY_CD This property holds the currency code of the transaction.
SCC_EPAY_ADDR2.ADDRESS1 This property holds the first line of the address for the owner of the
SCC_EPAY_ADDR2.ADDRESS2 This property holds the second line of the address for the owner of the
SCC_EPAY_ADDR2.ADDRESS3 This property holds the third line of the address for the owner of the
SCC_EPAY_ADDR2.ADDRESS4 This property holds the fourth line of the address for the owner of the
SCC_EPAY_ADDR2.CITY This property holds the city portion of the address for the owner of the
SCC_EPAY_ADDR2.STATE This property holds the state code portion of the address for the owner
of the account (credit card or eCheck account)

SCC_EPAY_RESPONSE
SCC_EPAY_ADDR2.POSTAL This property holds the zip code portion of the address for the owner
of the account (credit card or eCheck account)
SCC_EPAY_ADDR2.COUNTRY This property holds the country code portion of the address for the
owner of the account (credit card or eCheck account)
SCC_EPAY_CARD.SCC_EPAY_TYPE This property holds the type of credit card.
SCC_EPAY_CARD.SCC_EPAY_NUMBER This property holds the credit card account number.
SCC_EPAY_CARD.SCC_EPAY_EXPYR This property holds the expiration year of the credit card.
SCC_EPAY_CARD.SCC_EPAY_EXPMO This property holds the expiration month of the credit card.
SCC_EPAY_ACCT.SCC_EPAY_BANK_CD This property holds the bank code for the eCheck transaction.
SCC_EPAY_ACCT.SCC_EPAY_ACCT_TYPE This property holds the account type for the eCheck transaction.
SCC_EPAY_ACCT.SCC_EPAY_ACCT_NBR This property holds the bank account for the eCheck transaction.
SCC_EPAY_ACCT.SCC_EPAY_CHECK_NBR This property holds the check number for the eCheck transaction.
SCC_EPAY_BILLTO.SCC_EPAY_DL_NO This property holds the drivers license number sometimes used in
ePayment transactions.
SCC_EPAY_BILLTO.SCC_EPAY_DL_STATE This property holds the drivers license state code sometimes used in

APPENDIX C: CREATING A TRANSFORMATION PROGRAM USING APPLICATION

ENGINE (REQUEST)
Create a new Application Engine program using PeopleSoft Application Designer. This new process will transform outbound
request messages into the required format of your payment provider.
1. In the properties of the new program, click on the “Advanced” tab and update the Program Type to “Transform Only”,
enter the Input Message Name (SCC_EPAY_SYNC), the Input Message Version (VERSION_1), Output Message
Name (IB_GENERIC), and Output Message Version (VERSION_1). Once the values in the “Advanced” tab of the
AE Program Properties have been set, click “OK”.
2. Click on the “Step01” step of the AE Program directly under the “MAIN” section.
3. Click on the “Insert” Menu Bar Item and select “Action”.
4. Set the Action to “PeopleCode” or “XSLT” depending on how you wish to code the transformation.

5. Add your transformation logic to the Action and save the program. The provided samples below are located in
“Appendix Z: Code Samples”.
a. Request Sample 1: Request Transformation PeopleCode
b. Request Sample 2: Request Transformation PeopleCode
c. Request Sample 3: Request Transformation PeopleCode (Hosted Payment Transactions Only)

APPENDIX D: CREATING A TRANSFORMATION PROGRAM USING APPLICATION

ENGINE (RESPONSE)
Create a new Application Engine program to process the inbound transformation (response).
1. In the properties of the new program, click on the “Advanced” tab and update the Program Type to “Transform Only”,
enter the Input Message Name (IB_GENERIC), the Input Message Version (VERSION_1), Output Message Name
(SCC_EPAY_RESPONSE), and Output Message Version (VERSION_1). Once the values in the “Advanced” tab of
the AE Program Properties have been set click “OK”.
2. Click on the “Step01” step of the AE Program directly under the “MAIN” section.
3. Click on the “Insert” Menu Bar Item and select “Action”.
4. Set the Action to “PeopleCode” or “XSLT” depending on how you wish to code the transformation.

5. Add your transformation logic to the Action and save the program. The provided samples below are located in
“Appendix Z: Code Samples”.
a. Response Sample 1: Response Transformation PeopleCode
b. Response Sample 2: Response Transformation PeopleCode
c. Response Sample 3: Response Transformation PeopleCode (Hosted Payment Transactions Only)

APPENDIX E: CREATING AN INTEGRATION BROKER NODE FOR YOUR PAYMENT

PROVIDER
to help with the routing of the transaction to the payment provider.
Informational: Please review the Enterprise PeopleTools 8.49 PeopleBook: PeopleSoft Integration Broker (Adding and
Configuring Nodes section) for proper instruction on how to add and configure Integration Broker Nodes. The following
instructions are supplied here as only an “example” of how this can be done.
1. Log in to your Campus Solutions environment using PIA and navigate to the Node Setup component (PeopleTools >
Integration Broker > Integration Setup > Nodes).
2. Click “Add a New Value” tab at the top of the search page.
3. Enter the name you wish to use for this vendor and click the “Add” button.
4. Enter the required information for your vendor.

5. Click on the “Connectors” tab on the top of the page and fill in the page appropriately with values relevant for your
external third party payment provider.
a. Most integrations will be performed using the HTTPTARGET connector as shown below.
b. Some properties of the HTTPTARGET connector that you may need to use are:
i. Property ID: HEADER, Property Name: sendUncompressed, Value: Y
ii. Property ID: HTTPPROPERTY, Property Name: Method, Value: POST
iii. Property ID: PRIMARYURL, Property Name: URL, Value: [This value needs to come from your
payment provider. It represents the location of where to send your ePayment transactions.]
iv. Property ID: HEADER, Property Name: Content-Type, Value: text/xml; charset-utf-8

6. Save the node.
7. Test the Node setup by clicking the “Ping Node”. You should see that the Node pings successfully.
Informational: The URL property shown above will need to come from your payment provider. It represents the location of
where you should direct or route your ePayment transactions.

APPENDIX F: UPDATING THE EXISTING SERVICE OPERATION AND CREATING

THE REQUIRED ROUTING
1. Log in to your environment using PIA and navigate to the Service Operations Setup component (PeopleTools >
Integration Broker > Integration Setup > Service Operations).
2. Enter “SCC_EPAYMENT_SYNC” in the Service Operation search field and click “Search”.
3. Make sure the Service Operation is active (See “Active” checkbox) and that the “SCC_EPAY_SYNC.VERSION_1”
and “SCC_EPAY_RESPONSE.VERSION_1” messages appear in the Message.Version field of the Message
Information group box (update the Service Operation if the values have not been filled in or are different than those
suggested here).
4. Click on the “Routings” tab at the top of the page.

5. Add a Routing Name as shown above and click the “Add” button.
6. Enter values for the Routing Active checkbox (should be set to active), Description, Sender Node (generally the
default local node), Receiver Node (your payment provider‟s node, created earlier), Object Owner ID, and Log Detail
preference (note that the Header and Detail option is nice to have in your development environment but not advisable
for your production environment), and User Exception (generally unchecked unless you are interfacing with a vendor
who often returns SOAP faults for unsuccessful transactions, including declines).
7. Click “Save” to save your work.
8. Click on the Parameters tab at the top of the page.

9. Enter values into the Parameters group box for Type “Outbound Request”:
a. Set Message.Ver into Transform 1 to “SCC_EPAY_SYNC.VERSION_1”.
b. Set Transform Program 1 to “QA_DEMORQST” (set to the REQUEST transformation program, created
earlier).
c. Set Message.Ver out of Transforms to “IB_GENERIC.VERSION_1”.
10. Enter values into the Parameters group box for Type “Inbound Response”:
a. Set Message.Ver into Transform 1 to “IB_GENERIC.VERSION_1”.
b. Set Transform Program 1 to “QA_DEMORESP” (set to the RESPONSE transformation program, created
earlier).

c. Set Message.Ver out of Transforms to “SCC_EPAY_RESPONSE.VERSION_1”.
11. Click “Save” to save your work.
12. Click on the “Connector Properties” tab only if you need to override your Connector Properties that exist on the Node
referenced as the Receiver Node from the first page of the Routing setup (this value should be pointing to the newly
created external payment provider Node). This would be required only if you want this Service Operation‟s Routing
to have different Connector Properties (such as pointing to a different primary URL) than the targeted Receiver Node.
Informational: You can choose to use the supplied Campus Solutions‟ Service Operation (SCC_EPAYMENT_SYNC) or you
can create new Service Operations provided they work with the selected ePayment Adapter. The delivered Integration Broker
adapter is designed to use the SCC_EPAY_SYNC and SCC_EPAY_RESPONSE messages. Any Service Operation that needs
to work with the delivered Integration Broker adapter needs to use the SCC_EPAY_SYNC and SCC_EPAY_RESPONSE
message structures.

APPENDIX G: TRANSACTION CLASS

The transaction class acts as a container for the transaction data. It is used by both the Electronic Payment API and the Hosted
Payment API to pass payment related transaction data in and out of various objects and structures. It houses both the request
and response data represented as properties of the Transaction class.
TransactionRequest Class Properties
Transaction Data Class
SCC_EPAYMENT.TransactionRequest Property Definition

(Properties)
property string transCode get set; The transaction code property is used to identify the type of transaction that is
being processed.
Current valid values:

* 1 (Authorize Only - CC)
* 2 (Authorize and Bill - CC)
* 3 (Bill Only - CC)
* 4 (Credit Only - CC)
* 5 (Make Payment - ACH)
* 6 (Apply Credit - ACH)
* 91 (Get Token - HPay)
* 92 (Authorize Only - HPay)
* 93 (Credit Only - HPay)
This property must be set by the invoking application code.
property string merchantSetupID; The Merchant Setup ID property holds the CS Merchant ID
(SCC_MERCHANT_ID) and should be set by the invoking application code.
property string merchantID; This property holds the actual Merchant ID that is used when integrating with the
payment provider (MERCHANT_ID). It is defaulted in by code in the
abstractAdapter class. This property does not need to be set by the invoking
application code.


(Properties)
property string serviceOperation; This property is used by Integration Broker-based adapters. It identifies the
Integration Broker Service Operation that should be used to process the ePayment
transaction. This property is defaulted in from the Payment Manager setup if not
filled in. This property does not need to be set by the invoking application code.
property string serverHost; This property holds the location of the Process Server used by the Business
Interlink-based integration. It is currently used by the credit card and eCheck
business interlinks (server_host input property). This property is defaulted in
from the Payment Manager setup if not filled in. This property does not need to
be set by the invoking application code.
property string ipOverride; This property is currently used by the credit card and eCheck business interlinks in
the ip_address input property. We are also using this field as a default ip address
for transactions processed by our Integration Broker-based adapter. This property
is defaulted in from the Payment Manager setup if not filled in. This property
does not need to be set by the invoking application code.
property string trace; This property is currently used by the Business Interlink-based adapter to set the
trace input property of the credit card and eCheck business interlinks.
property string merchantRef; This property holds the unique reference ID used to track transactions in the third
party vendor's site. must be set by the invoking application code.
property string transRefID; This property is used to identify a prior transaction for follow-on transaction or
reporting purposes.
property string requestID; Request ID property is used to identify a prior transaction for follow-on
property string requestToken; Request Token property is used to identify a prior transaction for follow-on
property string transSecToken; Transaction security token is used to hold any security-related token that may be
required by a payment provider for transaction processing purposes.
property string sessionID; The Session ID property is used as the unique session identifier for Hosted
Payment transactions. It is needed for most Hosted Payment transactions to
identify the specific session that was used to enter the ePayment transaction on the
third party hosted payment vendor's site.
property string settleNow; This property is sometimes used on credit card capture transactions to request an
immediate settlement for a batch. This property may not be supported by all
payment providers.
property string AVSflag; This property can be used by credit card authorization transactions to request
optional address verification services. This property is defaulted in from the
Payment Manager setup if not filled in. This property does not need to be set by
the invoking application code.


(Properties)
property string verification; This property can be used to set the verification level for eCheck (ACH)
transactions. It may not be used by all payment providers.
property string settleMethod; This property can hold the settle method needed for eCheck (ACH) transactions to
identify the desired settlement delivery method.
property string secretDescr; This property can hold the description of the shared secret. It can be used for
property string secretValue; This property can hold the value of the shared secret. It can be used for Hosted
Payment transactions to help authenticate or verify the identity of the person
entering credit card or eCheck transaction information on an externally hosted
third party hosted payment vendor's site.
property string achClass; Can be used to relate the class of the ACH or eCheck transaction.
property string ipAddress; Can be used to send ip address-related information. It is sometimes needed to
identify the ip address of the client where the eCheck (ACH) transaction
originated as a fraud detection mechanism by the payment provider.
property string transactionSource; Can be used to identify the source of the transaction. It is currently used to hold
application id for hosted payment transactions.
property string miscIn; Can be used to hold miscellaneous data that can not be sent in any of the other
properties.
property string agreementID; This property is designed to hold the agreement id that is sometimes needed for
property string agreementDate; This property is designed to hold the agreement data that is sometimes needed for
property string agreementText; This property is designed to hold the agreement text that is sometimes needed for
property string paymentMethod; Can be used to identify the payment method (such as credit card or eCheck) of the
transaction.
property string comments; Can be used to send comments associated to the ePayment transaction.
property string scoreRisk; Can be used to hold data that can be used by CyberSource's Decision Manager
property string scoreThreshold; Can be used to hold data that can be used by CyberSource's Decision Manager
property string scoreRiskModify; Can be used to hold data that can be used by CyberSource's Decision Manager


(Properties)
property string scoreCatGift; Can be used to hold data that can be used by CyberSource's Decision Manager
property string scoreCatLongTerm; Can be used to hold data that can be used by CyberSource's Decision Manager
property string scoreCatTime; Can be used to hold data that can be used by CyberSource's Decision Manager
property string hostHedge; Can be used to hold data that can be used by CyberSource's Decision Manager
property string timeHedge; Can be used to hold data that can be used by CyberSource's Decision Manager
property string velocityHedge; Can be used to hold data that can be used by CyberSource's Decision Manager
property string firstName; This property holds the first name of the account owner (credit card or eCheck
account).
property string lastName; This property holds the last name of the account owner (credit card or eCheck
account).
property string fullName; This property holds the full name of the account owner (credit card or eCheck
account).
property string email; This property holds the email address of the account owner (credit card or eCheck
account).
property string phone; This property holds the phone number of the account owner (credit card or
eCheck account).
property string amount; This property holds the amount of the transaction.
property string currencyCD; This property holds the currency code of the transaction.
property string addr1; This property holds the first line of the address for the owner of the account
property string addr2; This property holds the second line of the address for the owner of the account
property string addr3; This property holds the third line of the address for the owner of the account
property string addr4; This property holds the fourth line of the address for the owner of the account
property string city; This property holds the city portion of the address for the owner of the account


(Properties)
property string state; This property holds the state code portion of the address for the owner of the
property string zip; This property holds the zip code portion of the address for the owner of the
property string country; This property holds the country code portion of the address for the owner of the
property string ccType; This property holds the type of credit card.
property string ccNum; This property holds the credit card account number.
property string expYR; This property holds the expiration year of the credit card.
property string expMO; This property holds the expiration month of the credit card.
property string cvv; This property holds the CVV value of the credit card.
property string bankCD; This property holds the bank code for the eCheck transaction.
property string bankAcctType; This property holds the account type for the eCheck transaction.
property string bankAcctNum; This property holds the bank account for the eCheck transaction.
property string checkNum; This property holds the check number for the eCheck transaction.
property string DLNumber; This property holds the drivers license number sometimes used in ePayment
transactions.
property string DLState; This property holds the drivers license state code sometimes used in ePayment
transactions.
property string subID; This property is intended to be used with subscription (or profile) related
transactions and is not currently used.
property string subTitle; This property is intended to be used with subscription (or profile) related
property string disableAutoAuth; This property is intended to be used with subscription (or profile) related
property string createService; This property is intended to be used with subscription (or profile) related
property string eventUpdateAction; This property is intended to be used with subscription (or profile) related
property string eventUpdate; This property is intended to be used with subscription (or profile) related
property string getService; This property is intended to be used with subscription (or profile) related


(Properties)
property string updateService; This property is intended to be used with subscription (or profile) related
property string subAmt; This property is intended to be used with subscription (or profile) related
property number setupAmt; This property is intended to be used with subscription (or profile) related
property string approvalRequired; This property is intended to be used with subscription (or profile) related
property string approvedBy; This property is intended to be used with subscription (or profile) related
property string autoRenew; This property is intended to be used with subscription (or profile) related
property string billPay; This property is intended to be used with subscription (or profile) related
property string eventNumber; This property is intended to be used with subscription (or profile) related
property string frequency; This property is intended to be used with subscription (or profile) related
property string nbrPayments; This property is intended to be used with subscription (or profile) related
property string subStartDate; This property is intended to be used with subscription (or profile) related
property string subEndDate; This property is intended to be used with subscription (or profile) related
property string subStatus; This property is intended to be used with subscription (or profile) related
property string subMethod; This property is intended to be used with subscription (or profile) related

TransactionResponse Class Properties

(Properties)
property string returnCode; Return Code property will contain a Peoplesoft-specific return value based
on the response from the payment provider..
Values are:
0 (Success)
100-199 (Declined, OK to display to on-line users)
200-299 (Declined, not OK to display to on-line users.)
300-399 (Connection Error: ETIMEOUT - Internal error)
700-799 (PeopleSoft Error)
property string rawReturnCode; The raw return code property will contain the return code returned from the
payment provider.
property number reasonCode; The reason code property contains the reason code if one is returned from the
payment provider.
property string returnMsg; The return message property will contain a general description of the return
code (returnCode) property.
Example: "Required card data was not present or failed verification check
(CyberSource Return Code: -1702).";
property string decision; The decision property will contain a single word result for the transaction
(Success, Declined, Error).
property string trStatusMsg; The transaction status message property (rtStatusMsg) will contain a short
undetailed explanation of the results(Transaction was successful, Transaction
was declined, or Processing error).
property string merchantID; This property will contain the merchant id of the transaction.
property datetime procDttm; This property will contain the process date time in date time format.
property string authCode; This property will contain the authorization code as returned by the payment
provider.
property string authDttm; This property will contain the authorization date time value as a string.
property string AVS; This property will contain the returned AVS code.
property string rawAVS; This property will contain the raw AVS code as returned by the payment
provider.
property string zipAVS; This property can hold zip code specific AVS processing codes if available.
property string stAVS; This property can hold street specific AVS processing codes if available.
property string merchantRef; This property holds the merchant reference property that was sent with the
original request.


(Properties)
property string transRefID; This property is used to identify a prior transaction for follow-on transaction
or reporting purposes.
property string requestID; Request ID property is used to identify a prior transaction for follow-on
property string requestToken; Request Token property is used to identify a prior transaction for follow-on
property string debit_amt; This property can hold the debit amount.
property string credit_amt; This property can hold the credit amount.
property string cvResult; This property holds the result of processing the Security Code (CVV, CSC,
etc.).
property string bankName; This property holds the bank name from eCheck (ACH) transactions.
property string bankAddr; This property holds the bank address from eCheck (ACH) transactions.
property string bankCSZ; This property holds the bank city, state, and zip code from eCheck (ACH)
transactions.
property string agreementID; This property holds the agreement ID used for some eCheck transactions.
property string agreementText; This property holds the agreement text used for some eCheck transactions.
property date agreementDate; This property holds the agreement date used for some eCheck transactions.
property string ipAddress; This property can hold the ip address.
property string statusCode; This property can hold the status code of an ePayment transaction.
property string statusDescr; This property can hold a description of the status code of an ePayment
transaction.
property string sessionID; This property can hold the session id for hosted payment transactions.
property string settleMethod; This property can hold the settle method used for eCheck transactions.
property string transactionSource; Can be used to identify the source of the transaction. It is currently used to
hold application id for hosted payment transactions.
property string miscOut; This is a general field that can be used to transmit general data that can not
be placed in other properties.
property string comments; Can be used to send comments associated to the ePayment transaction.
property string scoreFactors; Can be used to hold data returned by CyberSource's Decision Manager


(Properties)
property string hostSeverity; Can be used to hold data returned by CyberSource's Decision Manager
property string rCode; Can be used to hold data returned by CyberSource's Decision Manager
property string rFlag; Can be used to hold data returned by CyberSource's Decision Manager
property string rMsg; Can be used to hold data returned by CyberSource's Decision Manager
property string scoreResult; Can be used to hold data returned by CyberSource's Decision Manager
property string scoreTime; Can be used to hold data returned by CyberSource's Decision Manager
property string firstName; This property holds the first name of the account owner (credit card or
eCheck account).
property string lastName; This property holds the last name of the account owner (credit card or
eCheck account).
property string fullName; This property holds the full name of the account owner (credit card or
eCheck account).
property string email; This property holds the email address of the account owner (credit card or
eCheck account).
property string phone; This property holds the phone number of the account owner (credit card or
eCheck account).
property number amount; This property holds the amount of the transaction.
property string currencyCD; This property holds the currency code of the transaction.
property string addr1; This property holds the first line of the address for the owner of the account
property string addr2; This property holds the second line of the address for the owner of the
property string addr3; This property holds the third line of the address for the owner of the account
property string addr4; This property holds the fourth line of the address for the owner of the account
property string city; This property holds the city portion of the address for the owner of the


(Properties)
property string state; This property holds the state code portion of the address for the owner of the
property string zip; This property holds the zip code portion of the address for the owner of the
property string country; This property holds the country code portion of the address for the owner of
the account (credit card or eCheck account)
property string ccType; This property holds the type of credit card.
property string ccNum; This property holds the credit card account number.
property string expYR; This property holds the expiration year of the credit card.
property string expMO; This property holds the expiration month of the credit card.
property string bankCD; This property holds the bank code for the eCheck transaction.
property string bankAcctType; This property holds the account type for the eCheck transaction.
property string bankAcctNum; This property holds the bank account for the eCheck transaction.
property string checkNum; This property holds the check number for the eCheck transaction.
property string DLNumber; This property holds the drivers license number sometimes used in ePayment
transactions.
property string DLState; This property holds the drivers license state code sometimes used in
property string subID; This property is intended to be used with subscription (or profile) related
property string subTitle; This property is intended to be used with subscription (or profile) related
property string subReasonCode; This property is intended to be used with subscription (or profile) related
property number subAmt; This property is intended to be used with subscription (or profile) related
property number setupAmt; This property is intended to be used with subscription (or profile) related
property string updSubID; This property is intended to be used with subscription (or profile) related
property string approvalRequired; This property is intended to be used with subscription (or profile) related


(Properties)
property string approvedBy; This property is intended to be used with subscription (or profile) related
property string autoRenew; This property is intended to be used with subscription (or profile) related
property string billPay; This property is intended to be used with subscription (or profile) related
property number eventNumber; This property is intended to be used with subscription (or profile) related
property string frequency; This property is intended to be used with subscription (or profile) related
property number nbrPayments; This property is intended to be used with subscription (or profile) related
property date subStartDate; This property is intended to be used with subscription (or profile) related
property date subEndDate; This property is intended to be used with subscription (or profile) related
property string subStatus; This property is intended to be used with subscription (or profile) related

APPENDIX H: PAYMENT MANAGER CLASS

The Payment Manager application class (PaymentManager) is used to orchestrate the processing of the ePayment transaction.
It leverages the transaction and adapter application classes to process the transaction. The Payment Merchant setup data is used
to determine which adapter should to be invoked to process the ePayment transaction and also to populate the Merchant ID
property on the transaction request. The Payment Manager application class is used by Campus Solutions application code to
process ePayment transactions.

APPENDIX I: ADAPTER REGISTRY

The adapter registry is used to define adapter types and adapters. It is used by multiple features within the Campus Solutions
product.
(Set Up SACR > System Administration > Utilities > Adapter Registry)
Adapter Type Table

Adapter types are used to categorize adapters by purpose.
(Set Up SACR > System Administration > Utilities > Adapter Registry > Adapter Type Table)
There are currently 4 delivered Adapter Types. The ePayment API uses SCC_EPAYMENT adapter type.
SCC_EPAYMENT: Used to identify “Electronic Payment Processing” adapters.
SCC_HOSTEDPY: Used to identify “Hosted Payment Processing” adapters.
SCC_PMT_APPL: Used to identify „Payment Application‟ related adapters.
SSF_SHSECRET: Used to identify „Shared Secret‟ adapters.
Note that the Adapter Type Table is considered “System Data” and is always prefixed with a valid Campus Solutions owner id
(SCC, SSF, SFA, …etc.).

Adapters Table
The Adapter Table is used to create a pointer to a specific application class. We currently have nine adapters that are delivered
as System Data. The ePayment API uses the adapters that have an Adapter Type of „SCC_EPAYMENT‟
(SCC_INT_BROKER and SCC_BUS_INTERLINK).
Informational: Note that the Adapter Table is considered “System Data” and is always prefixed with a valid Campus Solutions
owner id (SCC, SSF, SFA, …etc.).

APPENDIX J: PAYMENT MERCHANT

The Payment Merchant table instructs the system on how to process ePayment transactions for a specific third party payment
merchant id.
(Set Up SACR > Common Definitions > Payment Merchant)

Fields
 Merchant Setup ID: Uniquely identifies this Payment Merchant Setup
 Description: Describes the Merchant
 Status: This will document the status of the specified Payment Merchant as either active or inactive.
 Service Provider: This field was moved from the SF Merchant page. It allows the customer to identify the merchant as
“CyberSource”, “Touch Net”, or “Unsupported”. It is for informational purposes only.
 3rd party Merchant ID: This field holds the actual merchant name, or in the case of Hosted Payment the actual Site ID.
[Hosted Payment Setup]
 Hosted Payment Provider: This checkbox will identify the Payment Merchant as a Hosted Payment provider. This
checkbox will control the display of the “Hosted Payment Setup” group of fields. When checked, the “CVV Supported”
checkbox will be hidden.
 Adapter: This is the adapter that should be used by the hosted payment merchant to process hosted payment transactions.
 Browser Requirements Message: This field is used to document any browser-related message that an application may want
to display to the user prior to the user being transferred to the third party hosted site.
 Browser Requirements Detail: This field is used to document any browser-related detail concerning specific browser
requirements that an application may want to display to the user prior to the user being transferred to the third party hosted
site.
[Electronic Payment Setup]
 Service Operation: This field holds the Service Operation that should be used by the Adapter when processing the
electronic or hosted payment transaction request.

 Adapter: This is the adapter that should be used by this merchant. This is the adapter that will be used when processing
electronic payment transactions via the electronic payment API.
 Insert All Transactions: This button will insert all transactions into the “Supported Transactions” grid.
 Security Key Required: This checkbox will control the visibility of the “Security Key Setup” area directly below the
checkbox.
[Security Key Setup]
 Key ID: This field holds the ID of the Key.
 Exp Date: This field holds the Expiration Date of the Key.
 Key: This field holds a security key that may be required for security reasons by the third party payment provider when
interfacing transactions. It can be used to create the WS security section of SOAP headers that may be required by some
payment providers. This field will be encrypted once it has been saved using the encryption profiles located on the SF
Installation record.
[Supported Transactions]
This section defines which transactions this Payment Merchant supports. The listing below documents all possible supported
transactions at this time. The valid values for the transactions are currently maintained in the SCC_EPAY_TRANSACT field.
 Value: This is the value or code of the supported transactions.

o Credit Card Transactions
 01 - Authorize Only
 02 - Authorize and Bill
 03 - Bill Only
 04 - Credit Only
o Echeck Transactions
 05 - Make Payment
 06 - Apply Credit
o Hosted Transactions
 91 – Get Token
 92 – Authorize Only
 93 – Credit Only
 Description: This description comes from the translate table (psxlattable) and is relate display.
[Electronic Check]
 Verification Level: This field has been moved from the existing SF Merchant page. This is a default for the Verification
Level data element used by eCheck transactions. If this field isn‟t filled in on the transaction request it will be defaulted in
from this page.
 Settlement Method: This field has been moved from the existing SF Merchant page. This is the default Settlement method
that should be used by the ePayment transactions. If this field isn‟t filled in on the transaction request it will be defaulted in
from this page.

 ACH Class: This is the default value for ACH Class data element used by eCheck transactions. This value will be used for
eCheck transactions if a valid value is not entered on the transaction request. (Values: ARC, POP, TEL, WEB, etc.)
[Credit Card]
 Perform Check Risk Service: This is a default value for the Check Risk Service data element used by the credit card
authorization transactions. This value will be used for credit card transactions if a valid value is not entered on the
transaction request (on both the SF Merchant and the Payment Merchant).
 Check Risk Threshold: This is a default value for the Check Risk Threshold data element used by credit card authorization
transactions. This value will be used for credit card transactions if a valid value is not entered on the transaction request
(on both the SF Merchant and the Payment Merchant).
 CVV Supported: This field identifies if this merchant supports the sending of Security Code (CVV, CSC, etc.) values.
Merchants using the legacy Business Interlink-based integration technology will have this box unchecked. This field will
be hidden for Hosted Payment Providers (those Payment Merchants with the “Hosted Payment Provider” checkbox
checked).
 Address Verification Flag: This is a default value for the AVS data element used by credit card authorization transactions.
This value will be used for credit card transactions if a valid value is not entered on the transaction request (on both the SF
Merchant and the Payment Merchant).
[Additional Setup Options]
 Process Server: This field has been moved from the existing SF Merchant page and holds the location of the Process
Server used by the Business Interlink-based credit card and eCheck transactions. It is currently used by the creditcard and
eCheck business interlinks (server_host input property).
 IP Override: This field has been moved from the existing SF Merchant page. It is currently used by the creditcard and
eCheck business interlinks (ip_address input property). We are also using this field as a default ip address for transactions
processed by our new Integration Broker-based adapter described later in this document.
Informational: The Adapter dropdowns in both the Hosted Payment and Electronic Payment sections above are referencing the
Adapter Table described earlier.

APPENDIX K: ADAPTERS FOR THE EPAYMENT API

The adapter construct allows Campus Solutions to insulate the application code from the specifics of the underlying integration
technology and the payment provider‟s specific processing requirements. By developing an ePayment API consisting of the
Transaction and the PaymentManager application classes and by leveraging the Adapter Registry and Payment Merchant setup,
we can offer ePayment transaction support for both the existing Business Interlink-based integrations and a new Integration
Broker-based integration. This has been accomplished by the introduction of two ePayment adapters, one for Business
Interlink-based integrations and one for Integration Broker-based integrations. New adapters can be created by customers
and/or payment providers to support vendor or customer-specific processing requirements. Any new adapter created for
purposes of processing ePayment transactions should always extend the AbstractAdapter application class.
The ePayment adapter performs many important tasks:
 It marshals data from the transaction request to the integration technology specific structure (Business Interlink or
Integration Broker Message).
 It sets setup-related transactional defaults on the transaction request.
 It executes the actual transaction.
 It interprets the response from the payment provider and populates the transaction response.
Adapter Class Model
The adapter class model consists of three application classes. The first class is the AbstractAdapter
(SCC_EPAYMENT:ADAPTERS:AbstractAdapter) application class. It is used as the base class for all of the ePayment
adapters of type “SCC_EPAYMENT”, and it should never be invoked directly. The BusinessInterlinkAdapter application class
is derived from the AbstractAdapter class. It is used to process Business Interlink-based ePayment transactions. The
IntegrationBrokerAdapter application class is also derived from the AbstractAdapter class. It is used to process Integration
Broker-based ePayment transactions.
Abstract Adapter
The AbstractAdapter application class is the base class used by all ePayment adapters (adapters of type “SCC_EPAYMENT”
as defined in the Adapter Registry).
Methods
AbstractAdapter method: This method constructs the AbstractAdapter class. It sets and initializes properties of the class.
method AbstractAdapter(&p_merchant As SCC_EPAYMENT:SETUP:SCCMerchant);

ProcessTrans method: This is an abstract method and must be overridden by the extending class. The implementation of this
method in the extending class will perform the actual processing of the ePayment transaction. The transaction class will serve
as an in/out parameter to the method and a boolean value will be returned representing either success or failure of the call-out to
the third party processor. Note that a True does not mean the transaction was successful, but only that the call-out to the third
party was successful. A false means a processing error was encountered and a valid response was not received from the third
party payment processor. (RECOMMENDATION: This method MUST be overridden.)
method ProcessTrans(&p_Transaction As SCC_EPAYMENT:DATA:Transaction out) Returns boolean
abstract;
ValidateTrans method: This method checks to see if a specific transaction code is supported by the Payment Merchant by
calling the transSupported method. Additional validation checks can be performed by overriding this method in the extending
class. (RECOMMENDATION: Overriding this method should be done if the extending class desires to do additional
validation.)
method ValidateTrans(&p_Transaction As SCC_EPAYMENT:DATA:Transaction) Returns boolean;
transSupported method: This method checks to see if a specific transaction code is supported by the Payment Merchant. It is
called by the ValidateTrans method by default. (RECOMMENDATION: Overriding this method should not be required. We
suggest that the ValidateTrans method should be overridden if more stringent validation is desired.)
method transSupported(&p_transCode As string) Returns boolean;
PaymentException method: This method creates a payment exception class, sets the exception flag to true, and updates the
return code property with the exception message number. (RECOMMENDATION: Do not override this method.)
method PaymentException(&p_MsgSet As integer, &p_MsgNumber As integer, &p_MsgText As
string, &p_Parm1 As any, &p_Parm2 As any, &p_Parm3 As any, &p_Parm4 As any, &p_Parm5 As
any);
setDefaults method: This method will update the Transaction Request class with relevant default values from the SCC
Merchant Setup. (RECOMMENDATION: Do not override this method. If this method must be overridden copy or modify
existing method logic.)
method setDefaults(&p_Transaction As SCC_EPAYMENT:DATA:Transaction out);
Properties
property boolean exception: This property contains a read only boolean flag indicating if an exception was encountered during
processing.
property SCC_EPAYMENT:EXCEPTIONS:PaymentException PaymentException: This property contains a standard

exception class that will be populated in the event of an error.
property SCC_EPAYMENT:DATA:Constants EpayConstants: This property contains the payment constants class.
property SCC_EPAYMENT:SETUP:SCCMerchant merchant: This property contains the SCCMerchant Class.
property SCC_EPAYMENT:UTIL:EPayUtilities utilities: This property is used to perform various utility functions for
ePayment processing. This property is currently used to decrypt the Merchant Security KEY (security key required by some
providers).
property number returnCode: This property contains the return code result from the ProcessTrans function. Return Code will
contain a Peoplesoft-specific return value based on the transaction. Returned values will be:
 0 (Success), 100-199 (Declined, OK to display to on-line users)
 200-299 (Declined, not OK to display to on-line users.)
 300-399 (Connection Error: ETIMEOUT - Internal error)

 700-799 (PeopleSoft Error)
Business Interlink-Based Adapter
The Business Interlink-based adapter interacts with the existing Business Interlinks (CREDITCARD_TRANSACTION and
ECHECK_TRANSACTION) to process ePayment transactions. The Business Interlink-based adapter extends the
AbstractAdapter class described earlier. The Business Interlink-based adapter marshals the data from the Transaction class to
the Business Interlinks (see “Appendix L: Business Interlink Adapter Mappings” for specifics of how the data is mapped from
the Transaction class to the Business Interlinks).
Integration Broker-Based Adapter
The Integration Broker-based adapter interacts with Integration Broker and the SCC_EPAY_SYNC (request) and
SCC_EPAY_RESPONSE (response) messages. The Integration Broker-based adapter extends the AbstractAdapter class
described earlier. The Integration Broker-based adapter marshals the data from the Transaction class to the
SCC_EPAY_SYNC (request) and SCC_EPAY_RESPONSE (response) Integration Broker message structures (see “Appendix
M: Integration Broker Adapter Mappings” for specifics of how the data is mapped from the Transaction class to the Integration
Broker request and response messages). The Integration Broker-based adapter also contains logic to handle SOAP faults that
may be returned from some payment processors when ePayment transactions are unsuccessful.
Informational: Note that the “User Exception” checkbox on the Service Operation Routing definition will need to be checked if
you wish to be able to capture the SOAP fault error condition. If desired, a custom Integration Broker adapter can be created
that parses the SOAP fault text and return meaningful error messages and return codes to the calling application code.
Currently, SOAP faults are treated as declines in the application code as we are unable to parse the vendor-specific SOAP faults
in the non-vendor specific Business Interlink-based adapter.

APPENDIX L: BUSINESS INTERLINK ADAPTER MAPPINGS

TransactionRequest Class Mappings to the CREDITCARD_TRANSACTION and ECHECK_TRANSACTION Business
Interlinks:
Business Interlink Business Interlink

Transaction Data Class (BusinessInterlinkAdapter) (BusinessInterlinkAdapter)
SCC_EPAYMENT.TransactionRequest CREDITCARD_TRANSACTION ECHECK_TRANSACTION
property string transCode get set; service service
property string merchantID; merchant merchant
property string serverHost; server_host server_host
property string ipOverride; ip_address ip_address
property string trace; trace trace
property string merchantRef; merchant_ref merchant_ref
property string requestID; rqstid rqstid
property string requestToken; rqst_token rqst_token
property string verification; verification
property string settleMethod; settlement
property string agreementDate; agreement_dt
property string agreementText; agreement_text
property string scoreRisk; fraud_screen,

fraud_screen_modify
property string scoreThreshold; score_threshold
property string firstName; fname fname
property string lastName; lname lname
property string email; email email
property string phone; phone phone
property string amount; amount amount
property string currencyCD; currency currency
property string addr1; addr1 addr1


property string city; city city
property string state; state state
property string zip; zip zip
property string country; country country
property string ccType; cctype
property string ccNum; ccnum
property string expYR; expyr
property string expMO; expmo
property string cvv; avs_ignore
property string bankCD; bankcd
property string bankAcctType; accttype
property string bankAcctNum; acctnum
TransactionResponse Class Mappings to the CREDITCARD_TRANSACTION and ECHECK_TRANSACTION Business

Interlinks:

property string returnCode; return_status return_status
property string rawReturnCode; return_status return_status
property string returnMsg; ret_msg1, ret_msg2, ret_msg3 ret_msg1, ret_msg2, ret_msg3
property string trStatusMsg; ret_msg1, ret_msg2, ret_msg3 ret_msg1, ret_msg2, ret_msg3
property string authCode; ret_authcd
property string authDttm; ret_authdttm
property string AVS; ret_avs
property string transRefID; trans_ref_no trans_ref_no


property string requestID; rqstid_out rqstid_out
property string requestToken; rqst_token_out rqst_token_out

APPENDIX M: INTEGRATION BROKER ADAPTER MAPPINGS
TransactionRequest Class Mappings to SCC_EPAY_SYNC Integration Broker request message
Transaction Data Class IB Message (IntegrationBrokerAdapter)
SCC_EPAYMENT.TransactionRequest SCC_EPAY_SYNC
property string transCode get set; SCC_EPAY_TRNTYP.SCC_EPAY_TRANSACT
property string merchantID; SCC_EPAY_RQST.SCC_EPAY_MERCHANT
property string merchantRef; SCC_EPAY_TRANS.SCC_EPAY_MERCH_REF

SCC_EPAY_XMLPAY.SCC_EPAY_UNIQUE_ID
property string transRefID; SCC_EPAY_TRANS.SCC_EPAY_TRANS_REF
property string requestID; SCC_EPAY_TRANS.SCC_EPAY_RQST_ID
property string requestToken; SCC_EPAY_TRANS.SCC_EPAY_RQST_TOKN
property string transSecToken; SCC_EPAY_TRANS.SCC_EPAY_SEC_KEY
property string sessionID; SCC_EPAY_TRANS.SCC_EPAY_SESSIONID
property string settleNow; SCC_EPAY_TRNTYP.SCC_EPAY_SETTLENOW
property string AVSflag; SCC_EPAY_TRNTYP.SCC_EPAY_AVSFLAG
property string verification; SCC_EPAY_TRNTYP.EC_VERIFICATION
property string settleMethod; SCC_EPAY_TRNTYP.EC_SETTLE_METHOD
property string secretDescr; SCC_EPAY_TRNTYP.SCC_EPAY_SECRET
property string secretValue; SCC_EPAY_TRNTYP.SCC_EPAY_SECRETVAL
property string achClass; SCC_EPAY_TRNTYP.SCC_EPAY_ACH_CLASS
property string ipAddress; SCC_EPAY_TRNTYP.SCC_EPAY_IP_ADDR
property string transactionSource; SCC_EPAY_TRANS.SCC_PMT_APPL
property string miscIn; SCC_EPAY_TRANS.SCC_EPAY_MISC_LONG
property string agreementID; SCC_EPAY_TRANS.SCC_EPAY_AGREE_NBR
property string agreementDate; SCC_EPAY_TRANS.AGREEMENT_DT
property string agreementText; SCC_EPAY_TRANS.AGREEMENT_TEXT
property string paymentMethod; SCC_EPAY_TENDER.SCC_EPAY_PAYMETHOD
property string comments; SCC_EPAY_TRNTYP.SCC_EPAY_COMMENT
property string scoreRisk; SCC_EPAY_TRNTYP.SCC_EPAY_FSRISK
property string scoreThreshold; SCC_EPAY_TRNTYP.SCC_EPAY_FSTHRES

property string scoreRiskModify; SCC_EPAY_TRNTYP.SCC_EPAY_FSCMOD
property string scoreCatGift; SCC_EPAY_TRNTYP.SCC_EPAY_FSCGIFT
property string scoreCatLongTerm; SCC_EPAY_TRNTYP.SCC_EPAY_FSCLNGTRM
property string scoreCatTime; SCC_EPAY_TRNTYP.SCC_EPAY_FSCTIME
property string hostHedge; SCC_EPAY_TRNTYP.SCC_EPAY_FSHOSTHDG
property string timeHedge; SCC_EPAY_TRNTYP.SCC_EPAY_FSTIMEHDG
property string velocityHedge; SCC_EPAY_TRNTYP.SCC_EPAY_FSVELHDG
property string firstName; SCC_EPAY_BILLTO.SCC_EPAY_FNAME
property string lastName; SCC_EPAY_BILLTO.SCC_EPAY_LNAME
property string fullName; SCC_EPAY_BILLTO.SCC_EPAY_FULLNAME
property string email; SCC_EPAY_BILLTO.SCC_EPAY_EMAIL
property string phone; SCC_EPAY_BILLTO.PHONE
property string amount; SCC_EPAY_INV.SCC_EPAY_TOTAL_AMT
property string currencyCD; SCC_EPAY_INV.CURRENCY_CD
property string addr1; SCC_EPAY_ADDR2.ADDRESS1
property string city; SCC_EPAY_ADDR2.CITY
property string state; SCC_EPAY_ADDR2.STATE
property string zip; SCC_EPAY_ADDR2.POSTAL
property string country; SCC_EPAY_ADDR2.COUNTRY
property string ccType; SCC_EPAY_CARD.SCC_EPAY_TYPE
property string ccNum; SCC_EPAY_CARD.SCC_EPAY_NUMBER
property string expYR; SCC_EPAY_CARD.SCC_EPAY_EXPYR
property string expMO; SCC_EPAY_CARD.SCC_EPAY_EXPMO
property string cvv; SCC_EPAY_CARD.SCC_EPAY_CVNUM
property string bankCD; SCC_EPAY_ACCT.SCC_EPAY_BANK_CD
property string bankAcctType; SCC_EPAY_ACCT.SCC_EPAY_ACCT_TYPE

property string bankAcctNum; SCC_EPAY_ACCT.SCC_EPAY_ACCT_NBR
property string checkNum; SCC_EPAY_ACCT.SCC_EPAY_CHECK_NBR
property string DLNumber; SCC_EPAY_BILLTO.SCC_EPAY_DL_NO
property string DLState; SCC_EPAY_BILLTO.SCC_EPAY_DL_STATE
property string subID; SCC_EPAY_SUBSCR.EPAY_SUB_ID
property string subTitle; SCC_EPAY_SUBSCR.EPAY_SUB_TITLE
property string disableAutoAuth; SCC_EPAY_SUBSCR.EPAY_DISBLAATH
property string createService; SCC_EPAY_SUBSCR.EPAY_SUBCRSRVC
property string eventUpdateAction; SCC_EPAY_SUBSCR.EPAY_EVENTACTN
property string eventUpdate; SCC_EPAY_SUBSCR.EPAY_EVENTSRVC
property string getService; SCC_EPAY_SUBSCR.EPAY_GETSRVC
property string updateService; SCC_EPAY_SUBSCR.EPAY_UPDSRVC
property string subAmt; SCC_EPAY_SUBSCR.EPAY_RECUR_AMT
property number setupAmt; SCC_EPAY_SUBSCR.EPAY_SETUP_AMT
property string approvalRequired; SCC_EPAY_SUBSCR.EPAY_APPROVAL
property string approvedBy; SCC_EPAY_SUBSCR.EPAY_EAPPR_BY
property string autoRenew; SCC_EPAY_SUBSCR.EPAY_AUTORENEW
property string billPay; SCC_EPAY_SUBSCR.EPAY_BILLPAY
property string eventNumber; SCC_EPAY_SUBSCR.EPAY_EVENT_NBR
property string frequency; SCC_EPAY_SUBSCR.EPAY_EVNT_FREQ
property string nbrPayments; SCC_EPAY_SUBSCR.EPAY_NBR_PYMNT
property string subStartDate; SCC_EPAY_SUBSCR.EPAY_STARTDATE
property string subEndDate; SCC_EPAY_SUBSCR.EPAY_END_DT
property string subStatus; SCC_EPAY_SUBSCR.EPAY_STATUS
property string subMethod; SCC_EPAY_SUBSCR.EPAY_SUB_METHD

TransactionResponse Class Mappings to the SCC_EPAY_RESPONSE Integration Broker request message
property string returnCode; SCC_EPAY_TRRSLT.SCC_EPAY_RESULT
property string rawReturnCode; SCC_EPAY_TRRSLT.SCC_EPAY_ORIGRSLT
property number reasonCode; SCC_EPAY_TRRSLT.SCC_EPAY_REASON_CD
property string returnMsg; SCC_EPAY_TRRSLT.RET_MSG
property string decision; SCC_EPAY_TRRSLT.SCC_EPAY_DECISION
property string trStatusMsg; SCC_EPAY_TRRSLT.SCC_EPAY_TRSTATMSG
property string authCode; SCC_EPAY_TRRSLT.SCC_EPAY_AUTHCD
property string authDttm; SCC_EPAY_TRRSLT.SCC_EPAY_AUTHDTTM
property string AVS; SCC_EPAY_TRRSLT.SCC_EPAY_AVS
property string rawAVS; SCC_EPAY_TRRSLT.SCC_EPAY_RAWAVS
property string zipAVS; SCC_EPAY_AVRSLT.SCC_EPAY_MATCH_ZIP
property string stAVS; SCC_EPAY_AVRSLT.SCC_EPAY_MATCH_ST
property string transRefID; SCC_EPAY_TRRSLT.SCC_EPAY_TRANSID
property string requestID; SCC_EPAY_TRRSLT.SCC_EPAY_RQST_ID
property string requestToken; SCC_EPAY_TRRSLT.SCC_EPAY_RQST_TOKN
property string debit_amt; SCC_EPAY_TRRSLT.SCC_EPAY_DB_AMT
property string credit_amt; SCC_EPAY_TRRSLT.SCC_EPAY_CR_AMT
property string cvResult; SCC_EPAY_TRRSLT.SCC_EPAY_CVRESULT
property string bankName; SCC_EPAY_TRRSLT.SCC_EPAY_BANK_NAME
property string bankAddr; SCC_EPAY_TRRSLT.SCC_EPAY_BANKADDR
property string bankCSZ; SCC_EPAY_TRRSLT.SCC_EPAY_BANKCSZ
property string agreementID; SCC_EPAY_TRRSLT.SCC_EPAY_AGREE_NBR
property string agreementText; SCC_EPAY_TRRSLT.AGREEMENT_TEXT
property date agreementDate; SCC_EPAY_TRRSLT.AGREEMENT_DT
property string ipAddress; SCC_EPAY_TRRSLT.SCC_EPAY_IP_ADDR

property string statusCode; SCC_EPAY_TRRSLT.SCC_EPAY_STAT_CD
property string statusDescr; SCC_EPAY_TRRSLT.SCC_EPAY_STAT_DSCR
property string sessionID; SCC_EPAY_TRRSLT.SCC_EPAY_SESSIONID
property string settleMethod; SCC_EPAY_TRRSLT.SCC_EPAY_RESP_MTHD
property string transactionSource; SCC_EPAY_TRRSLT.SCC_PMT_APPL
property string miscOut; SCC_EPAY_TRRSLT.SCC_EPAY_MISC_LONG
property string comments; SCC_EPAY_SUBRSP.SCC_EPAY_COMMENT
property string scoreFactors; SCC_EPAY_TRRSLT.SCC_EPAY_FSFACTORS
property string hostSeverity; SCC_EPAY_TRRSLT.SCC_EPAY_FSHOSTSEV
property string rCode; SCC_EPAY_TRRSLT.SCC_EPAY_FS_RCODE
property string rFlag; SCC_EPAY_TRRSLT.SCC_EPAY_FS_RFLAG
property string rMsg; SCC_EPAY_TRRSLT.SCC_EPAY_FS_RMSG
property string scoreResult; SCC_EPAY_TRRSLT.SCC_EPAY_FSSCORE
property string scoreTime; SCC_EPAY_TRRSLT.SCC_EPAY_FSSCORETM
property string firstName; SCC_EPAY_BILLTO.SCC_EPAY_FNAME
property string lastName; SCC_EPAY_BILLTO.SCC_EPAY_LNAME
property string fullName; SCC_EPAY_BILLTO.SCC_EPAY_FULLNAME
property string email; SCC_EPAY_BILLTO.SCC_EPAY_EMAIL
property string phone; SCC_EPAY_BILLTO.PHONE
property number amount; SCC_EPAY_TRRSLT.SCC_EPAY_TOTAL_AMT
property string currencyCD; SCC_EPAY_TRRSLT.CURRENCY_CD

property string city; SCC_EPAY_ADDR2.CITY
property string state; SCC_EPAY_ADDR2.STATE
property string zip; SCC_EPAY_ADDR2.POSTAL
property string country; SCC_EPAY_ADDR2.COUNTRY
property string ccType; SCC_EPAY_CARD.SCC_EPAY_TYPE
property string ccNum; SCC_EPAY_CARD.SCC_EPAY_NUMBER
property string expYR; SCC_EPAY_CARD.SCC_EPAY_EXPYR
property string expMO; SCC_EPAY_CARD.SCC_EPAY_EXPMO
property string bankCD; SCC_EPAY_ACCT.SCC_EPAY_BANK_CD
property string bankAcctType; SCC_EPAY_ACCT.SCC_EPAY_ACCT_TYPE
property string bankAcctNum; SCC_EPAY_ACCT.SCC_EPAY_ACCT_NBR
property string checkNum; SCC_EPAY_ACCT.SCC_EPAY_CHECK_NBR
property string DLNumber; SCC_EPAY_BILLTO.SCC_EPAY_DL_NO
property string DLState; SCC_EPAY_BILLTO.SCC_EPAY_DL_STATE
property string subID; SCC_EPAY_SUBRSP.SCC_EPAY_SUB_ID
property string subTitle; SCC_EPAY_SUBRSP.SCC_EPAY_SUB_TITLE
property string subReasonCode; SCC_EPAY_SUBRSP.SCC_EPAY_REASON_CD
property number subAmt; SCC_EPAY_SUBRSP.SCC_EPAY_RECUR_AMT
property number setupAmt; SCC_EPAY_SUBRSP.SCC_EPAY_SETUP_AMT
property string updSubID; SCC_EPAY_SUBRSP.SCC_EPAY_UPDSUB_ID
property string approvalRequired; SCC_EPAY_SUBRSP.SCC_EPAY_APPROVAL
property string approvedBy; SCC_EPAY_SUBRSP.SCC_EPAY_EAPPR_BY
property string autoRenew; SCC_EPAY_SUBRSP.SCC_EPAY_AUTORENEW

property string billPay; SCC_EPAY_SUBRSP.SCC_EPAY_BILLPAY
property number eventNumber; SCC_EPAY_SUBRSP.SCC_EPAY_EVENT_NBR
property string frequency; SCC_EPAY_SUBRSP.SCC_EPAY_EVNT_FREQ
property number nbrPayments; SCC_EPAY_SUBRSP.SCC_EPAY_NBR_PYMNT
property date subStartDate; SCC_EPAY_SUBRSP.SCC_EPAY_STARTDATE
property date subEndDate; SCC_EPAY_SUBRSP.SCC_EPAY_END_DT
property string subStatus; SCC_EPAY_SUBRSP.SCC_EPAY_STATUS

APPENDIX N: TESTING THE EPAYMENT API

Testing the ePayment API can be performed from the ePayment Test page located under the ePayment Folder (Set Up SACR >
Common Definitions > Electronic Payments > Electronic Payment Test)


Buttons
 Post to Hosted Payment URL: Pushing this button will cause a redirect out to the third party URL where a sample payment
can be made. The third party site should redirect you back to this page after the payment is made. You can then authorize
the payment using the “Trans Type” field to select the “Authorize Only” (92) transaction. Note that the “Session ID” field
should be updated once you select either “Authorize Only” (92) or “Credit Only” (93) transaction. This button will only be
available for Payment Merchants that are Hosted Payment Providers.
 Submit: This button submits the transaction using the Electronic Payment API.
 Run: This button runs the batch electronic payment test program. This program tests Credit Card and eCheck transactions
(Authorize and Credit) to make sure that these transactions function properly in a batch environment (this is more relevant
when using the Business Interlink adapter).
Fields
[Merchant Options]
 Merchant Setup ID: This field prompts the user to enter a valid Merchant Setup ID as defined in the New Payment
Merchant Setup component as documented in section 2.2.2.5 above.
Informational: Note that the remaining fields in this section are relate-displayed from the Payment Merchant Setup or the
Payment Adapter Setup and are informational only.
[Testing Options]
 Trans. Type: This field specifies the type of transaction that will be processed. The valid values for this field come from
the Payment Merchant Setup component (“Supported Transactions” section of the Payment Merchant setup page).
 Payment Amount: This is the amount of the transaction.
 Merchant Ref ID: This field is used to uniquely identify the transaction that is sent to the third party processor. If this field
is left blank it will be programmatically populated with a uniquely generated ID.
[Transaction Response]
 This section will contain the results of the transaction request. The fields of this section all come from properties of the
TransactionResponse class that is returned from the Electronic Payment Manager class.
o Return Code
o Raw Return Code
o Decision
o Status Message
o Authorization Code
o AVS Code
o CV Result
o Transaction Ref
o Request ID
o Request Token

o Session ID
o Return Message
[eCheck Account Information]
 This section contains relevant input fields for Echeck transactions.
o Reference Nbr:
o First Name:
o Last Name:
o Bank Account Type:
o Bank ID:
o Account Number:
o Agreement Number:
o Agreement Date:
o IP Address:
o Agreement Text:
[Credit Card Information]
 This section contains relevant input fields for Credit Card transactions.
o Credit Card First Name
o Credit Card Last Name
o Credit Card Type
o Card Number
o Security Code
o Card Expiration Month
o Card Expiration Year
o Card Number:
o Security Code
o Card Expiration Month
o Secret Description
o Secret Value
[Address Billing Information]
 This section contains address related fields used by both Echeck and Credit Card transactions.
o Address Line 1

o City:
o State:
o Country:
o Postal Code:
o Email Address:
o Telephone:
Testing Transactions
Basic Instructions for testing transactions:

APPENDIX O: EPAYMENT RETURN CODES AND ASSOCIATED MESSAGES

Campus Solutions has defined the Return Code property that is returned by the ePayment API so that it conveys
meaning to the calling applications regarding the ePayment transaction.
Return Code ranges:
 0 (Success)
 100-199 (Declined, OK to display to on-line users)
 200-299 (Declined, not OK to display to on-line users.)
 300-399 (Connection Error: ETIMEOUT - Internal error)
 700-799 (PeopleSoft Error)
The table below shows Message Set 14869. This Message Set contains all ePayment related response messages.
Set Msg Severity Message
14869 101 M The transaction was declined due to one or more missing fields (%1).
14869 102 M The transaction was declined due to an invalid value in one or more fields (%1).
14869 122 M The transaction was declined, the card is not active or has expired.
14869 123 M Transaction was declined.
14869 124 M The transaction was declined due to insufficient funds.
14869 128 M The Transaction was declined, the card is not active or not authorized for this type of transaction.
14869 129 M The transaction was declined due to invalid or incorrect CID.
14869 130 M The transaction was declined because the credit limit on the card has been reached or exceeded.
14869 131 M The transaction has been declined due to an invalid CVV number.
14869 151 M The transaction was declined due to an invalid account number.
14869 152 M The transaction was declined because the card type is not supported by the transaction processor.
14869 155 M The transaction was declined because of an amount mismatch.
14869 157 M The transaction was declined because the authorization has already been reversed.
14869 158 M The transaction was declined because the associated authorization was not available for capture.
14869 159 M The transaction was declined due to an amount mismatch.
14869 160 M The transaction was declined because the card type is invalid or does not match the number provided.
14869 161 M The transaction was declined because the request ID included in the transaction was not valid.
14869 162 M The transaction was declined because it had previously been settled or reversed.

14869 166 M The transaction was declined because this transaction type cannot be voided.
14869 167 M The transaction was declined because it had already been voided.
14869 170 M The transaction was declined due to required card data not present or failed verification check.
14869 171 M The transaction was declined due to a batch related issue.
14869 172 M The transaction was declined because an invalid amount was specified for the transaction.
14869 173 M The transaction was declined because the request is not valid for the specific operation type.
14869 174 M The transaction was declined because reversals are not allowed for this type of transaction.
14869 175 M The transaction was declined because the operation had already been attempted.
14869 176 M The transaction was declined because the operation is not valid for this type of transaction.
14869 177 M The transaction was declined due to settlement related issues.
14869 178 M The transaction was declined because the ACH agreement could not be found.
14869 179 M The transaction was declined because the ACH routing number could not be found.
14869 180 M The transaction was declined because it was reinitiated too many times.
14869 181 M The transaction was declined because the "settle now" option is not allowed.
14869 182 M The transaction was declined because it is not valid for the Merchant License.
14869 183 M The transaction was declined because it is not allowed by the processor.
14869 184 M The transaction was declined due to an invalid rejection code for the ACH transaction.
14869 185 M The transaction was declined because the operation is not allowed on payments from savings accounts.
14869 186 M The transaction was declined because the account is frozen.
14869 199 M The transaction was declined (%1).
14869 200 M The transaction was declined because of a failed AVS check.
14869 201 M The transaction was initially declined, call the card processor for possible approval.
14869 205 M The transaction was declined because the associated card has been reported as lost or stolen.
14869 221 M The transaction has been declined because the customer is on the processor's negative file.
14869 230 M The transaction was declined because it failed the CV (card validation) check.
14869 299 M The transaction was declined (%1).
14869 300 M System error or transaction timeout.
14869 399 M System error or transaction timeout (Return Code: %1).

14869 701 M Merchant not found (Merchant ID: %1).
14869 703 M Security Token required for Merchant (ID: %1).
14869 704 M Error returned from Merchant Manager Class (%1).
14869 705 M Error returned from Adapter Manager Class (%1).
14869 706 M Invalid Merchant (Merchant Setup ID: %1), no Integration ID specified.
14869 707 M Invalid Merchant (Merchant Setup ID: %1), no Service Operation specified.
14869 708 M Transaction Code is invalid or blank (Transaction Code: "%1").
14869 709 M Error creating the Adapter class (Adapter ID: %1,Type: %2), specified adapter not found.
14869 710 M Error creating the Adapter class, no Adapter Type was specified.
14869 711 M Error creating the Adapter class, no Adapter ID was specified.
14869 712 M Error, the specified Service Operation (%1) is not active or does not exist.
14869 713 M Error, transaction (%1) is not supported by this Service Provider (Merchant Setup ID: %2).
14869 714 M Transaction validation error (%1). This transaction was not processed.
14869 715 M The Service Operation (%1) was not found.
14869 717 M An error occurred processing the Service Operation (Error: %1).
14869 718 M A SOAP Fault occurred processing the Service Operation (detail: %1).
14869 719 M Error, no Adapter specified on Merchant Record (Merchant ID: %1).
14869 720 M An error occurred processing the transaction.
14869 721 M An error occurred processing the transaction (Error: %1).
14869 722 M Transaction validation error, no Merchant specified on the transaction.
14869 723 M An error has occurred in the %1 Business Interlink (Return Code: %2, Message: ).
14869 724 M This transaction (%1) is not supported by the Business Interlink Adapter.
14869 799 M An error was returned from %1 (Return CD: %2, Error Text: %3).

APPENDIX Z: CODE SAMPLES
Request Sample 1: Request Transformation PeopleCode

import SCC_EPAYMENT:UTIL:EPayUtilities;
REM Get the Transformation data from Integration Broker;
Local TransformData &MSGTData = %TransformData;
Local XmlDoc &MSGDataXMLDoc;
Local XmlDoc &MSGXMLDoc;
Local XmlDoc &SoapDoc;
Local XmlNode &EnvNode, &TransNode, &TrnDtlNode, &RqstNode, &CardNode, &AcctNode, &InvNode, &BillNode,
&AddrNode, &methodNode, &bodyNode, &workNode, &headerNode, &workNode3, &purchaseNode;
Local XmlNode &billTo, &cardNodeOut, &checkNode;
Local string &SOAPMethod, &transType, &transRef, &MerchRef, &cardNum, &expYR, &expMO, &transAmt,
&cvNum, &avsStreet, &avsZip, &settleNow, &checkNBR, &acctNBR, &acctType, &lname, &fname, &bankCD,
&savingsAcct, &agreementID, &achClass, &agreementText, &ipAddress, &merchantId, &merchantKey;
Local string &country, &city, &state, &requestID, &requestToken, &fullName, &settleMethod,
&verificationLevel, &email, &cardType;
Local array of XmlNode &XMLelementArray;
Local SCC_EPAYMENT:UTIL:EPayUtilities &Util = create SCC_EPAYMENT:UTIL:EPayUtilities();
REM Get the transaction data from the PS request message - SCC_EPAY_SYNC;
&MSGDataXMLDoc = &MSGTData.XmlDoc;
&RqstNode =
&MSGDataXMLDoc.DocumentElement.FindNode("/SCC_EPAY_SYNC/MsgData/Transaction/SCC_EPAY_XMLPAY/SCC_EPAY_RQ
ST");
&TransNode =
ST/SCC_EPAY_TRANS");
&TrnDtlNode =
ST/SCC_EPAY_TRANS/SCC_EPAY_TRNTYP");
&CardNode =
ST/SCC_EPAY_TRANS/SCC_EPAY_TRNTYP/SCC_EPAY_TENDER/SCC_EPAY_CARD");
&AcctNode =
ST/SCC_EPAY_TRANS/SCC_EPAY_TRNTYP/SCC_EPAY_TENDER/SCC_EPAY_ACCT");
&InvNode =
ST/SCC_EPAY_TRANS/SCC_EPAY_TRNTYP/SCC_EPAY_PAYDAT/SCC_EPAY_INV");
&BillNode =
ST/SCC_EPAY_TRANS/SCC_EPAY_TRNTYP/SCC_EPAY_PAYDAT/SCC_EPAY_INV/SCC_EPAY_BILLTO");
&AddrNode =
ST/SCC_EPAY_TRANS/SCC_EPAY_TRNTYP/SCC_EPAY_PAYDAT/SCC_EPAY_INV/SCC_EPAY_BILLTO/SCC_EPAY_ADDR2");
Local string &xmlstring = &TransNode.GenXmlString();
If Not &TransNode.IsNull Then

&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_TRANSACT");
If &XMLelementArray.Len > 0 Then
&transType = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_SETTLENOW");

&settleNow = &XMLelementArray [1].NodeValue;

End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_TRANS_REF");
&transRef = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_RQST_ID");
&requestID = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_RQST_TOKN");
&requestToken = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_MERCH_REF");
&MerchRef = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_SEC_KEY");
&merchantKey = &XMLelementArray [1].NodeValue;
End-If;
End-If;
If Not &RqstNode.IsNull Then

&XMLelementArray = &RqstNode.GetElementsByTagName("SCC_EPAY_MERCHANT");
&merchantId = &XMLelementArray [1].NodeValue;
End-If;
End-If;
If Not &CardNode.IsNull Then

&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_NUMBER");
&cardNum = &XMLelementArray [1].NodeValue;
REM Strip non-numeric chars from the card field;
&cardNum = &Util.StripCRCard(&cardNum);
End-If;
&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_TYPE");

&cardType = &XMLelementArray [1].NodeValue;
REM Translate the credit card type to the vendor's card type;
Evaluate &cardType
When "AE"
&cardType = "003";
When "DC"
&cardType = "005";
When "DI"
&cardType = "005";
When "MC"

&cardType = "002";
When "VI"
&cardType = "001";
When-Other
&cardType = "";
End-Evaluate;
End-If;
&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_EXPYR");
&expYR = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_EXPMO");
&expMO = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_CVNUM");
&cvNum = &XMLelementArray [1].NodeValue;
End-If;
End-If;
If Not &InvNode.IsNull Then

&XMLelementArray = &InvNode.GetElementsByTagName("SCC_EPAY_TOTAL_AMT");
&transAmt = &XMLelementArray [1].NodeValue;
REM Convert the amount from the SCC_EPAY_SYNC message to the vendor's required format;
&transAmt = LTrim(RTrim(NumberToString("%6.2", Value(&transAmt))));
End-If;
End-If;
If Not &AddrNode.IsNull Then

&XMLelementArray = &AddrNode.GetElementsByTagName("ADDRESS1");
&avsStreet = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &AddrNode.GetElementsByTagName("POSTAL");
&avsZip = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &AddrNode.GetElementsByTagName("CITY");
&city = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &AddrNode.GetElementsByTagName("COUNTRY");
&country = &XMLelementArray [1].NodeValue;
REM Convert the 3 char country code to 2 char country code;
&country = &Util.get2CharCountryCD(&country);
End-If;
&XMLelementArray = &AddrNode.GetElementsByTagName("STATE");

&state = &XMLelementArray [1].NodeValue;

End-If;
End-If;
If Not &AcctNode.IsNull Then

&XMLelementArray = &AcctNode.GetElementsByTagName("SCC_EPAY_ACCT_TYPE");
&acctType = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &AcctNode.GetElementsByTagName("SCC_EPAY_BANK_CD");
&bankCD = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &AcctNode.GetElementsByTagName("SCC_EPAY_ACCT_NBR");
&acctNBR = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &AcctNode.GetElementsByTagName("SCC_EPAY_CHECK_NBR");
&checkNBR = &XMLelementArray [1].NodeValue;
End-If;
End-If;
If Not &TrnDtlNode.IsNull Then

&XMLelementArray = &TrnDtlNode.GetElementsByTagName("SCC_EPAY_AGREE_NBR");
&agreementID = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TrnDtlNode.GetElementsByTagName("SCC_EPAY_ACH_CLASS");
&achClass = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TrnDtlNode.GetElementsByTagName("AGREEMENT_TEXT");
&agreementText = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TrnDtlNode.GetElementsByTagName("SCC_EPAY_IP_ADDR");
&ipAddress = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TrnDtlNode.GetElementsByTagName("EC_SETTLE_METHOD");
&settleMethod = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TrnDtlNode.GetElementsByTagName("EC_VERIFICATION");
&verificationLevel = &XMLelementArray [1].NodeValue;
End-If;
End-If;
If Not &BillNode.IsNull Then

&XMLelementArray = &BillNode.GetElementsByTagName("SCC_EPAY_FNAME");
&fname = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &BillNode.GetElementsByTagName("SCC_EPAY_LNAME");
&lname = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &BillNode.GetElementsByTagName("SCC_EPAY_FULLNAME");
&fullName = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &BillNode.GetElementsByTagName("SCC_EPAY_EMAIL");
&email = &XMLelementArray [1].NodeValue;
End-If;
End-If;
REM Build SOAP Document;

&SoapDoc = CreateXmlDoc("<?xml version=""1.0""?><soap:Envelope
xmlns:soap=""http://schemas.xmlsoap.org/soap/envelope/""/>");
&workNode = &SoapDoc.DocumentElement;
&workNode = &SoapDoc.DocumentElement.AddElement("soap:Header");
REM Add WS security section of SOAP doc;

&workNode = &workNode.AddElement("wsse:Security");
&workNode.AddAttribute("mustUnderstand", "1");
&workNode.AddAttribute("xmlns:wsse", "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-secext-1.0.xsd");
&workNode = &workNode.AddElement("wsse:UsernameToken");
&workNode.AddElement("wsse:Username").NodeValue = &merchantId;
REM Add Security Key from Payment Merchant here;
&workNode3 = &workNode.AddElement("wsse:Password");
&workNode3.AddAttribute("type", "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
token-profile-1.0#PasswordText");
&workNode3.NodeValue = &merchantKey;
&workNode = &SoapDoc.DocumentElement.AddElement("soap:Body");
&workNode.AddAttribute("xmlns:xsi", "http://www.w3.org/2001/XMLSchema-instance");
&workNode.AddAttribute("xmlns:xsd", "http://www.w3.org/2001/XMLSchema");
&XMLelementArray = &SoapDoc.GetElementsByTagName("soap:Body");
&bodyNode = &XMLelementArray [1];
REM Review the transaction type and build the requested message;
REM in the 3rd party vendor's required format;
Evaluate &transType
When "1"
REM ccAuthCharge;
REM need to add scoreRisk and scoreThresh to the authcharge transaction;
&SOAPMethod = "requestMessage";
&methodNode = &bodyNode.AddElement(&SOAPMethod);

&methodNode.AddAttribute("xmlns", "urn:schemas-paymentprovider-com:transaction-data-1.35");
&methodNode.AddElement("merchantID").NodeValue = &merchantId;
&methodNode.AddElement("merchantReferenceCode").NodeValue = &MerchRef;
&billTo = &methodNode.AddElement("billTo");
&billTo.AddElement("firstName").NodeValue = &fname;
&billTo.AddElement("lastName").NodeValue = &lname;
&billTo.AddElement("street1").NodeValue = &avsStreet;
&billTo.AddElement("city").NodeValue = &city;
&billTo.AddElement("state").NodeValue = &state;
&billTo.AddElement("postalCode").NodeValue = &avsZip;
&billTo.AddElement("country").NodeValue = &country;
&billTo.AddElement("email").NodeValue = &email;
&purchaseNode = &methodNode.AddElement("purchaseTotals");
&purchaseNode.AddElement("currency").NodeValue = "USD";
&purchaseNode.AddElement("grandTotalAmount").NodeValue = &transAmt;
&cardNodeOut = &methodNode.AddElement("card");
&cardNodeOut.AddElement("accountNumber").NodeValue = &cardNum;
&cardNodeOut.AddElement("expirationMonth").NodeValue = &expMO;
&cardNodeOut.AddElement("expirationYear").NodeValue = &expYR;
If All(&cvNum) Then
&cardNodeOut.AddElement("cvNumber").NodeValue = &cvNum;
End-If;
If All(&cardType) Then
&cardNodeOut.AddElement("cardType").NodeValue = &cardType;
End-If;
&methodNode.AddElement("ccAuthService").AddAttribute("run", "true");
When "2"
REM ccAuthCharge+ccCapture;
If All(&cvNum) Then
&cardNodeOut.AddElement("cvNumber").NodeValue = &cvNum;

End-If;
End-If;
&methodNode.AddElement("ccAuthService").AddAttribute("run", "true");
&methodNode.AddElement("ccCaptureService").AddAttribute("run", "true");
When "3"
REM ccCapture;
&methodNode = &methodNode.AddElement("ccCaptureService");
&methodNode.AddAttribute("run", "true");
If All(&requestID) Then
&methodNode.AddElement("authRequestID").NodeValue = &requestID;
End-If;
If All(&transRef) Then
&methodNode.AddElement("reconciliationID").NodeValue = &transRef;
End-If;
If All(&requestToken) Then
&methodNode.AddElement("authRequestToken").NodeValue = &requestToken;
End-If;
&methodNode.AddElement("transactionID").NodeValue = &transRef;
End-If;
When "4"
REM ccCreditService;

End-If;
&methodNode = &methodNode.AddElement("ccCreditService");
&methodNode.AddElement("captureRequestID").NodeValue = &requestID;
End-If;
&methodNode.AddElement("reconciliationID").NodeValue = &transRef;
End-If;
&methodNode.AddElement("captureRequestToken").NodeValue = &requestToken;
End-If;
When "5"
REM ecDebitService;
&checkNode = &methodNode.AddElement("check");
&checkNode.AddElement("fullName").NodeValue = &fullName;
&checkNode.AddElement("accountNumber").NodeValue = &acctNBR;

&checkNode.AddElement("accountType").NodeValue = &acctType;
&checkNode.AddElement("bankTransitNumber").NodeValue = &bankCD;
&checkNode.AddElement("checkNumber").NodeValue = &checkNBR;
&methodNode = &methodNode.AddElement("ecDebitService");
&methodNode.AddElement("paymentMode").NodeValue = "0";
If All(&settleMethod) Then
&methodNode.AddElement("settlementMethod").NodeValue = &settleMethod;
End-If;
If All(&verificationLevel) Then
&methodNode.AddElement("verificationLevel").NodeValue = &verificationLevel;
End-If;
When "6"
REM ecCreditService;
&checkNode = &methodNode.AddElement("check");
&checkNode.AddElement("fullName").NodeValue = &fullName;
&checkNode.AddElement("accountNumber").NodeValue = &acctNBR;
&checkNode.AddElement("accountType").NodeValue = &acctType;
&checkNode.AddElement("bankTransitNumber").NodeValue = &bankCD;
&checkNode.AddElement("checkNumber").NodeValue = &checkNBR;
&methodNode = &methodNode.AddElement("ecCreditService");
&methodNode.AddElement("referenceNumber").NodeValue = &transRef;
End-If;
If All(&settleMethod) Then
&methodNode.AddElement("settlementMethod").NodeValue = &settleMethod;
End-If;
&methodNode.AddElement("debitRequestID").NodeValue = &requestID;
End-If;
&methodNode.AddElement("debitRequestToken").NodeValue = &requestToken;
End-If;

When-Other
&SoapDoc = &MSGTData.XmlDoc;
End-Evaluate;
REM Update Integration Broker with the transformed message;

%TransformData.XmlDoc = &SoapDoc;
Request Sample 2: Request Transformation PeopleCode


Local XmlDoc &MSGDataXMLDoc = &MSGTData.XmlDoc;
Local XmlNode &EnvNode, &TransNode, &TrnDtlNode, &RqstNode, &CardNode, &AcctNode, &InvNode, &BillNode,
&AddrNode;
Local XmlNode &bodyNode, &methodNode, &workNode;
Local string &SOAPMethod, &transType, &transRef, &MerchRef, &MerchantID, &cardNum, &expYR, &expMO,
&transAmt, &cvNum, &cardType;
Local string &avsStreet, &avsZip, &settleNow, &checkNBR, &acctNBR, &acctType, &lname, &fname, &bankCD,
&savingsAcct, &agreementID, &achClass, &agreementText, &ipAddress, &fullname, &email;
Local number &OK;
&RqstNode =
ST");
&TransNode =
&TrnDtlNode =
&CardNode =
ST/SCC_EPAY_TRANS/SCC_EPAY_TRNTYP/SCC_EPAY_TENDER/SCC_EPAY_CARD");
&AcctNode =
ST/SCC_EPAY_TRANS/SCC_EPAY_TRNTYP/SCC_EPAY_TENDER/SCC_EPAY_ACCT");
&InvNode =
&BillNode =
&AddrNode =

End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_SETTLENOW");
&settleNow = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_TRANS_REF");
End-If;
End-If;
End-If;

&MerchantID = &XMLelementArray [1].NodeValue;
End-If;
End-If;
If Not &CardNode.IsNull Then

&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_NUMBER");
&cardNum = &XMLelementArray [1].NodeValue;
REM Strip non-numeric chars from the card field;
&cardNum = &Util.StripCRCard(&cardNum);
End-If;
&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_EXPYR");
&expYR = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_EXPMO");
&expMO = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_CVNUM");
&cvNum = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &CardNode.GetElementsByTagName("SCC_EPAY_TYPE");
&cardType = &XMLelementArray [1].NodeValue;
REM Translate the credit card type to the vendor's card type;
Evaluate &cardType
When "AE"
&cardType = "American Express";

When "DC"
&cardType = "Diner's Club";
When "DI"
&cardType = "Discover Card";
When "MC"
&cardType = "MasterCard";
When "VI"
&cardType = "Visa";
When-Other
&cardType = "";
End-Evaluate;
End-If;
End-If;

&transAmt = String(Value(&XMLelementArray [1].NodeValue) * 100);
End-If;
End-If;

End-If;
End-If;
End-If;

End-If;
End-If;
&fullname = &XMLelementArray [1].NodeValue;
End-If;

End-If;
End-If;
If Not &AcctNode.IsNull Then

&XMLelementArray = &AcctNode.GetElementsByTagName("SCC_EPAY_ACCT_TYPE");
&acctType = &XMLelementArray [1].NodeValue;
If &acctType = "C" Then
&savingsAcct = "false";
Else
&savingsAcct = "true";
End-If;
End-If;
&XMLelementArray = &AcctNode.GetElementsByTagName("SCC_EPAY_BANK_CD");
&bankCD = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &AcctNode.GetElementsByTagName("SCC_EPAY_ACCT_NBR");
&acctNBR = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &AcctNode.GetElementsByTagName("SCC_EPAY_CHECK_NBR");
&checkNBR = &XMLelementArray [1].NodeValue;
End-If;
End-If;

&XMLelementArray = &TrnDtlNode.GetElementsByTagName("SCC_EPAY_AGREE_NBR");
&agreementID = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TrnDtlNode.GetElementsByTagName("SCC_EPAY_ACH_CLASS");
&achClass = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TrnDtlNode.GetElementsByTagName("AGREEMENT_TEXT");
&agreementText = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TrnDtlNode.GetElementsByTagName("SCC_EPAY_IP_ADDR");
&ipAddress = &XMLelementArray [1].NodeValue;
End-If;
REM Default the ipAddress if none is passed in;
If None(&ipAddress) Then
&ipAddress = "127.1.1.1";
End-If;
End-If;


&EnvNode = &SoapDoc.DocumentElement;
&EnvNode.AddAttribute("xmlns:ws", "http://ws.paymentprovider.com");
&EnvNode.AddAttribute("xmlns:xsd", "http://www.w3.org/2001/XMLSchema");
&EnvNode.AddAttribute("xmlns:xsi", "http://www.w3.org/2001/XMLSchema-instance");
&workNode = &EnvNode.AddElement("soap:Header");
&workNode = &EnvNode.AddElement("soap:Body");
Evaluate &transType
When "1"
When "2"
REM Assuming that an implicit Bill/Capture occurs if processing an Auth/Bill (&transType of 2);
&SOAPMethod = "ccAuthCharge";
&workNode = &methodNode.AddElement("merchantName");
&workNode.NodeValue = &MerchantID;
&workNode = &methodNode.AddElement("ccn");
&workNode.NodeValue = &cardNum;
&workNode = &methodNode.AddElement("expdate");
&workNode.NodeValue = RTrim(&expMO) | RTrim(&expYR);
&workNode = &methodNode.AddElement("avs");
&workNode.NodeValue = RTrim(&avsStreet) | " " | RTrim(&avsZip);
&workNode = &methodNode.AddElement("cents");
&workNode.NodeValue = &transAmt;
&workNode = &methodNode.AddElement("ancillary");
&workNode.NodeValue = &MerchRef;
If All(&cvNum) Then
&workNode = &methodNode.AddElement("cvv2");
&workNode.NodeValue = &cvNum;
End-If;
When "3"
&SOAPMethod = "ccCapture";
&workNode = &methodNode.AddElement("tpgRefNum");
&workNode.NodeValue = &transRef;
&workNode = &methodNode.AddElement("bSettleNow");
If &settleNow = "Y" Then
&workNode.NodeValue = "true";
Else
&workNode.NodeValue = "false";
End-If;

When "4"
&SOAPMethod = "ccIssueCredit";
&workNode = &methodNode.AddElement("creditAmountCents");
When "5"
&SOAPMethod = "achMakePayment2";
&workNode = &methodNode.AddElement("routingNum");
&workNode.NodeValue = &bankCD;
&workNode = &methodNode.AddElement("accountNum");
&workNode.NodeValue = &acctNBR;
&workNode = &methodNode.AddElement("agreementText");
&workNode.NodeValue = &agreementText;
&workNode = &methodNode.AddElement("ipAddress");
&workNode.NodeValue = &ipAddress;
&workNode = &methodNode.AddElement("nameOnAcct");
&workNode.NodeValue = RTrim(&lname) | "," | RTrim(&fname);
&workNode = &methodNode.AddElement("achClass");
&workNode.NodeValue = &achClass;
&workNode = &methodNode.AddElement("checkNum");
&workNode.NodeValue = &checkNBR;
&workNode = &methodNode.AddElement("bSavingsAcct");
&workNode.NodeValue = &savingsAcct;
When "6"
&SOAPMethod = "achVoidPayment";
When-Other
&MSGXMLDoc = &MSGTData.XmlDoc;
End-Evaluate;


Request Sample 3: Request Transformation PeopleCode (Hosted Payment

Transactions Only)

Local XmlDoc &MSGDataXMLDoc;
Local XmlNode &EnvNode, &TransNode, &TrnDtlNode, &RqstNode, &InvNode, &BillNode, &AddrNode;
Local XmlNode &bodyNode, &methodNode, &workNode, &nameValuePairsNode;
Local string &SOAPMethod, &transType, &transRef, &MerchRef, &MerchantID, &requestToken, &transAmt,
&fname, &lname, &fullname, &avsStreet, &avsZip;
Local string &email, &city, &state, &country, &sessionID, &transactionSource, &cardType, &secret,
&secretVal, &amtInCents;
&MSGDataXMLDoc = &MSGTData.XmlDoc;
&RqstNode =
ST");
&TransNode =
&TrnDtlNode =
&InvNode =
&BillNode =
&AddrNode =

End-If;
End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_SESSIONID");
&sessionID = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_EPAY_RQST_TOKN");

&requestToken = &XMLelementArray [1].NodeValue;

End-If;
&XMLelementArray = &TransNode.GetElementsByTagName("SCC_PMT_APPL");
&transactionSource = &XMLelementArray [1].NodeValue;
End-If;
End-If;

&XMLelementArray = &TrnDtlNode.GetElementsByTagName("SCC_EPAY_SECRET");
&secret = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TrnDtlNode.GetElementsByTagName("SCC_EPAY_SECRETVAL");
&secretVal = &XMLelementArray [1].NodeValue;
End-If;
End-If;

&MerchantID = &XMLelementArray [1].NodeValue;
End-If;
End-If;

&amtInCents = String(Value(&XMLelementArray [1].NodeValue) * 100);
&amtInCents = LTrim(RTrim(NumberToString("%8.0", Value(&amtInCents))));
End-If;
End-If;

End-If;
End-If;
&XMLelementArray = &AddrNode.GetElementsByTagName("CITY");
&city = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &AddrNode.GetElementsByTagName("COUNTRY");


REM - NEED TO GET country code from country table here;
&country = &XMLelementArray [1].NodeValue;
&country = &Util.get2CharCountryCD(&country);
End-If;
&XMLelementArray = &AddrNode.GetElementsByTagName("STATE");
&state = &XMLelementArray [1].NodeValue;
End-If;
End-If;

End-If;
End-If;
&fullname = &XMLelementArray [1].NodeValue;
End-If;
End-If;
End-If;

&EnvNode = &SoapDoc.DocumentElement;
&EnvNode.AddAttribute("xmlns:typ", "http://types.secureLink.paymentprovider.com");
&workNode = &EnvNode.AddElement("soap:Header");
&workNode = &EnvNode.AddElement("soap:Body");
Evaluate &transType
When "91"
&SOAPMethod = "generateSecureLinkTicketRequest";
&methodNode = &bodyNode.AddElementNS("http://types.secureLink.paymentprovider.com", &SOAPMethod);
&methodNode.AddElement("ticketName").NodeValue = &transactionSource;
&nameValuePairsNode = &methodNode.AddElement("nameValuePairs");
&nameValuePairsNode.AddElement("name").NodeValue = "AMT";
&nameValuePairsNode.AddElement("value").NodeValue = &transAmt;
&nameValuePairsNode.AddElement("name").NodeValue = "BILL_NAME";

&nameValuePairsNode.AddElement("value").NodeValue = RTrim(&fname) | " " | RTrim(&lname);

&nameValuePairsNode.AddElement("name").NodeValue = "BILL_EMAIL_ADDRESS";
&nameValuePairsNode.AddElement("value").NodeValue = &email;
&nameValuePairsNode.AddElement("name").NodeValue = "BILL_STREET1";
&nameValuePairsNode.AddElement("value").NodeValue = &avsStreet;
&nameValuePairsNode.AddElement("name").NodeValue = "BILL_CITY";
&nameValuePairsNode.AddElement("value").NodeValue = &city;
&nameValuePairsNode.AddElement("name").NodeValue = "BILL_STATE";
&nameValuePairsNode.AddElement("value").NodeValue = &state;
&nameValuePairsNode.AddElement("name").NodeValue = "BILL_POSTAL_CODE";
&nameValuePairsNode.AddElement("value").NodeValue = &avsZip;
&nameValuePairsNode.AddElement("name").NodeValue = "BILL_COUNTRY";
&nameValuePairsNode.AddElement("value").NodeValue = &country;
&nameValuePairsNode.AddElement("name").NodeValue = "EXT_TRANS_ID";
&nameValuePairsNode.AddElement("value").NodeValue = &MerchRef;
If All(&secretVal) Then
&nameValuePairsNode.AddElement("name").NodeValue = "SSV";
&nameValuePairsNode.AddElement("value").NodeValue = &secretVal;
&nameValuePairsNode.AddElement("name").NodeValue = "SSV_PROMPT";
&nameValuePairsNode.AddElement("value").NodeValue = &secret;
End-If;
When "92"
&SOAPMethod = "authorizeAccountRequest";
&methodNode.AddElement("session").NodeValue = &sessionID;
&methodNode.AddElement("invoiceNumber").NodeValue = &MerchRef;
&methodNode.AddElement("ancillaryData").NodeValue = &MerchRef;
When "93"
&SOAPMethod = "adjustBalanceRequest";
&methodNode.AddElement("session").NodeValue = &sessionID;
&methodNode.AddElement("amount").NodeValue = &amtInCents;
&methodNode.AddElement("ancillaryData").NodeValue = &MerchRef;
When-Other
&MSGXMLDoc = &MSGTData.XmlDoc;
End-Evaluate;


Response Sample 1: Response Transformation PeopleCode

import SCC_EPAYMENT:DATA:Constants;
Local Rowset &responseRS, &SCC_EPAY_RSPNS, &SCC_EPAY_TRRSLT, &SCC_EPAY_AVRSLT;
Local Message &responseMsg;
Local XmlNode &Response, &FindResponse;
Local string &tgpRefNum, &authCode, &returnCode, &nodeName, &soapBody, &serviceName, &bankName,
&bankAddress, &bankCSZ, &agreementID, &agreement, &ipAddress, &merchantId;
Local string &merchantRefCode, &requestToken, &avsCodeRaw, &avsCode, &transRef, &requestID, &cvResult,
&trStatMsg, &decision, &message, &missingFields, &invalidFields, &authDTTM;
Local number &returnCodeNBR, &i, &result;
Local SCC_EPAYMENT:DATA:Constants &EPayConstants = create SCC_EPAYMENT:DATA:Constants();
REM Locate the SOAP Body of the vendor's response;

&soapBody = "/soap:Envelope/soap:Body";
&FindResponse = &MSGTData.XmlDoc.DocumentElement.FindNode(&soapBody);
&FindResponse = &FindResponse.GetChildNode(1);
&Response = &FindResponse;
REM Create the response message (SCC_EPAY_RESPONSE);

&responseMsg = CreateMessage(Operation.SCC_EPAYMENT_SYNC, %IntBroker_Response);
&responseRS = &responseMsg.GetRowset();
&SCC_EPAY_RSPNS = &responseRS.GetRow(1).GetRowset(Scroll.SCC_EPAY_RSPNS);
&SCC_EPAY_TRRSLT = &SCC_EPAY_RSPNS.GetRow(1).GetRowset(Scroll.SCC_EPAY_TRRSLT);
&SCC_EPAY_AVRSLT = &SCC_EPAY_TRRSLT.GetRow(1).GetRowset(Scroll.SCC_EPAY_AVRSLT);
&returnCode = "9999";
&returnCodeNBR = 9999;
If Not &Response.IsNull Then
REM Parse the vendor's response and extract relevant data;

For &i = 1 To &Response.ChildNodeCount
&FindResponse = &Response.GetChildNode(&i);
&nodeName = &FindResponse.NodeName;
Evaluate &nodeName
When "c:merchantReferenceCode"
&merchantRefCode = &FindResponse.NodeValue;
When "c:requestID"
&requestID = &FindResponse.NodeValue;
When "c:decision"
&decision = &FindResponse.NodeValue;
When "c:reasonCode"
&returnCode = &FindResponse.NodeValue;
&returnCodeNBR = Value(&returnCode);
When "c:requestToken"
&requestToken = &FindResponse.NodeValue;
When "c:ccAuthReply"

&XMLelementArray = &FindResponse.GetElementsByTagName("c:reasonCode");
&returnCode = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &FindResponse.GetElementsByTagName("c:authorizationCode");
&authCode = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &FindResponse.GetElementsByTagName("c:authorizedDateTime");
&authDTTM = String(&XMLelementArray [1].NodeValue);
End-If;
&XMLelementArray = &FindResponse.GetElementsByTagName("c:avsCode");
&avsCode = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &FindResponse.GetElementsByTagName("c:avsCodeRaw");
&avsCodeRaw = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &FindResponse.GetElementsByTagName("c:reconciliationID");
End-If;
&XMLelementArray = &FindResponse.GetElementsByTagName("c:cvCode");
&cvResult = &XMLelementArray [1].NodeValue;
End-If;
When "c:ccCaptureReply"
End-If;
End-If;
When "c:ecCreditReply"
End-If;
End-If;
When "c:ecDebitReply"


End-If;
End-If;
When "c:missingField"
&XMLelementArray = &FindResponse.GetElementsByTagName("c:missingField");
If All(&missingFields) Then
&missingFields = &missingFields | ", " | &XMLelementArray [1].NodeValue;
Else
&missingFields = &missingFields | &XMLelementArray [1].NodeValue;
End-If;
End-If;
When "c:invalidField"
&XMLelementArray = &FindResponse.GetElementsByTagName("c:invalidField");
If All(&invalidFields) Then
&invalidFields = &invalidFields | ", " | &XMLelementArray [1].NodeValue;
Else
&invalidFields = &XMLelementArray [1].NodeValue;
End-If;
End-If;
End-Evaluate;
End-For;
End-If;
REM Populate the response message (SCC_EPAY_RESPONSE) with data extracted from the vendor's response;
&SCC_EPAY_RSPNS.GetRow(1).SCC_EPAY_RSPNS.SCC_EPAY_MERCHANT.Value = &merchantId;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_TRANS_REF.Value = &transRef;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RQST_ID.Value = &requestID;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_AUTHCD.Value = &authCode;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RESP_CD.Value = &returnCode;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_AVS.Value = &avsCode;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RAWAVS.Value = &avsCodeRaw;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RQST_TOKN.Value = &requestToken;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_AUTHDTTM.Value = &authDTTM;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_CVRESULT.Value = &cvResult;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_AVS.Value = &avsCode;
Evaluate &returnCodeNBR
When 100
REM Successful Transaction;
&result = 0;
&decision = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.decisionSuccessful,
"Message Not Found");
&trStatMsg = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.trStatusMsgSuccessful,
&message = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.trStatusMsgSuccessful,


When 101
REM Missing field;
&result = 101;
&decision = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.decisionDeclined,
&trStatMsg = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.trStatusMsgDeclined,
&message = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.returnMsg101, "Message Not
Found", &missingFields);
When 102
REM Invalid field;
&result = 102;
"Message Not Found");;
Found", &invalidFields);
When 150
When 151
When 152
When 207
When 234
When 236
When 250
REM System error or transaction timeout;
&result = 300;
&decision = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.decisionError, "Message
Not Found");
&trStatMsg = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.trStatusMsgError,
Found");
When = 200
REM Transaction was declined - AVS Failed;
&result = 200;
Found");
When = 201
REM Transaction was declined - call card processor for possible approval;
&result = 201;
Found");
When = 202
REM Transaction was declined - card is expired;
&result = 122;


Found");
When = 203
When = 233
REM Transaction was declined;
&result = 123;
Found");
When = 204
REM Transaction was declined - insufficient funds;
&result = 124;
Found");
When = 205
REM Transaction was declined - lost or stolen card;
&result = 205;
Found");
When = 208
REM Transaction was declined - card not active or not authorized for card-not-present transactions;
&result = 128;
Found");
When = 209
REM Transaction was declined - CID did not match;
&result = 129;
Found");
When = 210
REM Transaction was declined - credit limit reached;
&result = 130;
Found");
When = 211

REM Transaction was declined - invalid CVV;

&result = 131;
Found");
When = 220
REM Transaction was declined;
&result = 123;
Found");
When = 221
REM The transaction was declined becuase the customer is on the negative file;
&result = 221;
Found");
When = 222
REM The transaction was declined because the account if frozen;
&result = 186;
Found");
When = 230
REM Transaction was declined - authorization approved by issuing bank but declined by CyberSource
because it failed (CV) Card Validation check;
&result = 230;
Found");
When = 231
REM Transaction was declined - invalid account number;
&result = 151;
Found");
When = 232
REM Transaction was declined - invalid card type for processor;
&result = 152;


Found");
When = 233
REM System Error;
&result = 300;
Not Found");
"Message Not Found");;
Found");
When = 234
&result = 300;
Not Found");
Found");
When = 235
REM Transaction was declined - capture error amount mismatch;
&result = 155;
Found");
When = 236
&result = 300;
Not Found");
Found");
When = 237
REM Transaction was declined - authorization already reversed;
&result = 157;
Found");
When = 238
When = 242
REM Transaction was declined - capture error, authorization already captured or authorization not
found;
&result = 158;

Found");
When = 239
REM Transaction was declined - transaction amount mismatch;
&result = 159;
Found");
When = 240
REM Transaction was declined - card type is invalid or does not correlate with the credit card
number;
&result = 160;
Found");
When = 241
REM Transaction was declined - invalid request ID;
&result = 161;
&trStatMsg = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.decisionDeclined,
Found");
When = 243
REM Transaction was declined - transaction already settled or reversed;
&result = 162;
Found");
When = 246
REM Transaction was declined - transaction can not be voided;
&result = 166;
Found");
When = 247
REM Transaction was declined - credit was requested for a voided capture;
&result = 167;
Found");
When = 250
&result = 300;


Not Found");
Found");
When-Other
&result = 300;
Not Found");
Found");
End-Evaluate;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RESULT.Value = &result;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_ORIGRSLT.Value = &returnCodeNBR;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_REASON_CD.Value = &returnCodeNBR;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_DECISION.Value = &decision;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_TRSTATMSG.Value = &trStatMsg;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RET_MSG.Value = &message;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_AUTHDTTM.Value = String(%Datetime);

&MSGTData.XmlDoc = CreateXmlDoc(&responseMsg.GenXMLString());
%TransformData.XmlDoc = &MSGTData.XmlDoc;

Response Sample 2: Response Transformation PeopleCode


Local Rowset &responseRS, &SCC_EPAY_RSPNS, &SCC_EPAY_TRRSLT, &SCC_EPAY_AVRSLT;

Local XmlNode &TNResponse, &TNFindResponse;
Local string &tgpRefNum, &authCode, &merchantId, &returnCode, &nodeName, &soapBody, &serviceName,
&statusCode, &statusDescr, &bankName, &bankAddress, &bankCSZ, &agreementID, &agreement, &ipAddress;
Local string &trStatMsg, &decision, &message, &missingFields, &invalidFields, &cvResult;
Local number &returnCodeNBR, &result;

&soapBody = "/soapenv:Envelope/soapenv:Body";
&TNFindResponse = &MSGTData.XmlDoc.DocumentElement.FindNode(&soapBody);
&TNFindResponse = &TNFindResponse.GetChildNode(1);
&nodeName = &TNFindResponse.NodeName;
&serviceName = RTrim(&nodeName);
&serviceName = &soapBody | "/" | &serviceName;
&TNResponse = &MSGTData.XmlDoc.DocumentElement.FindNode(&serviceName);

If Not &TNResponse.IsNull Then
REM parse vendor's response and extract relevant data;

Evaluate &nodeName
When "ccAuthChargeResponse"
&XMLelementArray = &TNResponse.GetElementsByTagName("tpgRefNum");
&tgpRefNum = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNResponse.GetElementsByTagName("authCode");
End-If;
&XMLelementArray = &TNResponse.GetElementsByTagName("merchantId");

&merchantId = &XMLelementArray [1].NodeValue;

End-If;
&XMLelementArray = &TNResponse.GetElementsByTagName("returnCode");
End-If;
When "ccCaptureResponse"
When "ccIssueCreditResponse"
End-If;
When "achMakePayment2Response"
&XMLelementArray = &TNResponse.GetElementsByTagName("tpgRefNum");
&tgpRefNum = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNResponse.GetElementsByTagName("authCode");
End-If;
End-If;
When-Other
End-If;
End-Evaluate;
End-If;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_TRANS_REF.Value = &tgpRefNum;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RQST_ID.Value = &tgpRefNum;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_STAT_CD.Value = &statusCode;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_STAT_DSCR.Value = &statusDescr;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_BANK_NAME.Value = &bankName;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_BANKADDR.Value = &bankAddress;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_BANKCSZ.Value = &bankCSZ;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_AGREE_NBR.Value = &agreementID;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.AGREEMENT_TEXT.Value = &agreement;

&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_IP_ADDR.Value = &ipAddress;
Evaluate True
When (&returnCodeNBR = 0)
REM Transaction was successful;
&result = 0;
When (&returnCodeNBR <= - 1 And
&returnCodeNBR >= - 26)
&result = 300;
Not Found");
Found");
&result = 300;
Not Found");
Found");
&result = 300;
Not Found");
Found");
When (&returnCodeNBR = - 1701)
&result = 300;
Not Found");
Found");
rem Invalid Card Data;
&result = 170;
Not Found");
&trStatMsg = MsgGetText(&EPayConstants.paymentManagerMSGSet, &EPayConstants.returnMsg170, "Message
Not Found");


Found");
rem request denied by processor;
&result = 123;
Not Found");
Not Found");
Found");
rem The transaction was declined due to a batch related issue;
&result = 171;
Not Found");
Not Found");
Found");
&result = 300;
Not Found");
Found");
rem The transaction was declined because the request is not valid for the specific operation type;
&result = 173;
Not Found");
Found");
&result = 171;
Not Found");
Found");
When (&returnCodeNBR = - 1721 Or
&returnCodeNBR = - 1722)
&result = 171;
Not Found");

Found");
rem The transaction was declined because of a failed AVS check;
&result = 200;
Not Found");
Found");
rem The transaction was declined because the card is not active or has expired;
&result = 122;
Not Found");
Found");
&result = 171;
Not Found");
Found");
rem The transaction was declined because an invalid amount was specified for the transaction;
&result = 172;
Not Found");
Found");
rem Reversal not allowed for this transaction;
&result = 174;
Not Found");
Found");
rem Declined because the operation has been attempted on a previously voided transaction;
&result = 175;
Not Found");
Found");
rem Operation is not valid for this type of operation;
&result = 176;


Not Found");
Found");
rem Bad settlements;
&result = 177;
Not Found");
Found");
rem The transaction was declined because the ACH routing number could not be found;
&result = 178;
Not Found");
Found");
rem The transaction was declined because the ACH routing number could not be found;
&result = 179;
Not Found");
Found");
rem The transaction was declined because the operation is not valid for this type of transaction;
&result = 176;
Not Found");
Found");
rem The transaction was declined because it was reinitiated too many times;
&result = 180;
Not Found");
Found");
rem The transaction was declined because the "Settle Now" is not allowed;
&result = 181;
Not Found");

Found");
rem The transaction was declined because it is not valid for the Merchant License;
&result = 182;
Not Found");
Found");
rem The transaction was declined because it is not allowed by the processor;
&result = 183;
Not Found");
Found");
rem The transaction was declined due to an invalid rejection code for the ACH transaction;
&result = 184;
Not Found");
Found");
&result = 171;
Not Found");
Found");
rem The transaction has been declined due to an invalid CVV number;
&result = 131;
Not Found");
Found");
&result = 300;
Not Found");
Found");
rem The transaction was declined becasue the operation is not allowed on payments from savings
accounts;
&result = 185;


Not Found");
Found");
&result = 300;
Not Found");
Found");
When-Other
&result = 300;
Not Found");
Found");
End-Evaluate;


Response Sample 3: Response Transformation PeopleCode (Hosted Payment

Transactions Only)

Local Rowset &responseRS, &SCC_EPAY_RSPNS, &SCC_EPAY_TRRSLT, &SCC_EPAY_AVRSLT, &SCC_EPAY_TENDER,
&SCC_EPAY_CARD, &SCC_EPAY_ACCT, &SCC_EPAY_BILLTO, &SCC_EPAY_ADDR2, &SCC_EPAY_SUBRSP;
Local XmlNode &TNResponse, &TNFindResponse, &XMLElement;
Local array of XmlNode &XMLelementArray, &nameElementArray, &valueElementArray;
Local string &tgpRefNum, &authCode, &merchantId, &returnCode, &nodeName, &soapBody, &serviceName,
&statusCode, &statusDescr, &bankName, &bankAddress, &bankCSZ, &agreementID, &agreement, &agreementDt,
&ipAddress, &ticket, &ticketName, &ticketExpire;
Local string &cvv2Available, &cvv2Succeeded, &avsAvailable, &avsSucceeded, &avsAddrStatus,
&avsZipStatus, &creditCardType;
Local string &trStatMsg, &decision, &message, &name, &value, &receipt, &maskedAccountNumber;
Local string &bankCityStateZip;
Local number &returnCodeNBR, &i, &result, &z;

&soapBody = "/soapenv:Envelope";
&TNFindResponse = &MSGTData.XmlDoc.DocumentElement.FindNode(&soapBody);
&TNFindResponse = &TNFindResponse.GetChildNode(1);
&serviceName = RTrim(&nodeName);
rem &TNResponse = &MSGTData.XmlDoc.DocumentElement.FindNode(&serviceName);

&TNResponse = &TNFindResponse;

&SCC_EPAY_TENDER = &SCC_EPAY_TRRSLT.GetRow(1).GetRowset(Scroll.SCC_EPAY_TENDER);
&SCC_EPAY_CARD = &SCC_EPAY_TENDER.GetRow(1).GetRowset(Scroll.SCC_EPAY_CARD);
&SCC_EPAY_ACCT = &SCC_EPAY_TENDER.GetRow(1).GetRowset(Scroll.SCC_EPAY_ACCT);
&SCC_EPAY_BILLTO = &SCC_EPAY_TRRSLT.GetRow(1).GetRowset(Scroll.SCC_EPAY_BILLTO);
&SCC_EPAY_ADDR2 = &SCC_EPAY_BILLTO.GetRow(1).GetRowset(Scroll.SCC_EPAY_ADDR2);
&SCC_EPAY_SUBRSP = &SCC_EPAY_TRRSLT.GetRow(1).GetRowset(Scroll.SCC_EPAY_SUBRSP);
If Not &TNResponse.IsNull Then

REM parse vendor's response and extract relevant data;
For &i = 1 To &TNResponse.ChildNodeCount
&TNFindResponse = &TNResponse.GetChildNode(&i);

Evaluate &nodeName
When "generateSecureLinkTicketResponse"
&XMLelementArray = &TNFindResponse.GetElementsByTagName("ticket");
&ticket = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("ticketExpire");
&ticketExpire = &XMLelementArray [1].NodeValue;
End-If;
&ticket = RTrim(&ticket);
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RQST_TOKN.Value = &ticket;
If All(&ticket) Then
&returnCodeNBR = 0;
Else
&returnCodeNBR = - 1;
End-If;
When "authorizeAccountResponse"
&XMLelementArray = &TNFindResponse.GetElementsByTagName("ticketName");
&ticketName = &XMLelementArray [1].NodeValue;
&ticketName = RTrim(&ticket);
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_PMT_APPL.Value = &ticketName;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("nameValuePairs");
For &z = 1 To &XMLelementArray.Len
&XMLElement = &XMLelementArray [&z];
&nameElementArray = &XMLElement.GetElementsByTagName("name");
If &nameElementArray.Len > 0 Then
&name = &nameElementArray [1].NodeValue;
&name = RTrim(&name);
End-If;
&valueElementArray = &XMLElement.GetElementsByTagName("value");
If &valueElementArray.Len > 0 Then
&value = &valueElementArray [1].NodeValue;
&value = RTrim(&value);
End-If;
If &name = "AMT" Then
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_TOTAL_AMT.Value = Value(&value);
End-If;
If &name = "EXT_TRANS_ID" Then
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_MERCH_REF.Value = &value;
End-If;
If &name = "BILL_NAME" Then
&SCC_EPAY_BILLTO.GetRow(1).SCC_EPAY_BILLTO.SCC_EPAY_FULLNAME.Value = &value;
End-If;
If &name = "BILL_EMAIL_ADDRESS" Then
&SCC_EPAY_BILLTO.GetRow(1).SCC_EPAY_BILLTO.SCC_EPAY_EMAIL.Value = &value;
End-If;

If &name = "BILL_STREET1" Then

&SCC_EPAY_ADDR2.GetRow(1).SCC_EPAY_ADDR2.ADDRESS1.Value = &value;
End-If;
If &name = "BILL_CITY" Then
&SCC_EPAY_ADDR2.GetRow(1).SCC_EPAY_ADDR2.CITY.Value = &value;
End-If;
If &name = "BILL_STATE" Then
&SCC_EPAY_ADDR2.GetRow(1).SCC_EPAY_ADDR2.STATE.Value = &value;
End-If;
If &name = "BILL_POSTAL_CODE" Then
&SCC_EPAY_ADDR2.GetRow(1).SCC_EPAY_ADDR2.POSTAL.Value = &value;
End-If;
If &name = "BILL_COUNTRY" Then
&SCC_EPAY_ADDR2.GetRow(1).SCC_EPAY_ADDR2.COUNTRY.Value = &value;
End-If;
End-For;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("achResponse");
&XMLelementArray = &TNFindResponse.GetElementsByTagName("approvalCode");
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("receiptNumber");
&receipt = &XMLelementArray [1].NodeValue;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RECEIPT.Value = &receipt;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("bankName");
&bankName = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("bankAddress");
&bankAddress = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("bankCityStateZip");
&bankCityStateZip = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("maskedAccountNumber");
&maskedAccountNumber = &XMLelementArray [1].NodeValue;
End-If;
End-If;

&XMLelementArray = &TNFindResponse.GetElementsByTagName("creditResponse");
&XMLelementArray = &TNFindResponse.GetElementsByTagName("approvalCode");
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("receiptNumber");
&receipt = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("cvv2Available");
&cvv2Available = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("cvv2Succeeded");
&cvv2Succeeded = &XMLelementArray [1].NodeValue;
End-If;
If &cvv2Available = "True" Then
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_AVS.Value = &cvv2Succeeded;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("avsAvailable");
&avsAvailable = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("avsSucceeded");
&avsSucceeded = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("avsZipStatus");
&avsZipStatus = &XMLelementArray [1].NodeValue;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("avsAddrStatus");
&avsAddrStatus = &XMLelementArray [1].NodeValue;
End-If;
If &avsAvailable = "True" Then
&SCC_EPAY_AVRSLT.GetRow(1).SCC_EPAY_AVRSLT.SCC_EPAY_MATCH_ZIP.Value = &avsZipStatus;
&SCC_EPAY_AVRSLT.GetRow(1).SCC_EPAY_AVRSLT.SCC_EPAY_MATCH_ST.Value = &avsAddrStatus;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_AVS.Value = &avsSucceeded;
End-If;
If &cvv2Available = "True" Then
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_CVRESULT.Value = &cvv2Succeeded;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("creditCardType");
&creditCardType = &XMLelementArray [1].NodeValue;
Evaluate &creditCardType
When "American Express"

&creditCardType = "AE";
When "Diner's Club"
&creditCardType = "DC";
When "Discover Card"
&creditCardType = "DI";
When "MasterCard"
&creditCardType = "MC";
When "Visa"
&creditCardType = "VI";
When-Other
&creditCardType = "";
End-Evaluate;
&SCC_EPAY_CARD.GetRow(1).SCC_EPAY_CARD.SCC_EPAY_TYPE.Value = &creditCardType;
End-If;
&XMLelementArray = &TNFindResponse.GetElementsByTagName("maskedAccountNumber");
&maskedAccountNumber = &XMLelementArray [1].NodeValue;
&SCC_EPAY_CARD.GetRow(1).SCC_EPAY_CARD.SCC_EPAY_NUMBER.Value = &maskedAccountNumber;
End-If;
End-If;
&returnCodeNBR = 0;
When "adjustBalanceResponse"
&returnCodeNBR = 0;
When "adjustBalanceRequestResponse"
&returnCodeNBR = 0;
When "emptyResponse"
&returnCodeNBR = 0;
End-Evaluate;
End-For;
End-If;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_TRANS_REF.Value = &tgpRefNum;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_RQST_ID.Value = &tgpRefNum;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_STAT_CD.Value = &statusCode;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_STAT_DSCR.Value = &statusDescr;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_BANK_NAME.Value = &bankName;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_BANKADDR.Value = &bankAddress;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_BANKCSZ.Value = &bankCSZ;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_AGREE_NBR.Value = &agreementID;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.AGREEMENT_TEXT.Value = &agreement;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.AGREEMENT_DT.Value = &agreementDt;
&SCC_EPAY_TRRSLT.GetRow(1).SCC_EPAY_TRRSLT.SCC_EPAY_IP_ADDR.Value = &ipAddress;
REM This vendor throws out SOAP faults for any exceptions or declines.;
REM SOAP faults need to be intercepted and interrogated in the Integration Broker adapter;

REM and can not be processed here as Integration Broker processing is immediately terminated;
REM once a SOAP fault is received.;
Evaluate True
When (&returnCodeNBR = 0)
REM Transaction was successful;
&result = 0;
When-Other
&result = 300;
Not Found");
Found");
End-Evaluate;


Electronic_Payment_Integration_Developer_s_Reference_Guide

Uploaded by

Copyright:

Available Formats

You might also like

Electronic_Payment_Integration_Developer_s_Reference_Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Electronic_Payment_Integration_Developer_s_Reference_Guide

Uploaded by

Copyright:

Available Formats

PeopleSoft Developer’s Reference Guide

Campus Solutions 9.0 Electronic Payment

Copyright © 2009, Oracle. All rights reserved.

The information contained in this document is proprietary and confidential to Oracle.

No part of this document may be reproduced or transmitted in any form or by any

Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation

© Copyright Oracle Corporation 2009. All rights reserved. 2

TABLE OF CONTENTS ................................................................................................................................................ 3

ELECTRONIC PAYMENT OVERVIEW ........................................................................................................................ 7

ARCHITECTURE OF THE EPAYMENT API ................................................................................................................ 9

ARCHITECTURE OF THE HOSTED PAYMENT FRAMEWORK .............................................................................. 11

IMPLEMENTING THE TRADITIONAL PAYMENT MODEL ....................................................................................... 16

IMPLEMENTING THE HOSTED PAYMENT MODEL ................................................................................................ 27

© Copyright PeopleSoft Corporation 2009. All rights reserved. 3

Step 4: Test the Integration ........................................................................................................................... 33

© Copyright Oracle Corporation 2009. All rights reserved. 4

STRUCTURE OF THIS DEVELOPER’S REFERENCE GUIDE

 Enterprise PeopleTools 8.49 PeopleBook: Internet Technology

This PeopleBook provides an understanding of PeopleTools Internet technology.

 Enterprise PeopleTools 8.49 PeopleBook: PeopleSoft Integration Broker

© Copyright PeopleSoft Corporation 2009. All rights reserved. 5

© Copyright Oracle Corporation 2009. All rights reserved. 6

Electronic Payment Overview

TRADITIONAL VS. HOSTED PAYMENT MODELS

© Copyright Oracle Corporation 2009. All rights reserved. 7

© Copyright Oracle Corporation 2009. All rights reserved. 8

Architecture of the ePayment API

Process Flow Diagram

Process Flow Narrative

© Copyright Oracle Corporation 2009. All rights reserved. 9

Components of the ePayment API

 Transaction class (see “Appendix G: Transaction Class” for more information)

o Adapter Registry (see “Appendix I: Adapter Registry” for more information)

o Payment Merchant (see “Appendix J: Payment Merchant” for more information)

 Integration Technologies (Business Interlinks and Integration Broker)

© Copyright Oracle Corporation 2009. All rights reserved. 10

Architecture of the Hosted Payment Framework

© Copyright Oracle Corporation 2009. All rights reserved. 11

2. The application invokes the Hosted Payment framework.

© Copyright Oracle Corporation 2009. All rights reserved. 12

9. The third party responds with a token.

13. The iScript performs the form post.

© Copyright Oracle Corporation 2009. All rights reserved. 13

© Copyright Oracle Corporation 2009. All rights reserved. 14

9. The iScript redirects to the component.

THIRD PARTY INTEGRATION REQUIREMENTS FOR HOSTED PAYMENT

© Copyright Oracle Corporation 2009. All rights reserved. 15

Implementing the Traditional Payment Model

Supported Transactions for the Traditional Model:

 Bill (Capture) Only

 Make Payment (Debit)

TRADITIONAL MODEL USING BUSINESS INTERLINKS

Step 1: Pre-Requisite Setup

Verify Business Interlinks Setup

© Copyright Oracle Corporation 2009. All rights reserved. 16

Step 2: Create the Payment Merchant

1. Log in to Campus Solutions using PIA.

3. Click on “Add a New Value” tab.

5. Enter values in the various Payment Merchant fields: